On Apr 23, 2006, at 8:28 AM, Bill Birch wrote:
> On Sun, 23 Apr 2006 12:53 am, Fredrik Lundh wrote:
>> Guido van Rossum wrote:
>>> It's an interesting idea; it's been brought up before but nobody
>>> AFAIK
>>> has ever implemented it. I like the scoping requirement.
>>
>> can we add support for
On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Edward C. Jones wrote:> I suggest a singleton object "UseForbidden" ("Py_UseForbidden" in C).It should be called "Mu". :-)Although such an object could cause a lot of pain to
debuggers and other such introspective code.Actually this sounds a lot lik
Greg Wilson wrote:
>One of the reasons I'd like native syntax for sets is that I'd like set
>comprehensions:
>
>a = {b for b in c where b > 0}
>
>
>
>
This is no good. That form could as easily represent a frozenset
comprehension or dict comprehension. It buys us nothing over the clear
a
On 4/24/06, Guido van Rossum wrote:
> [...] Python has 'in' for ',
Isn't it an inconsistency that Python admits 'in' as a concise english
equivalent to ∈ (and 'not in' for ∉) while λ requires painful spelling out as
'lambda' ?
NB : this mail means to bring to mind the possibility of supportin
> On Tue, 25 Apr 2006, Raymond Hettinger wrote:
> Embrace genexps -- they are a path to uniform and clear expression
> across a wide range of datatypes.
> ...
> Avoid punctuation and funky syntax -- they burden the learning curve,
> they do not generalize well, they challenge parsers (both human an
On Tue, Apr 25, 2006, Kevin Jacobs <[EMAIL PROTECTED]> wrote:
>
> Actually this sounds a lot like a signaling Not-a-number (sNaN)
> from IEEE754. One can pass around a sNaN, but any use will raise a
> (numeric) exception. Similarly, you want a signaling Not-an-Object
> (sNaO) that also doesn't li
Greg Wilson <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 25 Apr 2006, Raymond Hettinger wrote:
> > Embrace genexps -- they are a path to uniform and clear expression
> > across a wide range of datatypes.
> > ...
> > Avoid punctuation and funky syntax -- they burden the learning curve,
> > they do not
> > Greg Wilson <[EMAIL PROTECTED]> wrote:
> > Do you have any data to back up these assertions? Something like
> > http://mail.python.org/pipermail/python-dev/2000-July/006427.html?
> Josiah Carlson:
> Assuming programmer sanity, how can naming the data type in the
> construction of the data typ
On 4/25/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
...
> If list comprehensions didn't come first (and even though list
> comprehensions came first), I would argue that there should only be
> generator expressions. If one wants a list comprehension, one should
> use list(genexp). Obviously
On 4/25/06, Boris Borcic <[EMAIL PROTECTED]> wrote:
> On 4/24/06, Guido van Rossum wrote:
> > OTOH mathematicians (whether in high school or not) write things like
> > {x | 2 < x < 10}, which is of course the origin of our list
> > comprehensions and generator expressions [...]
> Most of the t
On 4/25/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Greg Wilson <[EMAIL PROTECTED]> wrote:
> > > On Tue, 25 Apr 2006, Raymond Hettinger wrote:
> > > Avoid punctuation and funky syntax -- they burden the learning curve,
> > > they do not generalize well, they challenge parsers (both human and
>
"Alex Martelli" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 4/25/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> ...
>> If list comprehensions didn't come first (and even though list
>> comprehensions came first), I would argue that there should only be
>> generator express
On 4/25/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> I can see an argument that the appropriate
> response to more types is a compensating decrease in syntax
> (as in dropping [xx] as a synonym for list(xx)) rather than adding
> more.
Great. Except then how would you create a collection in the fi
[Guido]
>>> OTOH mathematicians (whether in high school or not) write things like
>>> {x | 2 < x < 10}, which is of course the origin of our list
>>> comprehensions and generator expressions [...]
[Boris Borcic]
>> Most of the time they use it as "filter" and write something like
>>
>> {x ∈ S st.
On 4/25/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 4/25/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>...
> > If list comprehensions didn't come first (and even though list
> > comprehensions came first), I would argue that there should only be
> > generator expressions. If one wants a
Raymond Hettinger wrote:
> Greg Wilson wrote:
>
>> One of the reasons I'd like native syntax for sets is that I'd like set
>> comprehensions:
>>
>>a = {b for b in c where b > 0}
>>
>>
>>
>>
>
> This is no good. That form could as easily represent a frozenset
> comprehension or dict compre
I think perhaps I'm the the only one who's missing the big joke. At any
rate, I'm going to go ahead and speak up: The Emperor Has No Cloths!
Adding a literal notation for sets may or may not be a good idea (it's
certainly not *necessary*). Adding a literal notation for every built-in
data structur
On Tue, Apr 25, 2006, Brett Cannon wrote:
>
> I'll toss in my straw; I have no issue losing listcomps and favoring
> ``list(genexp)``. TOOWTDI since there is not that huge of a "simple
> over complex" savings. Probably never thought about this since I
> really got into Python when listcomps were
Aahz wrote:
>There are [at least] two separate issues being discussed here, and I
>think that's confusing things. From my POV, the issue about whether
>listcomps per se go away in Python 3.0 is completely separate from the
>issue of whether sets get special literal syntax.
>
>
For the record, I
I think that a significant motivation for people that propose set
literals is that the following is just plain ugly:
s = set([1,2,3])
It seems much more natural to write:
s = set(1, 2, 3)
However, it is fairly common to want to build a set from a collection,
an iterator, or a genexp.
20 matches
Mail list logo
