Re: PEP-xxx: Unification of for statement and list-comp syntax
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 exist any longer. The difference doesn't exist anymore for CPython (if you join a lot of strings), but for Jython (and several other dialects), the fastest way to join strings is still .join(), because there are no optimizations on a += b and the likes of it (replacement for the % operator, e.g.). --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
RE: PEP-xxx: Unification of for statement and list-comp syntax
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 measurable, and may not even exist any longer. The difference doesn't exist anymore for CPython (if you join a lot of strings) Actually, the string concatenation optimisations only work in certain specific cases (although they are the most common cases). It is still definitely advised to append to a list, then join the list. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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 it
Please note the should, preferably, and obvious.
Touche. Please tell me which of the above should obviously be the
preferable way to concatenate strings. All those weasel words prove my
point: it's a vague and watered-down guideline that gives way in the face
of other considerations.
Well, there's really no difference between the first two, and this would
work just as well:
s = foo + '''bar'''
The third line only works for string constants, not for string variables.
IMHO, it would be the preferred method for concatenating string constants.
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 exist any longer.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza Boekelheide, Inc.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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 should be one and preferably only one way to do it.
You mean like this:
s = foo + bar
s = 'foo' + 'bar'
s = 'foo' 'bar'
s = '%s%s' % ('foo', 'bar')
This one and only one way stuff is overrated. I don't care how many ways
there are as long as:
1. at least one way is intuitive
2. every way is easily comprehendible (readable, no side effects, etc)
The real mantra is actually :
There should be one-- and preferably only one --obvious way to do it
Please note the should, preferably, and obvious.
My 2 cents
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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 syntactic sugar for: for node in tree: if not node.haschildren(): continue do something with node 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 ? -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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 I've replied on python-dev, indentation is not always a good thing, especially if the for-body is longer than a few lines. The if not: continue form allows you to keep the indentation at one level, so that it's pretty clear what is part of the loop body, and what is not. If you add an extra indentation, your mind has to keep track of the indentation, and will expect an else: somewhere, which in the use case I propose won't happen. At least that's what my mind does, and is majorly confused, if the else doesn't appear. This certainly is personal taste, and AFAICT there are pretty few people who feel like I do. But, basically, I find it easier to have one level of indentation, and to test for the negated condition, than to put the loop body in an enclosing if-statement, which will always add an extra level of indentation. I put forth the proposal, because it allows you to save this level of indentation, which makes the code more readable for me. Anyway, the PEP has already been rejected on python-dev, and I'm currently just rewriting it with the positive and negative things that have so far been said, so basically, it'll just be there so that people can be pointed at it when anybody else'll ask for it. --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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, and obvious.
Touche. Please tell me which of the above should obviously be the
preferable way to concatenate strings. All those weasel words prove my
point: it's a vague and watered-down guideline that gives way in the face
of other considerations.
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
+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
PEP-xxx: Unification of for statement and list-comp syntax
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$
Last-Modified: $Date$
Author: Heiko Wundram [EMAIL PROTECTED]
Status: Active
Type: Standards Track
Content-Type: text/plain
Created: 21-May-2006
Post-History: 21-May-2006 17:00 GMT+0200
Abstract
When list comprehensions were introduced, they added the ability
to add conditions which are tested before the expression which is
associated with the list comprehension is evaluated. This is
often used to create new lists which consist only of those items
of the original list which match the specified condition(s). For
example:
[node for node in tree if node.haschildren()]
will create a new list which only contains those items of the
original list (tree) whose items match the havechildren()
condition. Generator expressions work similarily.
With a standard for-loop, this corresponds to adding a continue
statement testing for the negated expression at the beginning of
the loop body.
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 syntactic sugar for:
for node in tree:
if not node.haschildren():
continue
do something with node
There are several other methods (including generator-expressions or
list-comprehensions, the itertools module, or the builtin filter
function) to achieve this same goal, but all of them make the code
longer and harder to understand and/or require more memory, because
of the generation of an intermediate list.
Implementation details
The implementation of this feature requires changes to the Python
grammar, to allow for a variable number of 'if'-expressions before
the colon of a 'for'-statement:
for_stmt: 'for' exprlist 'in' testlist_safe ('if' old_test)* ':'
suite ['else' ':' suite]
This change would replace testlist with testlist_safe as the
'in'-expression of a for statement, in line with the definition of
list comprehensions in the Python grammar.
Each of the 'if'-expressions is evaluated in turn (if present), until
one is found False, in which case the 'for'-statement restarts at the
next item from the generator of the 'in'-expression immediately
(the tests are thus short-circuting), or until all are found to be
True (or there are no tests), in which case the suite body is executed.
The behaviour of the 'else'-suite is unchanged.
The intermediate code that is generated is modelled after the
byte-code that is generated for list comprehensions:
def f():
for x in range(10) if x == 1:
print x
would generate:
2 0 SETUP_LOOP 42 (to 45)
3 LOAD_GLOBAL 0 (range)
6 LOAD_CONST 1 (10)
9 CALL_FUNCTION1
12 GET_ITER
13 FOR_ITER28 (to 44)
16 STORE_FAST 0 (x)
19 LOAD_FAST0 (x)
22 LOAD_CONST 2 (1)
25 COMPARE_OP 2 (==)
28 JUMP_IF_FALSE9 (to 40)
31 POP_TOP
3 32 LOAD_FAST0 (x)
35 PRINT_ITEM
36 PRINT_NEWLINE
37 JUMP_ABSOLUTE 13
40 POP_TOP
41 JUMP_ABSOLUTE 13
44 POP_BLOCK
45 LOAD_CONST 0 (None)
48 RETURN_VALUE
where all tests are inserted immediately at the beginning of the
loop body, and jump to a new block if found to be false which pops
the comparision from the stack and jumps back to the beginning of
the loop to fetch the next item.
Implementation issues
The changes are backwards-compatible, as they don't change the
default behaviour of the 'for'-loop. Also, as the changes that
this PEP proposes don't change the byte-code structure of the
interpreter, old byte-code continues to run on Python with this
addition unchanged.
Implementation
A sample implementation (with updates to the grammar documentation
and a small test case) is available at:
http://sourceforge.net/tracker/index.php?func=detailaid=1492509group_id=5470atid=305470
Copyright
This document has been placed in the public domain.
===
--- Heiko.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
i wanted to suggest this myself. +1 -tomer -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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
Re: PEP-xxx: Unification of for statement and list-comp syntax
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 But that's ugly... -- Felipe. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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
Re: PEP-xxx: Unification of for statement and list-comp syntax
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, that's also why I don't oppose the PEP. -- Felipe. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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 different semantic meanings I know, that's also why I don't oppose the PEP. -- Felipe. I guess the main objections will be that: 1) It doesn't buy you much compared to: for node in tree: if node.haschildren(): do something with node 2) There should be one and preferably only one way to do it. List/genexp comprehensions don't allow larger statement blocks anyway, so that's not a problem for them. George -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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 preferably only one way to do it.
You mean like this:
s = foo + bar
s = 'foo' + 'bar'
s = 'foo' 'bar'
s = '%s%s' % ('foo', 'bar')
This one and only one way stuff is overrated. I don't care how many ways
there are as long as:
1. at least one way is intuitive
2. every way is easily comprehendible (readable, no side effects, etc)
Now 'one way to do it' is a good mantra for keeping language complexity down
and achieving the second goal. But it needs to be flexible. The proposed
syntax is short, intuitive, and consistent with comprehension/generator
syntax. I'd say it's entirely in keeping with a number of rules which
trump 'one way':
Beautiful is better than ugly.
Flat is better than nested.
Readability counts.
Special cases aren't special enough to break the rules. (proposal eliminates
the current special case for comprehensions/generators)
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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 negative) pronouncement, so we have it on the record. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
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 listcomps and regular statements. This listcomp: [ x for x in y ] is, by definition, semantically equivalent to this (except it's an expression instead of a statement): for x in y: _.append(x) If you have two fors in the listcomp, the second for is equivalent to a nested for. This: [ x for y in z for x in y ] is, by defintion, equivalent to this: for y in z: for x in y: _.append(x) Likewise, an if gets its own nested block in the equivalent statements. This: [ x for x in y if x is not None ] is, by definition, equivalent to this: for x in y: if x is not None: _.append(x) In other words, each for and if in a listcomp is equivalent to a nested block in a regular statement. There's a regular way to nest, and listcomp way, and they're separate. This PEP suggests we should mix them up--now *that's* a special case. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
