Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #26027 > unrolled thread

from future import pass_function

Back to article view | Back to comp.lang.python

Contents

  from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-25 10:40 +0200
    Re: from future import pass_function Philipp Hagemeister <phihag@phihag.de> - 2012-07-25 12:30 +0200
    Re: from future import pass_function Nicholas Cole <nicholas.cole@gmail.com> - 2012-07-25 11:33 +0100
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-25 07:02 -0400
    Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-25 11:33 +0000
      Re: from future import pass_function Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-25 21:42 -0400
        Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 02:38 +0000
          Re: from future import pass_function Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-25 23:30 -0400
            Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-26 13:53 +1000
              Re: from future import pass_function Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-26 00:03 -0400
                Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-25 21:32 -0700
                  Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 13:55 -0700
                  Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-26 14:23 -0700
                    Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 15:20 -0700
                    Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 15:20 -0700
                  Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 13:55 -0700
                Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-26 08:43 +0100
            Re: from future import pass_function alex23 <wuwei23@gmail.com> - 2012-07-25 21:20 -0700
          Re: from future import pass_function Rusi <rustompmody@gmail.com> - 2012-07-25 22:09 -0700
          Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 08:59 +0200
            Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 09:26 +0000
              Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 13:45 +0200
                Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 15:21 +0000
                  Re: from future import pass_function Joel Goldstick <joel.goldstick@gmail.com> - 2012-07-26 12:55 -0400
                  RE: from future import pass_function "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-07-26 17:19 +0000
                  Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-27 03:33 +1000
                  Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-27 00:25 +0100
                  Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-27 00:23 +0100
        Re: from future import pass_function alex23 <wuwei23@gmail.com> - 2012-07-25 21:17 -0700
    Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-26 02:05 +1000
      Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 08:39 +0200
        Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 08:36 +0000
        Re: from future import pass_function Terry Reedy <tjreedy@udel.edu> - 2012-07-26 10:38 -0400
    Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-25 09:28 -0700
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-25 12:48 -0400
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-25 14:17 -0400
    Re: from future import pass_function Michael Hrivnak <mhrivnak@hrivnak.org> - 2012-07-26 01:20 -0400
      Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 08:42 +0200
        Re: from future import pass_function Michael Hrivnak <mhrivnak@hrivnak.org> - 2012-07-26 17:15 -0400
    Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-26 08:50 +0100
      Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-27 08:39 +0200
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-26 05:16 -0400
    Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-26 19:42 +1000
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-26 06:00 -0400
    Re: from future import pass_function rusi <rustompmody@gmail.com> - 2012-07-26 08:01 -0700
    Re: from future import pass_function Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-26 14:01 -0400
    Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-27 04:14 +1000
    Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 13:48 -0700
      Re: from future import pass_function Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-26 15:18 -0600
      Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-26 15:35 -0700
      Re: from future import pass_function Terry Reedy <tjreedy@udel.edu> - 2012-07-27 00:21 -0400
    Re: from future import pass_function Michael Hrivnak <mhrivnak@hrivnak.org> - 2012-07-26 17:20 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#26074

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

[toc] | [prev] | [next] | [standalone]

#26084

Am 26.07.2012 11:26, schrieb 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:
>>> (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!


Uli

[toc] | [prev] | [next] | [standalone]

#26098

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

[toc] | [prev] | [next] | [standalone]

#26101

On Thu, Jul 26, 2012 at 11:21 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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
> --
> 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

[toc] | [prev] | [next] | [standalone]

#26102

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

[toc] | [prev] | [next] | [standalone]

#26103

On Fri, Jul 27, 2012 at 3:19 AM, Prasad, Ramit
<ramit.prasad@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

[toc] | [prev] | [next] | [standalone]

#26126

On 26/07/2012 18:33, Chris Angelico wrote:
> On Fri, Jul 27, 2012 at 3:19 AM, Prasad, Ramit
> <ramit.prasad@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 :)

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

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#26128

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.

[toc] | [prev] | [next] | [standalone]

#26058

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?

[toc] | [prev] | [next] | [standalone]

#26045

On Wed, Jul 25, 2012 at 6:40 PM, Ulrich Eckhardt
<ulrich.eckhardt@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

[toc] | [prev] | [next] | [standalone]

#26067

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

[toc] | [prev] | [next] | [standalone]

#26072

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

[toc] | [prev] | [next] | [standalone]

#26092

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

[toc] | [prev] | [next] | [standalone]

#26046

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~

[toc] | [prev] | [next] | [standalone]

#26047

On Wed, Jul 25, 2012 at 12:05 PM, Chris Angelico <rosuav@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

[toc] | [prev] | [next] | [standalone]

#26048

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

This lacks my foolish consistency.

-- Devin

[toc] | [prev] | [next] | [standalone]

#26062

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.eckhardt@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
>
>    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
> --
> http://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#26066

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

[toc] | [prev] | [next] | [standalone]

#26116

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

[toc] | [prev] | [next] | [standalone]

#26070

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.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web