from future import pass_function

[Ulrich Eckhardt]

Hi!

I just had an idea, it occurred to me that the pass statement is pretty
similar to the print statement, and similarly to the print() function,
there could be a pass() function that does and returns nothing.

Example:
def pass():
return

try:
do_something()
except:
pass()


One thing I don't like about this is the syntax

class foo(object):
pass()


What do you think?

Uli

[Philipp Hagemeister]

Unlike the print statement, pass has no overboarding complexity (like
>>, printing tuples, etc.) - it just serves as a marker (and
practicality beats purity).

And you don't ever want to use pass as a value (say, for map() or the
right side of an assignment). In fact, if pass were a function, users
could construct strange code like

x = pass()

def pass():
raise Exception('Are you slacking off? Get back to work!')

And don't forget that while the parentheses mainly confuse users,
they're also making it harder to type, and feel like useless overhead
(similar to the parentheses in if (x): ). In fact, I'd argue that if
pass were a function, None would be the better placeholder:

try:
do_something()
except:
None # 2 hard-to-type (on a German keyboard) characters shorter
# (and probably way faster: No function call overhead and no need
# to actually find out what pass happens to be in this context)

- Philipp

[Nicholas Cole]

On Wed, Jul 25, 2012 at 9:40 AM, Ulrich Eckhardt
<ulrich....@dominolaser.com> wrote:
> What do you think?
>

I enjoyed the question, but actually I don't think this is a good idea.

1. If you really needed something like this, you could define it easily.

def do_nothing(*args, **keywords):
return None

2. If it were a built-in function, you would be able to override it,
and then there would be chaos.

Best,

Nicholas

[Devin Jeanpierre]

On Wed, Jul 25, 2012 at 4:40 AM, Ulrich Eckhardt

<ulrich....@dominolaser.com> wrote:
> What do you think?

retort:

def foo():
None

-- Devin

[Steven D'Aprano]

On Wed, 25 Jul 2012 10:40:45 +0200, Ulrich Eckhardt wrote:

> Hi!
>
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement,

[...]
> try:
> do_something()
> except:
> pass()

What's the point of this? If you intend to do nothing, why call a
function instead?

There's a surprising amount of effort involved behind the scenes in
calling a function. Python has to:

1) look up the function's name to get access to the function object
2) push any arguments onto the stack
3) determine the function object's type
4) look up its __call__ method
5) match the arguments (if any) with the parameter list (if any)
6) execute the function body
7) push the return result (None) onto the stack in case it's needed
8) and pop it off the stack.

Turning pass into a function instead of a statement would essentially
take something that does *nothing at all* into something that
(figuratively speaking) jumps up to its feet, runs around the room three
times, and then sits back down again.


--
Steven

[Chris Angelico]

On Wed, Jul 25, 2012 at 6:40 PM, Ulrich Eckhardt
<ulrich....@dominolaser.com> wrote:
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, and similarly to the print() function, there
> could be a pass() function that does and returns nothing.
>
> Example:
> def pass():
> return
>
> try:
> do_something()
> except:
> pass()

Except that "pass" is a syntactic construct that basically says "hey,
I have an indented block here, but there's no code in it". It's not
executable any more than the syntactic token "INDENT" is. It's more
closely related to the colon at the end of "try" than it is to the
"do_something()" call.

By comparison, Python 2's print statement is executable. It causes
real action to happen at run-time. It makes sense to pass "print" as
an argument to something; for instance:

def some_generator():
yield blah

map(print,some_generator())

Simple way of making the iterator display its yielded result. I cannot
imagine any circumstance in which you'd want to map "pass" over
everything. But then, as Teresa said, I'm only one, and possibly I'm
wrong!

ChrisA

[Ethan Furman]

Ulrich Eckhardt wrote:
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, and similarly to the print() function,
> there could be a pass() function that does and returns nothing.
>
> Example:
> def pass():
> return
>
> try:
> do_something()
> except:
> pass()

Do you have a use case where `pass()` works but `pass` doesn't?

~Ethan~

[Devin Jeanpierre]

On Wed, Jul 25, 2012 at 12:05 PM, Chris Angelico <ros...@gmail.com> wrote:
> Simple way of making the iterator display its yielded result. I cannot
> imagine any circumstance in which you'd want to map "pass" over
> everything. But then, as Teresa said, I'm only one, and possibly I'm
> wrong!

True. But it might be nice to use pass both in lambdas and regular
functions, or to use pass as a variable name.

(Unfortunately, these two niceties are somewhat in conflict.)

