Greg Ewing wrote:
> So the reasons for keeping the comprehension notations
> are (a) slightly more convenient syntax and (b) maybe
> a bit faster.
Yes, I was actually agreeing with you on that point (I just got
sidetracked on a couple of technical quibbles, so my agreement may not
have been clea
Nick Coghlan wrote:
> There is no function call per loop even when using a
> generator expression - a generator function is implicit defined, and
> then called once to instantiate the generator.
You're right -- I must have been half-thinking of
map() at the time. Resuming the generator ought to
Greg Ewing wrote:
> Russell E. Owen wrote:
>> I would personally be happy lose set comprehensions and just use
>> generator expressions for all comprehension-like tasks.
>
> One advantage of the comprehension syntaxes is that the
> body can be inlined instead of relegated to a lambda,
> saving th
Russell E. Owen wrote:
> I would personally be happy lose set comprehensions and just use
> generator expressions for all comprehension-like tasks.
One advantage of the comprehension syntaxes is that the
body can be inlined instead of relegated to a lambda,
saving the overhead of a Python functio
In article <[EMAIL PROTECTED]>,
Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Russell E. Owen" <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > > ...one could make the argument that TOOTDI says that literals and
> > > generators
"Russell E. Owen" <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> > ...one could make the argument that TOOTDI says that literals and
> > generators + constructors are the only reasonable options.
> > Comprehensions save perhaps 5 char
In article <[EMAIL PROTECTED]>,
Josiah Carlson <[EMAIL PROTECTED]> wrote:
> ...one could make the argument that TOOTDI says that literals and
> generators + constructors are the only reasonable options.
> Comprehensions save perhaps 5 characters over the constructor method,
> and may be a bit fas
Brandon Craig Rhodes <[EMAIL PROTECTED]> wrote:
> Joachim König <[EMAIL PROTECTED]> writes:
>
> > ... could someone enlighten me why
> >
> > {,}
> >
> > can't be used for the empty set, analogous to the empty tuple (,)?
>
> And now that someone else has broken the ice regarding questions that
>
>> What would a registry of tranformation algorithms buy us compared to a
>> module with transformation functions?
>
> Easier registering of custom transformations. Without a registry, you'd have
> to monkey-patch a module.
Or users would have to invoke the module directly.
I think a convention
Thanks, you're right, I've fixed it.
On 6/19/07, Eric V. Smith <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I've written up a comprehensive status report on Python 3000. Please read:
> >
> > http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>
> I think this sentence:
>
> "Python
Guido van Rossum wrote:
> I've written up a comprehensive status report on Python 3000. Please read:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=208549
I think this sentence:
"Python 2.6 will contain backported versions of many Py3k features,
either enabled through __future__ statemen
Benji York schrieb:
> Joachim König wrote:
>> could someone enlighten me why
>>
>> {,}
>>
>> can't be used for the empty set, analogous to the empty tuple (,)?
>
> Partially because (,) is not the empty tuple, () is.
Oh, yes, of course. I was thinking of (x) vs. (x,), and that the comma
after the l
Joachim König <[EMAIL PROTECTED]> writes:
> ... could someone enlighten me why
>
> {,}
>
> can't be used for the empty set, analogous to the empty tuple (,)?
And now that someone else has broken the ice regarding questions that
have probably been exhausted already, I want to comment that Python 3
Georg Brandl wrote:
> Walter Dörwald schrieb:
>> Georg Brandl wrote:
>>> Nick Coghlan schrieb:
Georg Brandl wrote:
> Guido van Rossum schrieb:
>> I've written up a comprehensive status report on Python 3000. Please
>> read:
>>
>> http://www.artima.com/weblogs/viewpost.jsp?
Joachim König wrote:
> could someone enlighten me why
>
> {,}
>
> can't be used for the empty set, analogous to the empty tuple (,)?
Partially because (,) is not the empty tuple, () is.
--
Benji York
http://benjiyork.com
___
Python-3000 mailing list
P
Walter Dörwald schrieb:
> Georg Brandl wrote:
>> Nick Coghlan schrieb:
>>> Georg Brandl wrote:
Guido van Rossum schrieb:
> I've written up a comprehensive status report on Python 3000. Please read:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=208549
Thank you! Now I h
Guido van Rossum schrieb:
> I've written up a comprehensive status report on Python 3000. Please read:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>
>
Nice summary, thanks.
I'm sure it has been proposed before (and I've googled for it but did
not find it),
but could someone en
On 2007-06-19 14:40, Walter Dörwald wrote:
> Georg Brandl wrote:
A minuscule nit: the rot13 codec has no library equivalent, so it won't be
supported anymore :)
>>> Given that there are valid use cases for bytes-to-bytes translations,
>>> and a common API for them would be nice, does it
Georg Brandl wrote:
> Nick Coghlan schrieb:
>> Georg Brandl wrote:
>>> Guido van Rossum schrieb:
I've written up a comprehensive status report on Python 3000. Please read:
http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>>> Thank you! Now I have something to show to interest
Nick Coghlan schrieb:
> Georg Brandl wrote:
>> Guido van Rossum schrieb:
>>> I've written up a comprehensive status report on Python 3000. Please read:
>>>
>>> http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>>
>> Thank you! Now I have something to show to interested people except "read
>
Georg Brandl wrote:
> Guido van Rossum schrieb:
>> I've written up a comprehensive status report on Python 3000. Please read:
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>
> Thank you! Now I have something to show to interested people except "read
> the PEPs".
>
> A minuscule n
21 matches
Mail list logo