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
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
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
+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
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
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(): > 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
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(): > > > as syntactic sugar for: > > for node in tree: > if not node.haschildren(): > continue > 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(): ? -- 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():
>>>
>>>
>>>as syntactic sugar for:
>>>
>>>for node in tree:
>>>if not node.haschildren():
>>>continue
>>>
>
> [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
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
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
George Sakkis wrote:
> Em Dom, 2006-05-21 às 17:11 +0200, Heiko Wundram escreveu:
>> for node in tree if node.haschildren():
>>
>>
>> as syntactic sugar for:
>>
>> for node in tree:
>> if not node.haschildren():
>> continue
>>
[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
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()): > > > > > > > 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(): 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
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()): > > > > 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
> 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()): > 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 17:11 +0200, Heiko Wundram escreveu: > for node in tree if node.haschildren(): > > > as syntactic sugar for: > > for node in tree: > if not node.haschildren(): > continue > 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()): But that's ugly... -- Felipe. -- 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
i wanted to suggest this myself. +1 -tomer -- http://mail.python.org/mailman/listinfo/python-list