-- Devin

[Devin Jeanpierre]

On Wed, Jul 25, 2012 at 2:14 PM, Ian Kelly <ian.g...@gmail.com> wrote:
> You can already use pass (or the equivalent) in a lambda.
>
> lambda: None

This lacks my foolish consistency.

-- Devin

[Ross Ridge]

Ulrich Eckhardt wrote:
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement,
[...]
> try:
> do_something()
> except:
> pass()

Steven D'Aprano <steve+comp....@pearwood.info> wrote:
>What's the point of this?

Remember everything you've said about why its a good thing the that
print statement is now a function? That.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Steven D'Aprano]

On Wed, 25 Jul 2012 21:42:18 -0400, Ross Ridge wrote:

> Ulrich Eckhardt wrote:
>> I just had an idea, it occurred to me that the pass statement is pretty
>> similar to the print statement,
> [...]
>> try:
>> do_something()
>> except:
>> pass()
>
> Steven D'Aprano <steve+comp....@pearwood.info> wrote:
>>What's the point of this?
>
> Remember everything you've said about why its a good thing the that
> print statement is now a function? That.

I can't believe I actually have to point this out explicitly, but pass is
not print. Apart from them both starting with the letter "P", they are
nothing alike. There are good reasons for making print a function, and
they don't apply to pass because pass doesn't do what print does.

The examples of pass-as-a-function shown by the Original Poster don't
give any clue of what advantage there is to make pass a function. It
appears that the only reason for this suggested change is that he would
rather write "pass()" instead of "pass", possibly because he thinks it
looks cool.

(Actually, I reckon that what is driving this idea is that the OP is a
beginner, and he's got a syntax error a few times from writing "pass()",
and so he thought it would be easier to force other people to change tens
or hundreds of thousands of Python programs to use "pass()" instead of
"pass" than to just learn to stop putting parentheses after it. I
remember what it was like to be a beginner with six weeks experience in a
twenty year old language, full of shiny new ideas for "improving" it.)

But of course I could be wrong. Ulrich, if you are still reading this, if
you have good examples for how pass as a function would actually be
better, and how it will let you do things in Python that can't easily be
done now, I'm very interested to hear them. Who knows, if the idea is
good enough, some day it may even happen.


--
Steven

[Ross Ridge]

Steven D'Aprano <steve+comp....@pearwood.info> wrote:
>What's the point of this?

Ross Ridge wrote:
> Remember everything you've said about why its a good thing the that
> print statement is now a function? That.

Steven D'Aprano <steve+comp....@pearwood.info> wrote:
>I can't believe I actually have to point this out explicitly, but pass is
>not print. Apart from them both starting with the letter "P", they are
>nothing alike. There are good reasons for making print a function, and
>they don't apply to pass because pass doesn't do what print does.

No, they're very much alike. That's why all your arguments for print
as function also apply just as well to pass a function. Your arguments
had very little to do what what print actually did.

[Chris Angelico]

On Thu, Jul 26, 2012 at 1:30 PM, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
> Steven D'Aprano <steve+comp....@pearwood.info> wrote:
>>I can't believe I actually have to point this out explicitly, but pass is
>>not print. Apart from them both starting with the letter "P", they are
>>nothing alike. There are good reasons for making print a function, and
>>they don't apply to pass because pass doesn't do what print does.
>
> No, they're very much alike. That's why all your arguments for print
> as function also apply just as well to pass a function. Your arguments
> had very little to do what what print actually did.

Except that print / print() is executable. Execution proceeds through
your code, comes to a "print", and goes off to handle that, then comes
back to your code. But "pass" doesn't have code attached to it. Why
should it be a function?

One of the reasons for print becoming a function was its strange
collection of modifiers. How do you, with the print statement, send
output to someplace other than stdout? How do you make it not put a
newline? Far more logical to make those into keyword-only arguments to
a function, and far easier to later add more such options. What
parameters do you give to "pass"?

The pass keyword exists because Python can't have an empty pair of
braces, or an empty semicolon, to represent a "null statement". It
needs a keyword. That keyword is syntax, not code.

ChrisA

[Ross Ridge]

Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
> No, they're very much alike. That's why all your arguments for print
> as function also apply just as well to pass a function. Your arguments
> had very little to do what what print actually did.

Chris Angelico <ros...@gmail.com> wrote:
>Except that print / print() is executable. Execution proceeds through
>your code, comes to a "print", and goes off to handle that, then comes
>back to your code. But "pass" doesn't have code attached to it. Why
>should it be a function?

