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 (likepracticality 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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEAREKAAYFAlAPyqsACgkQ9eq1gvr7CFwG0QCfdbVu/D7WxmsB8VwFVcrscpdq
cIwAn3WreGWR34zsYaBd6sFmUANg/PUQ
=LwyH
-----END PGP SIGNATURE-----

 

[Nicholas Cole]

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]

What do you think?

retort:

def foo():
None

-- Devin

 

[Steven D'Aprano]

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.

 

[Chris Angelico]

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]

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]

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

 

[Ross Ridge]

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?

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

Ross Ridge

 

[Steven D'Aprano]

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?

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.

 

[Ross Ridge]

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.

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.

Ross Ridge

 

[Chris Angelico]

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]

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?

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

Ross Ridge

 

[alex23]

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]

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]

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

(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

 

[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