On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak <mhriv...@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).
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.
<jeanpierr...@gmail.com> wrote:
> On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak <mhriv...@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).
Well, if/while/for could be functions. So could with, probably. Now,
def would be a little tricky...
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...
> On Thu, 26 Jul 2012 08:59:30 +0200, Ulrich Eckhardt wrote:
>> Am 26.07.2012 04:38, schrieb Steven D'Aprano:
>>> (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.
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!
> 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.
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")
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.
>> 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.
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
> 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.
<ramit.pra...@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...
On Fri, Jul 27, 2012 at 4:01 AM, Dennis Lee Bieber
<wlfr...@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.
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:
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.
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...
...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."
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
<ulrich.eckha...@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.
<john_lada...@sbcglobal.net> wrote:
> 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:
> 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.
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.
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.
<jeanpierr...@gmail.com> wrote:
> On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak <mhriv...@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).
> ...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."
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
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...
...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."
On Thursday, July 26, 2012 2:23:02 PM UTC-7, Ethan Furman wrote:
> That'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).
On Thursday, July 26, 2012 2:23:02 PM UTC-7, Ethan Furman wrote:
> That'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).
> 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`.
> On Fri, Jul 27, 2012 at 3:19 AM, Prasad, Ramit
> <ramit.pra...@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...
Are you nuts, asbestos? My tin hat, camouflage net and trenching tool are very much safer :)
>> 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.