For consistancy with print. What it does doesn't matter any more than
what print did mattered.

[alex23]

On Jul 26, 11:42 am, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
> Remember everything you've said about why its a good thing the that
> print statement is now a function?  That.

You regularly have the need to override the behaviour of pass?

Are you _really_ saying you see no distinction between an application-
level function and a low-level command directed at the interpreter?

[alex23]

On Jul 26, 1:30 pm, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
> No, they're very much alike.

Repetition isn't evidence. You keep making this claim, so support it.

> That's why all your arguments for print
> as function also apply just as well to pass a function.  Your arguments
> had very little to do what what print actually did.

As far as I can see, the only arguments Steven made were against pass
as a function, with an illustration of the function call cost that
pass-as-function would incur.

Your arguments, on the other hand, amount to nothing more than "nuh
uh!"

[Ethan Furman]

Ross Ridge wrote:
> Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
>> No, they're very much alike. That's why all your arguments for print
>> as function also apply just as well to pass a function. Your arguments
>> had very little to do what what print actually did.
>
> Chris Angelico <ros...@gmail.com> wrote:
>> Except that print / print() is executable. Execution proceeds through
>> your code, comes to a "print", and goes off to handle that, then comes
>> back to your code. But "pass" doesn't have code attached to it. Why
>> should it be a function?
>
> For consistancy with print. What it does doesn't matter any more than
> what print did mattered.

Of course what print did mattered. `print` was not changed to `print()`
because a function looks cooler; it was changed because it does stuff,
and what it does could be changed with parameters, and overriding it
with your own custom thingie was a useful thing to do.

What code does `pass` run? When do we pass parameters to `pass`? When
do we need to override `pass`?

Answers: None. Never. Still waiting for a reply from the OP for a use
case.

How does that quote go? "A foolish consistency is the hobgoblin of
little minds"? This definitely fits that category.

~Ethan~

[Rusi]

Ulrich:
If you take a look at pep 3105 you find five rationales.
http://www.python.org/dev/peps/pep-3105/#rationale

If the first were the only one then your suggestion would have merit.
There are also the other 4 in which pass and print dont really
correspond.

Steven wrote earlier:
> I have an axe that has been passed down for generations through my
> family, from my father, his father before him, and his father, and his
> father before him. Occasionally we replace the handle, or put on a new
> head, but that axe is almost as good as the day my great-great-
> grandfather made it.

Yeah I see that you are always wielding your great-great-grandfather's
axe. As for example

On Jul 26, 7:38 am, Steven D'Aprano <steve

+comp.lang.pyt...@pearwood.info> wrote:
> (Actually, I reckon that what is driving this idea is that the OP is a
> beginner, and he's got a syntax error a few times from writing "pass()",
> and so he thought it would be easier to force other people to change tens
> or hundreds of thousands of Python programs to use "pass()" instead of
> "pass" than to just learn to stop putting parentheses after it. I
> remember what it was like to be a beginner with six weeks experience in a
> twenty year old language, full of shiny new ideas for "improving" it.)

Do you sharpen it sometimes?

[Michael Hrivnak]

If we want pass(), then why not break() and continue()? And also
def() and class()? for(), while(), if(), with(), we can make them all
callable objects!

Except that they are control statements. They are not objects, they
have no type, and they can never be evaluated in an expression. And
most importantly, there is no value to be gained by making them
objects.

It is valuable for a language to have control statements, as others
have already explained. This is an interesting exercise to think
about what their nature is, but at the end of the day, embrace them
for what they are.

Michael

On Wed, Jul 25, 2012 at 4:40 AM, Ulrich Eckhardt
<ulrich....@dominolaser.com> wrote:

> --
> http://mail.python.org/mailman/listinfo/python-list

[Ulrich Eckhardt]

Am 25.07.2012 18:05, schrieb Chris Angelico:
> By comparison, Python 2's print statement is executable. It causes
> real action to happen at run-time. It makes sense to pass "print" as
> an argument to something; for instance:
>
> def some_generator():
> yield blah
>
> map(print,some_generator())
>
> Simple way of making the iterator display its yielded result. I cannot
> imagine any circumstance in which you'd want to map "pass" over
> everything.

I have seen code that just created a list comprehension to iterate over
something but was discarding the results. That could be a case for a "do
nothing" function.

Just having a function that does nothing would be useful in other
places, too. In some cases, you want to print() some debug output in
other cases you just use pass() to discard the debug output.

Uli

[Ulrich Eckhardt]

