Re: from future import pass_function

2012-07-27 Thread 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(): {} Uli -- http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

2012-07-26 Thread 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

Re: from future import pass_function

2012-07-26 Thread 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 ab

Re: from future import pass_function

2012-07-26 Thread Mark Lawrence
On 26/07/2012 18:33, Chris Angelico wrote: On Fri, Jul 27, 2012 at 3:19 AM, 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? Certainly not. We are well endowed with trolls here (X

Re: from future import pass_function

2012-07-26 Thread 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

Re: from future import pass_function

2012-07-26 Thread John Ladasky
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

Re: from future import pass_function

2012-07-26 Thread Ethan Furman
John Ladasky wrote: 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 thi

Re: from future import pass_function

2012-07-26 Thread 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 wrote: > On Thu, Jul 26, 2012 at 1:20 AM, Michael Hri

Re: from future import pass_function

2012-07-26 Thread Ian Kelly
On Thu, Jul 26, 2012 at 2:48 PM, John Ladasky 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

Re: from future import pass_function

2012-07-26 Thread 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/c

Re: from future import pass_function

2012-07-26 Thread 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

Re: from future import pass_function

2012-07-26 Thread 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 s

Re: from future import pass_function

2012-07-26 Thread Chris Kaynor
On Thu, Jul 26, 2012 at 11:01 AM, Dennis Lee Bieber wrote: > On Thu, 26 Jul 2012 19:42:11 +1000, Chris Angelico > 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... > > > An

Re: from future import pass_function

2012-07-26 Thread Chris Angelico
On Fri, Jul 27, 2012 at 4:01 AM, Dennis Lee Bieber wrote: > On Thu, 26 Jul 2012 19:42:11 +1000, Chris Angelico > 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

Re: from future import pass_function

2012-07-26 Thread Chris Angelico
On Fri, Jul 27, 2012 at 3:19 AM, 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? Certainly not. We are well endowed with trolls here (Xah Lee isn't prolific, but is certainly

RE: from future import pass_function

2012-07-26 Thread 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, accura

Re: from future import pass_function

2012-07-26 Thread Joel Goldstick
On Thu, Jul 26, 2012 at 11:21 AM, Steven D'Aprano 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 complai

Re: from future import pass_function

2012-07-26 Thread 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 noo

Re: from future import pass_function

2012-07-26 Thread rusi
On Jul 25, 1:40 pm, 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. > > Example: >     def pass(): >  

Re: from future import pass_function

2012-07-26 Thread 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 ex

Re: from future import pass_function

2012-07-26 Thread Ulrich Eckhardt
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()",

Re: from future import pass_function

2012-07-26 Thread Devin Jeanpierre
On Thu, Jul 26, 2012 at 5:42 AM, Chris Angelico 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 functio

Re: from future import pass_function

2012-07-26 Thread Chris Angelico
On Thu, Jul 26, 2012 at 7:16 PM, Devin Jeanpierre wrote: > On Thu, Jul 26, 2012 at 1:20 AM, 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! > > No, you actual

Re: from future import pass_function

2012-07-26 Thread 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 si

Re: from future import pass_function

2012-07-26 Thread Devin Jeanpierre
On Thu, Jul 26, 2012 at 1:20 AM, 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! No, you actually can't. You omit the one control flow statement that could actu

Re: from future import pass_function

2012-07-26 Thread 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

Re: from future import pass_function

2012-07-26 Thread 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! And if we could persuade the BDFL to introduce braces, we could have {() and }() -- Cheer

Re: from future import pass_function

2012-07-26 Thread Mark Lawrence
On 26/07/2012 05:03, Ross Ridge wrote: Ross Ridge 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 wrote: Except that print

Re: from future import pass_function

2012-07-26 Thread 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

Re: from future import pass_function

2012-07-26 Thread 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 k

Re: from future import pass_function

2012-07-26 Thread 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 w

Re: from future import pass_function

2012-07-25 Thread 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

Re: from future import pass_function

2012-07-25 Thread 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 ax

Re: from future import pass_function

2012-07-25 Thread Ethan Furman
Ross Ridge wrote: Ross Ridge 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 wrote: Except that print / print() is executa

Re: from future import pass_function

2012-07-25 Thread alex23
On Jul 26, 1:30 pm, Ross Ridge 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 a

Re: from future import pass_function

2012-07-25 Thread alex23
On Jul 26, 11:42 am, Ross Ridge 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 fun

Re: from future import pass_function

2012-07-25 Thread Ross Ridge
Ross Ridge 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 wrote: >Except that print / print() is executable. Execution p

Re: from future import pass_function

2012-07-25 Thread Chris Angelico
On Thu, Jul 26, 2012 at 1:30 PM, Ross Ridge wrote: > Steven D'Aprano 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, an

Re: from future import pass_function

2012-07-25 Thread Ross Ridge
Steven D'Aprano 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 wrote: >I can't believe I actually have to point this out explicitly, but pass is >not print.

Re: from future import pass_function

2012-07-25 Thread 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 wrote: >What's the point of this? Remember everything you've said about wh

Re: from future import pass_function

2012-07-25 Thread Devin Jeanpierre
On Wed, Jul 25, 2012 at 2:14 PM, Ian Kelly wrote: > You can already use pass (or the equivalent) in a lambda. > > lambda: None This lacks my foolish consistency. -- Devin -- http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

2012-07-25 Thread Ian Kelly
On Jul 25, 2012 10:51 AM, "Devin Jeanpierre" wrote: > True. But it might be nice to use pass both in lambdas and regular > functions, or to use pass as a variable name. You can already use pass (or the equivalent) in a lambda. lambda: None -- http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

2012-07-25 Thread Devin Jeanpierre
On Wed, Jul 25, 2012 at 12:05 PM, Chris Angelico 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

Re: from future import pass_function

2012-07-25 Thread 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_somethi

Re: from future import pass_function

2012-07-25 Thread Chris Angelico
On Wed, Jul 25, 2012 at 6:40 PM, 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():

Re: from future import pass_function

2012-07-25 Thread 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 n

Re: from future import pass_function

2012-07-25 Thread Devin Jeanpierre
On Wed, Jul 25, 2012 at 4:40 AM, Ulrich Eckhardt wrote: > What do you think? retort: def foo(): None -- Devin -- http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

2012-07-25 Thread Nicholas Cole
On Wed, Jul 25, 2012 at 9:40 AM, Ulrich Eckhardt 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 bui

Re: from future import pass_function

2012-07-25 Thread 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

from future import pass_function

2012-07-25 Thread 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: