from future import pass_function

[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]

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>

 

[Steven D'Aprano]

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.

 

[Devin Jeanpierre]

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]

Am 26.07.2012 04:38, schrieb Steven D'Aprano:

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.

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.

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.

 

[Chris Angelico]

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).

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

ChrisA

 

[Devin Jeanpierre]

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

In Haskell, sure.

-- Devin

 

[Ulrich Eckhardt]

Am 26.07.2012 11:26, schrieb Steven D'Aprano:

*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.

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]

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.

 

[rusi]

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.Traceback (most recent call last):

None+[1,2,3]

Traceback (most recent call last):

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]

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.

...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.

 

[Joel Goldstick]

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.




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.

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

 

[Prasad, Ramit]

No offence to all the well meaning participants here, but this looks liketrolling

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]

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

 

[Dennis Lee Bieber]

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

if(conditional):
would become
True:
or
False:

What determines that branching is desired? The colon? (then what
does the colon on "def x():" perform?)

Or take "while"...

while condition: #implies a loop

while(condition): #as a function implies a return value so again we
have

True:
or
False:

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

 

[Chris Angelico]

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]

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]

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."

 

[John Ladasky]

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