Am 26.07.2012 07:20, schrieb Michael Hrivnak:
> If we want pass(), then why not break() and continue()? And also
> def() and class()? for(), while(), if(), with(), we can make them all
> callable objects!
>
> Except that they are control statements. They are not objects, they
> have no type, and they can never be evaluated in an expression. And
> most importantly, there is no value to be gained by making them
> objects.

pass is not a control statement, it is just a placeholder to make it
explicit that there is nothing else to be expected here.

Uli

[Ulrich Eckhardt]

Am 26.07.2012 04:38, schrieb Steven D'Aprano:
> The examples of pass-as-a-function shown by the Original Poster don't
> give any clue of what advantage there is to make pass a function.

Just read the text, it just struck me how similar pass and print are,
i.e. that neither actually needs to be a keyword. In some cases, I would
rather use "return" to replace "pass" though.

> It appears that the only reason for this suggested change is that he
> would rather write "pass()" instead of "pass", possibly because he
> thinks it looks cool.

I have no idea where you got the "cool" from, it is not in my posting. I
stated clearly that "I just had an idea", which should signal that I
haven't thought about this for any extended period of time. Then I asked
"What do you think?" exactly because I wanted to discuss this. No need
to get defensive. ;)

> (Actually, I reckon that what is driving this idea is that the OP is a
> beginner, and he's got a syntax error a few times from writing "pass()",
> and so he thought it would be easier to force other people to change tens
> or hundreds of thousands of Python programs to use "pass()" instead of
> "pass" than to just learn to stop putting parentheses after it.

So, and in order to force people to write parens or break their code I
have considered the possibility of importing that feature from
__future__ for those people that want it? Seriously, Steven, as much as
I like your regular contributions here, this time you had better logged
off and taken a walk, because you come across as _very_ arrogant here.

> But of course I could be wrong. Ulrich, if you are still reading this, if
> you have good examples for how pass as a function would actually be
> better, and how it will let you do things in Python that can't easily be
> done now, I'm very interested to hear them. Who knows, if the idea is
> good enough, some day it may even happen.

No there is nothing that you strictly need a pass() function for.


In summary, after reading this thread I have a lot of good arguments
against this idea and few arguments supporting the idea. In any case I
have many more arguments than those that I came up with myself, which is
exactly what I asked for.


Thanks to all that took part in this discussion!

Uli

[Mark Lawrence]

On 26/07/2012 05:03, Ross Ridge wrote:
> Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
>> No, they're very much alike. That's why all your arguments for print
>> as function also apply just as well to pass a function. Your arguments
>> had very little to do what what print actually did.
>
> Chris Angelico <ros...@gmail.com> wrote:
>> Except that print / print() is executable. Execution proceeds through
>> your code, comes to a "print", and goes off to handle that, then comes
>> back to your code. But "pass" doesn't have code attached to it. Why
>> should it be a function?
>
> For consistancy with print. What it does doesn't matter any more than
> what print did mattered.
>
> Ross Ridge
>

My all time favourite engineering quote, from the UK Ptarmigan tactical
communications project, springs to my mind here regarding your comments
about the comparison of print and pass. "I might not be a mechanical
engineer, but that's fucking wrong".

--
Cheers.

Mark Lawrence.

[Mark Lawrence]

On 26/07/2012 06:20, Michael Hrivnak wrote:
> If we want pass(), then why not break() and continue()? And also
> def() and class()? for(), while(), if(), with(), we can make them all
> callable objects!

<reaching for tin hat, camouflage net and trenching tool>

And if we could persuade the BDFL to introduce braces, we could have {()
and }()

</reaching for tin hat, camouflage net and trenching tool>

--
Cheers.

Mark Lawrence.

[Steven D'Aprano]

On Thu, 26 Jul 2012 08:39:25 +0200, Ulrich Eckhardt wrote:

> I have seen code that just created a list comprehension to iterate over
> something but was discarding the results. That could be a case for a "do
> nothing" function.

That would be a case for *not* using a list comprehension.

Using a list comp when you don't want the results is the wrong way to do
it. That's like hammering a screw into a wall with a wrench. Okay, I
admit it, sometimes if I'm lazy and I'm in the interactive interpreter
and I need to consume use up results from an iterator, I type:

_ = [x for x in iterator]

and then I kick myself because I could have just written:

_ = list(iterator)

but in actual code, I'm not so lazy to bang that screw into the wall
using a wrench. I at least reach for a hammer:

_ = [None for x in iterator]

or better still, a drill:

collections.deque(iterator, maxlen=0)



But fine, you need a do-nothing function. Here you go:

_ = [(lambda x: None)(x) for x in sequence]

> Just having a function that does nothing would be useful in other
> places, too. In some cases, you want to print() some debug output in
> other cases you just use pass() to discard the debug output.

You're still not giving reasons why *pass* should be a do-nothing
function. Of course there are good use-cases for do-nothing functions,
that goes without saying. But you have to explain why:

1) that do-nothing function is so common and so important that it has to
be a built-in function; and

2) why it needs to be called "pass".


