Am Mittwoch 24 Mai 2006 06:12 schrieb Tim Roberts:
At one time, it was said that the % operator was the fastest way to
concatenate strings, because it was implemented in C, whereas the +
operator was interpreted. However, as I recall, the difference was hardly
measurable, and may not even
Heiko Wundram wrote:
Am Mittwoch 24 Mai 2006 06:12 schrieb Tim Roberts:
At one time, it was said that the % operator was the fastest way to
concatenate strings, because it was implemented in C, whereas the +
operator was interpreted. However, as I recall, the difference was
hardly
Edward Elliott [EMAIL PROTECTED] wrote:
bruno at modulix wrote:
Edward Elliott wrote:
You mean like this:
s = foo + bar
s = 'foo' + 'bar'
s = 'foo' 'bar'
s = '%s%s' % ('foo', 'bar')
[snip]
The real mantra is actually :
There should be one-- and preferably only one --obvious way to do
Edward Elliott wrote:
George Sakkis wrote:
Em Dom, 2006-05-21 às 17:11 +0200, Heiko Wundram escreveu:
for node in tree if node.haschildren():
do something with node
as syntactic sugar for:
for node in tree:
if not node.haschildren():
continue
do something with node
[snip]
2) There
Heiko Wundram wrote:
...
As I've noticed that I find myself typing the latter quite often
in code I write, it would only be sensible to add the corresponding
syntax for the for statement:
for node in tree if node.haschildren():
do something with node
as
Am Montag 22 Mai 2006 11:27 schrieb Boris Borcic:
Mhhh, your unsugared form remind me of darks hours with primitive BASICS in
my youth - the kind Dijsktra commented on. Why don't you write
for node in tree:
if node.haschildren():
do something with node
As
bruno at modulix wrote:
Edward Elliott wrote:
You mean like this:
s = foo + bar
s = 'foo' + 'bar'
s = 'foo' 'bar'
s = '%s%s' % ('foo', 'bar')
[snip]
The real mantra is actually :
There should be one-- and preferably only one --obvious way to do it
Please note the should, preferably,
+1 It does seem like a natural unificiation of the language -- one less
exception to learn.
-- Russell
--
http://mail.python.org/mailman/listinfo/python-list
Hi all!
The following PEP tries to make the case for a slight unification of for
statement and list comprehension syntax.
Comments appreciated, including on the sample implementation.
===
PEP: xxx
Title: Unification of for-statement and list-comprehension syntax
Version: $Revision$
i wanted to suggest this myself. +1
-tomer
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-05-21, Heiko Wundram wrote:
Hi all!
The following PEP tries to make the case for a slight unification of for
statement and list comprehension syntax.
Sounds great!
--
Konrad
--
http://mail.python.org/mailman/listinfo/python-list
Em Dom, 2006-05-21 às 17:11 +0200, Heiko Wundram escreveu:
for node in tree if node.haschildren():
do something with node
as syntactic sugar for:
for node in tree:
if not node.haschildren():
continue
do something with node
Today you can archive the same effect (but not necessarily with the same
performance) with:
for node in (x for x in tree if x.haschildren()):
do something with node
true, but it has different semantic meanings
-tomer
--
http://mail.python.org/mailman/listinfo/python-list
Em Dom, 2006-05-21 às 11:52 -0700, gangesmaster escreveu:
Today you can archive the same effect (but not necessarily with the same
performance) with:
for node in (x for x in tree if x.haschildren()):
do something with node
true, but it has different semantic meanings
I know,
Felipe Almeida Lessa wrote:
Em Dom, 2006-05-21 às 11:52 -0700, gangesmaster escreveu:
Today you can archive the same effect (but not necessarily with the same
performance) with:
for node in (x for x in tree if x.haschildren()):
do something with node
true, but it has
George Sakkis wrote:
Em Dom, 2006-05-21 às 17:11 +0200, Heiko Wundram escreveu:
for node in tree if node.haschildren():
do something with node
as syntactic sugar for:
for node in tree:
if not node.haschildren():
continue
do something with node
[snip]
2) There should be one and
Heiko Wundram wrote:
The following PEP tries to make the case for a slight unification of for
statement and list comprehension syntax.
-1
Adds complexity to the language and saves you nothing but an indent
level. However, I encourage you to submit this PEP and get a (almost
certianly
Edward Elliott wrote:
Special cases aren't special enough to break the rules. (proposal eliminates
the current special case for comprehensions/generators)
It really isn't a special case, though. It might seem like it is, but
it's not at all when you remember the rules of equivalence between
18 matches
Mail list logo
