Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Eric Nieuwland wrote: Martin v. Löwis wrote: That's not the full syntax. The full syntax is [ for in ] where can be an arbitrary expression: and, or, lambda, +, -, ... can be a list of expression, except for boolean and relational expressions (but I think this is further constrained semantically) list a list of tests is optional, and can be another for or if block Aren't these names a bit mixed up w.r.t. what's in that position? The names come directly from the grammar file (Grammar/Grammar) and thus have multiple uses. Basically ignore the actual names and just consider them placeholders. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Martin v. Löwis wrote: That's not the full syntax. The full syntax is [ for in ] where can be an arbitrary expression: and, or, lambda, +, -, ... can be a list of expression, except for boolean and relational expressions (but I think this is further constrained semantically) list a list of tests is optional, and can be another for or if block Aren't these names a bit mixed up w.r.t. what's in that position? As far as I know is not a test but a function as it produces any value not just True/False is a list of names, not arbitrary expressions is anything which will produce an iterator Or so I've understood so far. So a more complex example is [ lambda a: a[x]+y*z for x,y in A for z in B if x > z] I'm schocked ;-) --eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Eric Nieuwland wrote: The full syntax is: [ f(x) for x in seq if pred(x) ] being allowed to write 'x' instead of 'identity(x)' is already a shortcut, just as dropping the conditional part. That's not the full syntax. The full syntax is [ for in ] where can be an arbitrary expression: and, or, lambda, +, -, ... can be a list of expression, except for boolean and relational expressions (but I think this is further constrained semantically) list a list of tests is optional, and can be another for or if block So a more complex example is [ lambda a: a[x]+y*z for x,y in A for z in B if x > z] (Not that this does what you think it does :-) So that you can write f(x) is just a tiny special case. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
On Monday 2005-03-14 12:42, Eric Nieuwland wrote:
> Gareth McCaughan wrote:
>
> > I'd like it, and my reason isn't "just to save typing".
> > There are two reasons.
> >
> > 1 Some bit of my brain is convinced that [x in stuff if condition]
> > is the Right Syntax and keeps making me type it even though
> > I know it doesn't work.
> >
> > 2 Seeing [x for x in stuff if condition] triggers my internal
> > duplicated-stuff alarm, and it's distracting, in the same sort
> > of way as it's distracting in C or C++ seeing
>
> The full syntax is:
> [ f(x) for x in seq if pred(x) ]
> being allowed to write 'x' instead of 'identity(x)' is already a
> shortcut, just as dropping the conditional part.
>
> Remember we're doing set theory stuff here. IMHO we should follow its
> notation conventions as much as we can.
I'm well aware of what the full syntax is; being allowed to
write "x" instead of "identity(x)" is *not* a "shortcut" but
a perfectly straightforward unexceptional instance of the
usual syntax; list comprehensions already have neither the
syntax nor the semantics of set-theorists' comprehensions;
and in fact no set theorist would be at all troubled by seeing
{ x in S : predicate(x) }
which is the nearest equivalent in mathematical notation
for the abbreviated comprehension expressions being discussed.
Other than that, I quite agree :-).
--
g
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
On Monday 2005-03-14 12:09, Alex Martelli wrote: > > On Mar 14, 2005, at 10:57, Gareth McCaughan wrote: > > > of way as it's distracting in C or C++ seeing > > > > Thing thing = new Thing(); > > > > with the type name appearing three times. > > I think you can't possibly see this in C:-), you need a star there in > C++, and you need to avoid the 'new' (just calling Thing() should do it > -- maybe you're commixing with Java?), but still, I do agree it looks > uncool... no doubt a subtle ploy by Java and C++ designers to have you > use, instead, the preferable interface-and-factory idioms such as: Er, sorry about the various slips of detail. And I don't even use Java. Bah! (But it looks even worse without the "new" intervening...) > IThing thing* = thingFactory(); > > rather than declaring and instantiating concrete classes, which is just > _so_ three years ago;-) :-) > Back to the Python world, I don't particularly love [x for x in ...] by > any means, but I surely hope we're not tweaking the syntax for such > tiny gains in the 2.4 -> 2.5 transition. Wasn't 2.5 "supposed to be" > mostly about standard library reorganizations, enhancements, etc? Were > there some MAJOR gains to be had in syntax additions, guess that could > be bent, but snipping the [ for ...] leading part seems just such > a tiny issue. (If the discussion is about 3.0, and I missed the > indication of that, I apologize). When I say I'd like it, I don't mean "we should change it now", only that it would be nice for it to be there. Stability matters more than optimality sometimes, and now may well be such a time. -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Gareth McCaughan wrote: I'd like it, and my reason isn't "just to save typing". There are two reasons. 1 Some bit of my brain is convinced that [x in stuff if condition] is the Right Syntax and keeps making me type it even though I know it doesn't work. 2 Seeing [x for x in stuff if condition] triggers my internal duplicated-stuff alarm, and it's distracting, in the same sort of way as it's distracting in C or C++ seeing The full syntax is: [ f(x) for x in seq if pred(x) ] being allowed to write 'x' instead of 'identity(x)' is already a shortcut, just as dropping the conditional part. Remember we're doing set theory stuff here. IMHO we should follow its notation conventions as much as we can. --eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
On Mar 14, 2005, at 10:57, Gareth McCaughan wrote: of way as it's distracting in C or C++ seeing Thing thing = new Thing(); with the type name appearing three times. I think you can't possibly see this in C:-), you need a star there in C++, and you need to avoid the 'new' (just calling Thing() should do it -- maybe you're commixing with Java?), but still, I do agree it looks uncool... no doubt a subtle ploy by Java and C++ designers to have you use, instead, the preferable interface-and-factory idioms such as: IThing thing* = thingFactory(); rather than declaring and instantiating concrete classes, which is just _so_ three years ago;-) Back to the Python world, I don't particularly love [x for x in ...] by any means, but I surely hope we're not tweaking the syntax for such tiny gains in the 2.4 -> 2.5 transition. Wasn't 2.5 "supposed to be" mostly about standard library reorganizations, enhancements, etc? Were there some MAJOR gains to be had in syntax additions, guess that could be bent, but snipping the [ for ...] leading part seems just such a tiny issue. (If the discussion is about 3.0, and I missed the indication of that, I apologize). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
> - Before anybody asks, I really do think the reason this is requested > at all is really just to save typing; there isn't the "avoid double > evaluation" argument that helped acceptance for assignment operators > (+= etc.), and I find redability is actually improved with 'for'. I'd like it, and my reason isn't "just to save typing". There are two reasons. 1 Some bit of my brain is convinced that [x in stuff if condition] is the Right Syntax and keeps making me type it even though I know it doesn't work. 2 Seeing [x for x in stuff if condition] triggers my internal duplicated-stuff alarm, and it's distracting, in the same sort of way as it's distracting in C or C++ seeing Thing thing = new Thing(); with the type name appearing three times. Incidentally, while it's quite true that you only save 4 characters if you use "x" for your variable name, some of us do sometimes like to use something more informative even as a very local loop-index variable (which is what this basically is). -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Guido van Rossum: > - Before anybody asks, I really do think the reason this is requested > at all is really just to save typing; there isn't the "avoid double > evaluation" argument that helped acceptance for assignment operators > (+= etc.), and I find redability is actually improved with 'for'. For me, the main motivation is to drop an unnecessarily repeated identifier. If you repeat something there is a chance that one of the occurrances will be wrong which is one reason behind the Don't Repeat Yourself principle. The reader can more readily see that this is a filter expression rather than a transforming expression. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
[Nick Coghlan]
> > That 'x in seq' bit still shouts "containment" to me rather than
> > iteration, though.
> >
> > Perhaps repurposing 'from':
> >
> > (x from seq if f(x))
> >
> > That rather breaks TOOWTDI though (since it is essentially new syntax
> > for a for loop). And I have other hopes for the meaning of (x from ()). . .
[Greg Ewing]
> How about:
>
>(for x in seq if f(x))
>
> It still has the word 'for' in it and avoids mentioning
> x more times than necessary.
>
> Although I can't help feeling that it should be some
> other word instead, such as
>
>(all x in seq if f(x))
>
> or
>
>(every x in seq if f(x))
I doubt that we'll find a satisfactory solution for this issue. Here's why:
- We're only talking of a savings of 4 characters (plus two spaces) in
the best case, assuming the identifier can be a single letter (it's
scope is only the current expression anyway).
- Ping's proposal ('x in seq if f(x)') IMO loses for several reasons:
it would be a hugely ambiguous use of 'in', and would cut off a
possible future syntax for conditional expression(*): 'A if T else B'.
- The various improvements on Ping's proposal reduce the amount of
typing saved even more ('every' is actually longer than 'for x').
- Before anybody asks, I really do think the reason this is requested
at all is really just to save typing; there isn't the "avoid double
evaluation" argument that helped acceptance for assignment operators
(+= etc.), and I find redability is actually improved with 'for'.
(*) Pleas stop calling it 'ternary expression'. That doesn't explain
what it means. It's as if we were to refer to the + operator as
'binary expression'.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Nick Coghlan wrote: That 'x in seq' bit still shouts "containment" to me rather than iteration, though. Perhaps repurposing 'from': (x from seq if f(x)) That rather breaks TOOWTDI though (since it is essentially new syntax for a for loop). And I have other hopes for the meaning of (x from ()). . . How about: (for x in seq if f(x)) It still has the word 'for' in it and avoids mentioning x more times than necessary. Although I can't help feeling that it should be some other word instead, such as (all x in seq if f(x)) or (every x in seq if f(x)) -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Jim Jewett wrote: Note that the last x shouldn't have to be x. [x in seq if f(x)] is by far my most common syntax error, and [x for x in seq if f(x)] is always what I want instead. That 'x in seq' bit still shouts "containment" to me rather than iteration, though. Perhaps repurposing 'from': (x from seq if f(x)) That rather breaks TOOWTDI though (since it is essentially new syntax for a for loop). And I have other hopes for the meaning of (x from ()). . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] comprehension abbreviation (was: Adding any() and all())
Barry: > Ping's suggested list comprehension abbreviation, i.e.: >[x in seq if x] == [x for x in seq if x] > might help. Note that the last x shouldn't have to be x. [x in seq if f(x)] is by far my most common syntax error, and [x for x in seq if f(x)] is always what I want instead. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
