Re: [Python-Dev] 2.5 schedule
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 things in ASAP to get more testing. I should probably check in my perf patch for speeding up function calls. It would be great if someone picked that up in the sprint and polished it off. The last version I posted should work in debug and normal modes, adds some simple profiling. i think the only thing that it didn't have that Martin requested was more inlining of PyCFunction_CallMethod(?). I'm not sure if that would be faster or not. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] zlib module doesn't build - inflateCopy() not found
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 allows a developer to store the state of the (de)compressor at a certain point of the input stream in order to more efficiently compress data sharing some identical header, or to more efficiently seek inside compressed data. """ The submitter first posted this message to c.l.p: http://groups.google.com/group/comp.lang.python/msg/13f8ce4057162ad5 Apparently, one application is to take a snapshot of a gzip file that is being created, then add to it, and if that fails (e.g. because the size of the CD would be exceeded), truncate it to back to the snapshot (and then close the zlib stream). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
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. Nevertheless, I still think that putting out an alpha during or right before a major sprint is awkward at best. My testing is more focused on alpha releases than the trunk, and I think other people work similarly. Except for Anthony, the responses you've gotten to this surprising change have been negative; this doesn't seem in keeping with our usual decision-making process. BTW, the PEP on python.org hasn't been updated. Please post the current schedule here. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
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 more >> testing. > > Nevertheless, I still think that putting out an alpha during or right > before a major sprint is awkward at best. My testing is more focused on > alpha releases than the trunk, and I think other people work similarly. > Except for Anthony, the responses you've gotten to this surprising > change have been negative; this doesn't seem in keeping with our usual > decision-making process. Moving the alpha release from after a weekend to before a weekend is a bit of a hassle for me, too. I'd hoped to have the functional->functool move done this weekend, but wasn't too worried about getting it finished because I had next weekend as a fallback. Now it appears I'll need to find time to do it sometime this week instead. That's certainly possible, but it's somewhat inconvenient. We don't all get to do Python-related things on work time ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
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 get things in ASAP to get more> testing.Nevertheless, I still think that putting out an alpha during or right before a major sprint is awkward at best. My testing is more focused onalpha releases than the trunk, and I think other people work similarly.Except for Anthony, the responses you've gotten to this surprising change have been negative; this doesn't seem in keeping with our usualdecision-making process.Allow me to pitch in my support for speeding up the releases, then. I don't believe alpha releases (of Python) get serious testing. They wet appetites, but until the feature-freeze it's really too much in flux to even worry about extensive testing. Speeding up the releases makes sense to me, considering how little ruckus they've made so far (in spite of two rather complex internal changes), and it also means people get their hands on a beta -- good testing material -- that much sooner. An acceptable (to me) alternative would be to skip alpha3. The biggest change is Martin's rewrite of various os.* methods, which IMHO isn't really that big a deal (it's not *supposed* to change too many semantics, anyway :) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 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():
as syntactic sugar for:
for node in tree:
if not node.haschildren():
continue
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=detail&aid=1492509&group_id=5470&atid=305470
Copyright
This document has been placed in the public domain.
===
--- Heiko.
___
Python-Dev mailing list
[email protected]
http://mail.pytho
Re: [Python-Dev] zlib module doesn't build - inflateCopy() not found
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 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 allows a developer to store the > state of the (de)compressor at a certain point of the > input stream in order to more efficiently compress data > sharing some identical header, or to more efficiently > seek inside compressed data. > """ > > The submitter first posted this message to c.l.p: > > http://groups.google.com/group/comp.lang.python/msg/13f8ce4057162ad5 > > Apparently, one application is to take a snapshot of a gzip > file that is being created, then add to it, and if that fails > (e.g. because the size of the CD would be exceeded), truncate > it to back to the snapshot (and then close the zlib stream). > > Regards, > Martin > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp 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 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():
>
>
> as syntactic sugar for:
>
> for node in tree:
> if not node.haschildren():
> continue
>
>
> 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 o
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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"), but I guess it's superfluous to discuss this if you're -1. > Also, it would be a parsing conflict for the new conditional > expressions (x if T else y). It isn't, if you change the grammar to use testlist_safe as the 'in'-expression, just as is used for list comprehensions. As I've said in the PEP, I've created a patch that implements this, and Python's test suite passes cleanly (except for a little buglet in test_dis, which stems from the fact that the generated byte-code for a for-loop is slightly altered by this patch). > 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 form of mail on python-dev), so that's why I posted this. But, if I've really repeated things that were proposed before, feel free to ignore this. --- Heiko. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
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-day basis? Maybe that doesn't qualify as rigorous testing. I've been doing that for several years. I can only remember once or twice needing to fall back to something less bleeding edge for a short while. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
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 repository as the main Python interpreter on a day-to-day basis? Maybe thatdoesn't qualify as rigorous testing. I've been doing that for severalyears. I can only remember once or twice needing to fall back to something less bleeding edge for a short while.Sure, that counts. You only count as one, though (and so do I) -- and neither of us is actually using an alpha release :-) I was talking about the testing an alpha release attracts, in the wider population than just python-dev subscribers. The fact that much testing goes on between releases as well makes the alphas even less important. Wetting the appetites and soliciting feedback on the major features is what they're for, in my eyes. -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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 form of > mail on python-dev), so that's why I posted this. But, if I've really > repeated things that were proposed before, feel free to ignore this. 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 the PEP and explain that Guido's already rejected it. Steve -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-compsyntax
"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.haschildren(): > > >as syntactic sugar for: > > for node in tree: > if not node.haschildren(): > continue > 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? tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-compsyntax
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 read and understand in the long run. I find: for x in range(10): if not x % 2: print "Another even number:", print x ... print "Finished processing the even number" a lot harder to read and understand than: for x in range(10): if x % 2: continue print "Another even number:", print x ... print "Finished processing the even number" because with the latter it's much more obvious for me how the flow of control in the indented block is structured (and to what part of the loop the condition applies, namely to the whole loop body). That's why I'd prefer the "combination" of the two as: for x in range(10) if not x % 2: print "Another even number:", print x ... print "Finished processing the even number" because the logic is immediately obvious (at least if you find the logic to be obvious when reading list comprehensions, simply because the format is similar), and there's no extra indentation (as in your example), which makes the block, as I said, a lot easier to parse for my brain. But, probably, that's personal preference. --- Heiko. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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 the PEP and explain that Guido's already > rejected it. I'll submit the PEP tomorrow, after I've reworded it slightly. I'll also add Guido's rejection notice to the PEP, so that a number can be assigned to it properly and it can be added to the PEP list on python.org. --- Heiko. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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 current trunk, or just in some form of >>mail on python-dev), so that's why I posted this. But, if I've really >>repeated things that were proposed before, feel free to ignore this. > > > 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 the PEP and explain that Guido's already > rejected it. > > Steve I'd like to second Steve's point. I'm impressed by the thoroughness and organization of the PEP. 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. -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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 more to this "syntactic sugar" than just source code compression. 1) It unifies the syntax for list comprehensions and for loops, which use the same keywords (and are thus identified easily). Basically, you can then think of a for-loop as a list comprehension which evaluates a suite instead of an expression, and doesn't store the evaluated items, or vice versa, which at the moment you can't, because of the difference in setup. 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. 3) Generally, indentation, as Terry J. Reed suggested, isn't always good. If the body of the loop is more than a few lines long (which happens more often than not in my code), extra indentation is bound to confuse me. That's why I use "if not : continue" at the moment, so that I don't need extra indentation. If I could just append the condition to the loop to get it out of the way (just as you do with a list comprehension), I save the obnoxious "if not : continue" (which destroys my read flow of the body somewhat too), and still get the same behaviour without any extra (errorprone, in my eyes) indentation. Anyway, it's fine if Guido says this is -1. I don't need to discuss this, as I guess it's a pretty futile attempt to get people to consider this against Guido's will. I just found this to be something I'd personally longed for for a long time, and had time free today, so I thought I'd just implement it. ;-) And, additionally, nobody's keeping me from making my own Python tree where I can keep this patch for my very personal scripts where I don't need to have interoperability. This is open source, isn't it? ;-) --- Heiko. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46043 - peps/trunk/pep-0356.txt
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 improved, so the schedule > may work. It's just a call for the release manager really, I guess. If there's no functionality changes, what would be the problem with putting it in post-alpha? Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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. > > I know about this, but generally, I find there's more to this "syntactic > sugar" than just source code compression. > > 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... for ... in ... [if ...] [for ... in ... [if ...]]*: If I remember correctly, this was why it wasn't accepted before; because actual unification is ugly. Further, because quite literally the only difference is some indentation, a colon, and a line break, the vast majority of people would likely stick with "the one obvious way to do it", which has always worked. > 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. Not everyone finds list comprehensions easy to read. > 3) Generally, indentation, as Terry J. Reed suggested, isn't always good. If > the body of the loop is more than a few lines long (which happens more often > than not in my code), extra indentation is bound to confuse me. That's why I [snip] I feel for you; I really do. I've done the same thing myself. However, I don't believe that it is a good practice, in general, and I don't think that syntax should support this special case. > And, additionally, nobody's keeping me from making my own Python tree where I > can keep this patch for my very personal scripts where I don't need to have > interoperability. This is open source, isn't it? ;-) Do whatever you want. Good luck with keeping your patches current against whatever Python version you plan on using. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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 stuff if something_about(x)] for the very reason that it makes them easier to read. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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... > > for ... in ... [if ...] [for ... in ... [if ...]]*: > > If I remember correctly, this was why it wasn't accepted before; because > actual unification is ugly. This syntax is ugly, that's why the PEP doesn't try to make a case for this. But, one level equivalence to list comprehensions isn't bad, again, at least in my eyes. > > 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. > > 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? filter/itertools/any of the proposed "workarounds" in the PEP would also work for list-comprehensions). > > 3) Generally, indentation, as Terry J. Reed suggested, isn't always good. > > If the body of the loop is more than a few lines long (which happens more > > often than not in my code), extra indentation is bound to confuse me. > > That's why I > > [snip] > > I feel for you; I really do. I've done the same thing myself. However, > I don't believe that it is a good practice, in general, and I don't > think that syntax should support this special case. Why isn't this good practice? It's not always sensible to refactor loop code to call methods (to make the loop body shorter), and it's a pretty general case that you only want to iterate over part of a generator, not over the whole content. Because of this, list comprehensions grew the 'if'-clause. So: why doesn't the for-loop? --- Heiko. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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.haschildren(): > 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. --- Heiko. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for stateme nt and list-comp syntax
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 multiple lines, e.g. > >l = [foo(x) > for x in stuff >if something_about(x)] > > for the very reason that it makes them easier to read. You can also do the same here (by using normal bracketing): for in ( ) if ( and and ): foo(x) --- Heiko. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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 ones without -- exactly the opposite of what you seem to prefer. Also, I don't find an extra indendation level to be a problem at all, unless the code under it is more than a screen long -- in which case you've got big readability problems already. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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 longer in-line? The point of doing that eludes me... -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
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 useful because they're expressions rather than statements. Being expressions, they need if-clauses in order to be able to conditionally include items in the list. LCs with if-clauses don't *have* to be hard to read; you just need to lay them out on separate lines, as you would do when writing nested statements. With a for-statement, there is no need for if-clauses, since you can use a nested if-statement to get the same effect. The only possible reason for wanting an if-clause would be so that you can write it on the same line, which reduces readability for no corresponding benefit. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