Nobody is disputing the usefulness of do nothing functions. We're
disputing that *pass* should be that function.



--
Steven

[Devin Jeanpierre]

On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak <mhri...@hrivnak.org> wrote:
> If we want pass(), then why not break() and continue()? And also
> def() and class()? for(), while(), if(), with(), we can make them all
> callable objects!

No, you actually can't.

You omit the one control flow statement that could actually be turned
into a function, raise. None of the rest could in Python (except
class), and one of the rest couldn't in any language (def).

-- Devin

[Steven D'Aprano]

On Thu, 26 Jul 2012 08:59:30 +0200, Ulrich Eckhardt wrote:

> Am 26.07.2012 04:38, schrieb Steven D'Aprano:
>> The examples of pass-as-a-function shown by the Original Poster don't
>> give any clue of what advantage there is to make pass a function.
>
> Just read the text, it just struck me how similar pass and print are,
> i.e. that neither actually needs to be a keyword. In some cases, I would
> rather use "return" to replace "pass" though.

I did read your text. I was not enlightened.

>> It appears that the only reason for this suggested change is that he
>> would rather write "pass()" instead of "pass", possibly because he
>> thinks it looks cool.
>
> I have no idea where you got the "cool" from, it is not in my posting.

I didn't say that was what you said. I made it clear that "cool" was *my*
words.

>> (Actually, I reckon that what is driving this idea is that the OP is a
>> beginner, and he's got a syntax error a few times from writing
>> "pass()", and so he thought it would be easier to force other people to
>> change tens or hundreds of thousands of Python programs to use "pass()"
>> instead of "pass" than to just learn to stop putting parentheses after
>> it.
>
> So, and in order to force people to write parens or break their code I
> have considered the possibility of importing that feature from
> __future__ for those people that want it? Seriously, Steven, as much as
> I like your regular contributions here, this time you had better logged
> off and taken a walk, because you come across as _very_ arrogant here.

*shrug* I'm just being honest. As you admitted, you hadn't really given
the idea a lot of thought. Your examples didn't show any difference
except a pair of parentheses () after the pass. I made two guesses on
what motivated your suggestion, based on the information I had in front
of me at the time.

By the way, you trimmed out my comment where I admit to also having come
up with changes to Python without giving any thought to the consequences.
My guesses as to your motive for wanting to change "pass" were not based
on your thoughts, which are hidden to me, but on the way I used to think.
It took me a long time to learn that, for an established language like
Python, change is nearly always for the worse, and any change that
requires changing existing code better have a very good excuse.


--
Steven

[Chris Angelico]

Well, if/while/for could be functions. So could with, probably. Now,
def would be a little tricky...

ChrisA

[Devin Jeanpierre]

On Thu, Jul 26, 2012 at 5:42 AM, Chris Angelico <ros...@gmail.com> wrote:
>> You omit the one control flow statement that could actually be turned
>> into a function, raise. None of the rest could in Python (except
>> class), and one of the rest couldn't in any language (def).
>
> Well, if/while/for could be functions. So could with, probably. Now,
> def would be a little tricky...

In Haskell, sure.

-- Devin

[Ulrich Eckhardt]

I didn't say "Pass should be a function!" but asked "What do you
think?". You are assuming lots of things about my goals and jumping to
conclusions like that I'm complaining about the stupid Python syntax,
that I'm a frustrated noob, that I want someone to fix that syntax, but
that is not the case! I'm engaging in a discussion here exactly in order
to test the idea I had.

> It took me a long time to learn that, for an established language like
> Python, change is nearly always for the worse, and any change that
> requires changing existing code better have a very good excuse.

...so what do you do when you have an idea? You think about it on your
own, right? I do so, too, but I also engage in discussions with others.
See? BTW: I think you missed the implications of this thread's topic and
the snide remark about forcing people to change their code, i.e. that no
existing code has to change (apart from the Python implementation, of
course), even if pass was made a function!


Uli

[Terry Reedy]

On 7/26/2012 2:39 AM, Ulrich Eckhardt wrote:

> I have seen code that just created a list comprehension to iterate over
> something but was discarding the results.

If you mean, discard the resulting list, that is probably bad code as it
should not create the list in the first place. A generator expression or
for loop will iterate without creating an unneeded list.

> That could be a case for a "do nothing" function.

Such code does do something within the comprehension.

> Just having a function that does nothing

Not possible. None is the default return. Python does not have
proceedures, and that is not going to change, especially for a null
proceedure.

--
Terry Jan Reedy

[rusi]

On Jul 25, 1:40 pm, Ulrich Eckhardt <ulrich.eckha...@dominolaser.com>

wrote:
> Hi!
>
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, and similarly to the print() function,
> there could be a pass() function that does and returns nothing.
>
> Example:
>     def pass():
>         return

Since many have said NO but I see no good reasons for this no yet,
here's mine:

tl;dr version: Do-nothing statements are easy just do nothing, ie
pass.
Do-nothing expressions are hard. In the fully generic context they are
impossible to implement.

Longer version:

Consider the if expression and the if statement. The if statement can
have its else part elided in which case it defaults to pass. The if
expression cannot so elide. Why?

Consider the expression: (exp if cond) # no else
Now in "x + (exp if cond)" if cond is false it should presumably be 0
However in "x * (exp if cond)" it should presumably be 1?
And in the first case if x were a list should it not be [] ?

Now consider your suggestion:
def pass(): return
is identical to
def pass(): return None

So you are saying that None can serve as a "generic zero"?
Of course as you know (no suggestion that you are a noob on my part!!)

Python 2.7.3rc2 (default, Apr 22 2012, 22:35:38)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0+3
3
>>> None+3
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
>>> None+[1,2,3]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'NoneType' and 'list'
>>>

So now you (may) retort but these have nothing to do with what you
asked.

You see what youve asked for is moving pass from the statement world
to the expression world.
The meaning of a do-nothing statement is easy to give. The meaning of
a do-nothing expression is hard because we are obliged to specify a
type for expressions and the only value that can possibly belong to
all types is the error-value (what denotational semantics calls bottom
⊥ )

A more laymanish example:
I have a multiplication
I want one of the operands to be a 1, ie the identity
I substitute it with the nearest available value ie 0

And out goes the baby with the bathwater!

So to come back to your proposal:

> there could be a pass() function that does and returns nothing.

does nothing: easy
returns nothing: impossible (None is not "nothing", its more like
"error")

[Steven D'Aprano]

On Thu, 26 Jul 2012 13:45:23 +0200, Ulrich Eckhardt wrote:

> I didn't say "Pass should be a function!" but asked "What do you
> think?". You are assuming lots of things about my goals and jumping to
> conclusions like that I'm complaining about the stupid Python syntax,
> that I'm a frustrated noob, that I want someone to fix that syntax, but
> that is not the case! I'm engaging in a discussion here exactly in order
> to test the idea I had.

Fair point. I underestimated you. But go back and re-read your first
post, and see if you can understand *why* I underestimated you. You
really didn't give any sign that you had given this question much
detailed thought.

Perhaps if you had mentioned that you had not decided whether this was a
good idea and was looking for arguments both for and against, this tone
of this discussion would have been very different.

>> It took me a long time to learn that, for an established language like
>> Python, change is nearly always for the worse, and any change that
>> requires changing existing code better have a very good excuse.
>
> ...so what do you do when you have an idea? You think about it on your
> own, right? I do so, too, but I also engage in discussions with others.
> See? BTW: I think you missed the implications of this thread's topic and
> the snide remark about forcing people to change their code, i.e. that no
> existing code has to change (apart from the Python implementation, of
> course), even if pass was made a function!

I think that you misunderstand the purpose of from __future__ import. It
is a *temporary* measure, always. Features which are not backward
compatible are FIRST introduced as __future__ features, and THEN a
release or two later, they become mandatory. (Unless they are dropped,
which has not happened yet.)

There have been seven __future__ features as of Python 3.2:

absolute_import (enabled in 2.5, mandatory in 2.7)
division (enabled in 2.2, mandatory in 3.0)
generators (enabled in 2.2, mandatory in 2.3)
nested_scopes (enabled in 2.1, mandatory in 2.2)
print_function (enabled in 2.6, mandatory in 3.0)
unicode_literals (enabled in 2.6, mandatory in 3.0)
with_statement (enabled in 2.5, mandatory in 2.6)


In any case, I acknowledge that I was wrong about your motivation. I made
a guess based on the limited information I had, and based on my own
history, and you tell me my guess was wrong. I accept that.



--
Steven

[Joel Goldstick]

> --
> http://mail.python.org/mailman/listinfo/python-list


This is the silliest thread I've ever seen in this group. I should
abstain, but what the heck:

If you want a function that does nothing, write one. Maybe like this:

def do_nothing():
return

Then, where you previous wrote pass in your code you can replace it
with this thing.

But really, not being a language meta-maven myself, somewhere above in
this thread it was pointed out that pass is a syntax construction that
is necessary in the very seldom case where you create a block of code
that has no instructions. Instead of braces for every block, you get
to skip that in python and just put pass in this extraordinary little
case.

While I've come to the point in my python coding knowledge to get my
day to day work done proficiently, I'm amazed each time I delve deeper
into how profoundly well this language was thought out. No offence to
all the well meaning participants here, but this looks like trolling
--
Joel Goldstick

[Prasad, Ramit]

> No offence to all the well meaning participants here, but this looks like trolling

I thought Ranting Rick had sole dominion over trolling?

Ramit


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

[Chris Angelico]

On Fri, Jul 27, 2012 at 3:19 AM, Prasad, Ramit
<ramit....@jpmorgan.com> wrote:
>> No offence to all the well meaning participants here, but this looks like trolling
>
> I thought Ranting Rick had sole dominion over trolling?

Certainly not. We are well endowed with trolls here (Xah Lee isn't
prolific, but is certainly effective), plus we have some regular
posters who'll cover the trolls' tea breaks on occasion (myself,
sometimes, and Steven D'Aprano).

Now where did I put my asbestos suit... the Aprano is going to be at
me pretty hard for this...

*dives for cover without it*

ChrisA

[Chris Angelico]

On Fri, Jul 27, 2012 at 4:01 AM, Dennis Lee Bieber
<wlf...@ix.netcom.com> wrote:
> On Thu, 26 Jul 2012 19:42:11 +1000, Chris Angelico <ros...@gmail.com>
> declaimed the following in gmane.comp.python.general:

>
>> Well, if/while/for could be functions. So could with, probably. Now,
>> def would be a little tricky...
>>

> And how would a function "if" perform

It'd be much more similar to the ternary operator. Currently there's
no way to pass an unevaluated expression to a Python function, but the
concept isn't impossible. It's just more suited to functional
languages (someone mentioned Haskell) than to imperative ones.

> Now, how does the language differentiate between a loop and an if?
>
> if(conditional):
> do something and continue with next statement
>
> turns into
> True:
> do something and continue with next statement
>
> while
>
> while(conditional):
> do something and go back to the test
>
> turns into
> True:
> do something and go back to the test

Oh THAT's easily solved. A while loop is an if with a goto!

Okay, was that sufficiently incendiary? Have fun! :)

ChrisA

[John Ladasky]

On Wednesday, July 25, 2012 1:40:45 AM UTC-7, Ulrich Eckhardt wrote:
> Hi!
>
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, and similarly to the print() function,
> there could be a pass() function that does and returns nothing.

I had very similar thoughts about eight months ago, and posted them here:

https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A

I'm no computer science guru, but the idea that pass should be a function rather than a statement continues to appeal to me. As you can see, I actually wrote just such a function so that I could use it as an argument in my code.

[John Ladasky]

On Wednesday, July 25, 2012 9:32:33 PM UTC-7, Ethan Furman wrote:

> What code does `pass` run? When do we pass parameters to `pass`? When
> do we need to override `pass`?
>
> Answers: None. Never. Still waiting for a reply from the OP for a use
> case.

When I brought up this same issue some months ago...

https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A

...it wasn't because I wanted to pass parameters to "pass", it was because I wanted to define a do-nothing function as an optional behavior within another function. In other words, I wanted to pass "pass."

[Michael Hrivnak]

It's not uncommon for "pass" to be referred to as a control statement,
although I see your point that it isn't exerting as much control over
the flow of execution as others. As further evidence, this doc
categorizes it as a "statement" within "flow control tools":
http://docs.python.org/tutorial/controlflow.html

Michael

On Thu, Jul 26, 2012 at 2:42 AM, Ulrich Eckhardt
<ulrich....@dominolaser.com> wrote:
> pass is not a control statement, it is just a placeholder to make it
> explicit that there is nothing else to be expected here.
>
> Uli

> --
> http://mail.python.org/mailman/listinfo/python-list

[Ian Kelly]

As long as 1) the name can't be reassigned (like None) and 2) the
compiler is able to optimize it out when used by itself as a statement
(to avoid incurring the expense of a common but pointless name
lookup), then I kind of agree. The added complexity of those two
restrictions detracts a bit from the appeal to elegance, though.

[Michael Hrivnak]

In case the rest of the email didn't make it obvious, everything you
quoted me on was sarcasm. I know those things can't be done, and I
explained why they can't and shouldn't be done.

Michael

On Thu, Jul 26, 2012 at 5:16 AM, Devin Jeanpierre

<jeanpi...@gmail.com> wrote:
> On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak <mhri...@hrivnak.org> wrote:
>> If we want pass(), then why not break() and continue()? And also
>> def() and class()? for(), while(), if(), with(), we can make them all
>> callable objects!
>
> No, you actually can't.
>

> You omit the one control flow statement that could actually be turned
> into a function, raise. None of the rest could in Python (except
> class), and one of the rest couldn't in any language (def).
>

> -- Devin

[Ethan Furman]

That's a reasonable thing to want, and quite easily accomplished by
passing `lambda: None` or `lambda *args, **kwargs: None` instead. I
don't think this is difficult to do, nor common enough to justify making
every other `pass` a time-consuming do-nothing operation, instead of
just a do-nothing operation

~Ethan~

[John Ladasky]

[John Ladasky]

On Thursday, July 26, 2012 2:23:02 PM UTC-7, Ethan Furman wrote:

> That&#39;s a reasonable thing to want, and quite easily accomplished by

> passing `lambda: None` or `lambda *args, **kwargs: None` instead.

That's the same solution that Steven D'Aprano proposed the last time we had this discussion. Which, I agree, is reasonable (although I continue to have a certain instinctive aversion to lambda).

[John Ladasky]

On Thursday, July 26, 2012 2:23:02 PM UTC-7, Ethan Furman wrote:

> That&#39;s a reasonable thing to want, and quite easily accomplished by

> passing `lambda: None` or `lambda *args, **kwargs: None` instead.

[Ethan Furman]

John Ladasky wrote:
> I had very similar thoughts about eight months ago, and posted them here:
>
> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A
>
> I'm no computer science guru, but the idea that pass should be a function rather than a statement continues to appeal to me. As you can see, I actually wrote just such a function so that I could use it as an argument in my code.

I would have called `no_op` or `nop` -- `pass` does just what it says:
it passes and does zero work. Your _pass does do work, just useless
work. Sometimes that's necessary, but I wouldn't call it `_pass`.

~Ethan~

[Mark Lawrence]

Are you nuts, asbestos? My tin hat, camouflage net and trenching tool
are very much safer :)

>
> *dives for cover without it*
>
> ChrisA
>

--
Cheers.

Mark Lawrence.

[Mark Lawrence]

On 26/07/2012 18:19, Prasad, Ramit wrote:
>> No offence to all the well meaning participants here, but this looks like trolling
>
> I thought Ranting Rick had sole dominion over trolling?

Incorrect. Yes he can be a PITA but when he writes about tkinter/idle
he appears to know what he's talking about. I much prefer that to The
World's Leading Expert On Writing Documentation aka Xah Lee who must
spend his entire life sittng down as his voice is so muffled.

>
> Ramit
>
>
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of
> securities, accuracy and completeness of information, viruses,
> confidentiality, legal privilege, and legal entity disclaimers,
> available at http://www.jpmorgan.com/pages/disclosures/email.
>

--
Cheers.

Mark Lawrence.

[Terry Reedy]

On 7/26/2012 4:48 PM, John Ladasky wrote:

> I had very similar thoughts about eight months ago, and posted them
> here:
>
> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A
>
> I'm no computer science guru, but the idea that pass should be a
> function rather than a statement continues to appeal to me.

A do nothing statement is standard in statement based languages. It is
not going away.

> can see, I actually wrote just such a function so that I could use it
> as an argument in my code.

For one time use: lambda:None

For multiple use: def none: pass # same as return None in this context

A function needs a lot more meat than that to be added as a builtin.

---
Terry Jan Reedy

[Ulrich Eckhardt]

Am 26.07.2012 09:50, schrieb Mark Lawrence:
> And if we could persuade the BDFL to introduce braces, we could have {()
> and }()

What do you mean "persuade"? Braces work perfectly:

def foo():
{}

<grin, duck and run faster as the impacts get closer>

Uli