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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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():
>
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
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()",
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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():
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
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
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
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
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:
50 matches
Mail list logo