Heiko Wundram wrote:
> Am Montag 22 Mai 2006 01:59 schrieb Josiah Carlson:
> > Not everyone finds list comprehensions easy to read.
>
> Why has Python added list-comprehensions, then? (or at least, why has Python
> added the 'if'-expression to list-comprehensions if they're hard to read?
LCs are
Heiko Wundram wrote:
> You can also do the same here (by using normal bracketing):
>
> for in (
>
>) if ( and
> and
> ):
So you want to be able to write the if in-line,
and then format it so that it's no lo
Heiko Wundram wrote:
> Yes, of course. Read my replies to Terry J. Reed, to Josiah Carlton, to
> Talin,
> to see why I chose to compare it to the 'continue' syntax.
I saw them. Your brain must be wired very differently
to mine, because I find loops with a continue in them
harder to follow than
Am Montag 22 Mai 2006 02:46 schrieben Sie:
> Heiko Wundram wrote:
> > 2) Just as I've replied to Terry J. Reed, if you find list comprehensions
> > easy to read, you're also bound to be able to understand what "for
> > in if :" does, at least AFAICT.
>
> I tend to write non-trivial LCs on multipl
Am Montag 22 Mai 2006 02:22 schrieb Greg Ewing:
> Heiko Wundram wrote:
> > for node in tree:
> > if not node.haschildren():
> > continue
> >
>
> Er, you do realise that can be written more straightforwardly as
>
>for node in tree:
> if node.haschild
Am Montag 22 Mai 2006 01:59 schrieb Josiah Carlson:
> > 1) It unifies the syntax for list comprehensions and for loops, which use
> > the
>
> No, it /partially unifies/ list comprehensions and for loops. To
> actually unify them, you would need to allow for arbitrarily nested fors
> and ifs...
>
>
Heiko Wundram wrote:
> 2) Just as I've replied to Terry J. Reed, if you find list comprehensions
> easy
> to read, you're also bound to be able to understand what "for in
> if :" does, at least AFAICT.
I tend to write non-trivial LCs on multiple lines, e.g.
l = [foo(x)
for x in stuf
Heiko Wundram wrote:
> for node in tree:
> if not node.haschildren():
> continue
>
Er, you do realise that can be written more straightforwardly as
for node in tree:
if node.haschildren():
--
Greg
_
Heiko Wundram <[EMAIL PROTECTED]> wrote:
>
> Am Sonntag 21 Mai 2006 22:11 schrieb Talin:
> > As a general guideline, I've noticed that proposals which are purely
> > syntactic sugar are unlikely to be accepted unless there is some
> > additional benefit other than just compression of source code.
Steve Holden wrote:
> Will it be acceptable to add new (performance) changes between Alpha 3
> and beta 1, or would developers prefer to put a fourth alpha in to the
> schedule?
>
> The intention is there should be no major functionality added by the
> sprint, simply that performance should be im
Am Sonntag 21 Mai 2006 22:11 schrieb Talin:
> As a general guideline, I've noticed that proposals which are purely
> syntactic sugar are unlikely to be accepted unless there is some
> additional benefit other than just compression of source code.
I know about this, but generally, I find there's mo
Steven Bethard wrote:
> On 5/21/06, Heiko Wundram <[EMAIL PROTECTED]> wrote:
>
>>Am Sonntag 21 Mai 2006 17:38 schrieb Guido van Rossum:
>>
>>>This was proposed and rejected before.
>>
>>I haven't seen this proposed before (at least not in PEP form, or with a
>>working implementation against the cu
Am Sonntag 21 Mai 2006 18:08 schrieb Steven Bethard:
> While this has been proposed before, I'd like to thank you for putting
> together a full PEP and a working implementaiton. I think you should
> still submit the PEP, if for nothing else so that when the issue comes
> up again, we can point to
Am Sonntag 21 Mai 2006 20:31 schrieb Terry Reedy:
> Isn't this the same as
>
> for node in tree:
> if node.haschildren():
>
>
> so that all you would save is ':\n' and the extra indents?
Saving an extra indent and the ':\n' makes it quite a bit easier for me to
rea
"Heiko Wundram" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>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.haschildr
On 5/21/06, Heiko Wundram <[EMAIL PROTECTED]> wrote:
> Am Sonntag 21 Mai 2006 17:38 schrieb Guido van Rossum:
> > This was proposed and rejected before.
>
> I haven't seen this proposed before (at least not in PEP form, or with a
> working implementation against the current trunk, or just in some f
On 5/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Thomas> Allow me to pitch in my support for speeding up the releases,Thomas> then. I don't believe alpha releases (of Python) get seriousThomas> testing.Is there nobody else out there that uses Python built from the current svn
re
Thomas> Allow me to pitch in my support for speeding up the releases,
Thomas> then. I don't believe alpha releases (of Python) get serious
Thomas> testing.
Is there nobody else out there that uses Python built from the current svn
repository as the main Python interpreter on a day-to-
Am Sonntag 21 Mai 2006 17:38 schrieb Guido van Rossum:
> -1. The contraction just makes it easier to miss the logic.
I actually don't think so, because it's pretty synonymous to what 'if' means
for list comprehensions which use the same keywords (that's why I called
it "unification of ... syntax
-1. The contraction just makes it easier to miss the logic.
Also, it would be a parsing conflict for the new conditional
expressions (x if T else y).
This was proposed and rejected before.
--Guido
On 5/21/06, Heiko Wundram <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> The following PEP tries to make
Then options 2 and 3 are both fine.
Not compiling at all is *not*, so if nobody has time to implement 2 or
3, we'll have to do 4.
--Guido
On 5/21/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > What was the purpose of the patch in the first place?
>
> I don't fully
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-Modifie
On 5/21/06, Aahz <[EMAIL PROTECTED]> wrote:
On Sun, May 21, 2006, Neal Norwitz wrote:> On 5/19/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:Remember, the feature freeze isn't until beta1. New stuff can still go
>>in after the next alpha, before beta1.>> I agree. Of course, it's preferable to ge
Aahz wrote:
> On Sun, May 21, 2006, Neal Norwitz wrote:
>> On 5/19/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
>>> Remember, the feature freeze isn't until beta1. New stuff can still go
>>> in after the next alpha, before beta1.
>> I agree. Of course, it's preferable to get things in ASAP to get
On Sun, May 21, 2006, Neal Norwitz wrote:
> On 5/19/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
>>
>>Remember, the feature freeze isn't until beta1. New stuff can still go
>>in after the next alpha, before beta1.
>
> I agree. Of course, it's preferable to get things in ASAP to get more
> testing
Guido van Rossum wrote:
> What was the purpose of the patch in the first place?
I don't fully understand it. I guess the objective of the patch
was to expose the feature of the underlying library. The SF
submission then gives the rationale for that feature as
"""
Copying a
(de)compression object
On 5/19/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> Remember, the feature freeze isn't until beta1. New stuff can still go
> in after the next alpha, before beta1.
>
> And pure speedup related items aren't likely to cause feature changes
> (I hope)
I agree. Of course, it's preferable to get th
27 matches
Mail list logo
