Guido van Rossum wrote:
Thanks for the patches! Applied, except for the change to
tokenize.py; instead, I changed test_tokenize.py to use io.StringIO.
--Guido
Glad to have the opportunity to help make the future happen. ;-)
This next one converts unicode literals in tokenize.py and it's t
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
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
>
why does map and filter stay, but reduce leaves?
i understand that some people think that an explicit for-loop is more
understanda
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:
> 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
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
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
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
Gábor Farkas wrote:
> why does map and filter stay, but reduce leaves?
>
> i understand that some people think that an explicit for-loop is more
> understandable, but also many people claim that list-comprehensions are
> more understandable than map/filter.., and map/filter can be trivially
> w
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
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 <[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
Those are valid concerns. I'm cross-posting this to the python-3000
list in the hope that the PEP's author and defendents can respond. I'm
sure we can work something out.
Please keep further discussion on the [email protected] list.
--Guido
On 6/19/07, Chris McDonough <[EMAIL PROTECTED]> wr
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
On 6/19/07, Gábor Farkas <[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
> why does map and filter stay, but reduce leaves?
> i understand that some pe
> > written using list-comprehensions.. so why _reduce_?
>
> Don't worry, it wasn't complete removed. Reduce was moved to functools
Though, really, same question! There are functional equivalents (list
comprehensions) for "map" and "filter", but not for "reduce".
Shouldn't "reduce" stay in the
On 6/19/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > written using list-comprehensions.. so why _reduce_?
> >
> > Don't worry, it wasn't complete removed. Reduce was moved to functools
>
> Though, really, same question! There are functional equivalents (list
> comprehensions) for "map" and "
> > Shouldn't "reduce" stay in the 'built-in' space, while the other two
> > move to "functools"? Or move them all to "functools"? Bizarre
> > recombination, IMO.
>
> Arguing from the standpoint of purity, that, "these functions are
> builtins, why not this other one" isn't going to get you very
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
And, while I'm at it, why isn't there a built-in function called
"output()", which matches "input()", that is, it's equivalent to
import sys
sys.stdout.write(MESSAGE)
It could be easily implemented in terms of the built-in function
called "print". The fact that it's not there is going
On 19-Jun-07, at 10:51 AM, Bill Janssen wrote:
>
> Though, from the standpoint of pragmatism, removing "reduce" from the
> built-in space will break code (*my* code, among others), and leaving
> it in will not affect "purity", as both "map" and "reduce" are being
> left in. So leaving it alone se
A few comments here:
I'd get rid of "readinto", and just make the buffer an optional
argument to "read". If you keep "readinto", why not rename "write" to
"writefrom"?
The "seek" method on RawIOBase is awfully quaint and UNIX-y, what with
the "whence" argument. It could be made considerably mor
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
> map (especially the new iterized version) is a frequently-used
> builtin, while reduce is a rarely-used builtin that requires some
> head-wrapping. It makes sense to me to move it out of builtins.
I've never understood this kind of argument. Because most people
don't program in Python, we
Bill Janssen wrote:
> Though, from the standpoint of pragmatism, removing "reduce" from the
> built-in space will break code (*my* code, among others), and leaving
> it in will not affect "purity", as both "map" and "reduce" are being
> left in. So leaving it alone seems the more Pythonic response
>> 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
On 19-Jun-07, at 12:13 PM, Bill Janssen wrote:
>> map (especially the new iterized version) is a frequently-used
>> builtin, while reduce is a rarely-used builtin that requires some
>> head-wrapping. It makes sense to me to move it out of builtins.
>
> I've never understood this kind of argument
After reading Guido's blog post and noticing his comment about lack of
delegation, I decided to delegate to myself a look at struni and what
tests were failing (which turned out to be a lot).
I just started at the beginning and so that meant looking at
test_anydbm. That's failing because _bsddb.c
Check out what the dbm-based modules do. I believe they use strings
for keys and bytes for values, and if the keys are unicode, it
converts them to UTF-8.
On 6/19/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> After reading Guido's blog post and noticing his comment about lack of
> delegation, I de
On Tuesday 19 June 2007 19:47, Bill Janssen wrote:
> The "seek" method on RawIOBase is awfully quaint and UNIX-y, what with
> the "whence" argument. It could be made considerably more Pythonic by
> splitting it into two methods:
>
> .seek(POS: int)
>
> where positive values for POS are from the
+1 on deciding on keeping builtins built in based on
populuarity within actual source code.
Stats will never be perfect, and nobody can
practically sample all Python code ever written, but
anybody who measures a large codebase to argue for
keeping a builtin built in gets a +1 from me.
Regarding m
Bill Janssen wrote:
> The "seek" method on RawIOBase is awfully quaint and UNIX-y, what with
> the "whence" argument. It could be made considerably more Pythonic by
> splitting it into two methods:
>
> .seek(POS: int)
>
> where positive values for POS are from the beginning of the file, and
>
Gareth McCaughan wrote:
> On Tuesday 19 June 2007 19:47, Bill Janssen wrote:
>
>> The "seek" method on RawIOBase is awfully quaint and UNIX-y, what with
>> the "whence" argument. It could be made considerably more Pythonic by
>> splitting it into two methods:
>>
>> .seek(POS: int)
>>
>> where p
> How would I seek to EOF with your proposal? seek(-0)?
Good point. Though I just grepped all my Python sources, and I never
do that, so presumably the obvious workaround of
seek_eof = lambda fp: fp.seek(-1), fp.nudge(+1)
would be OK for that case.
Bill
_
On Jun 19, 2007, at 2:47 PM, Bill Janssen wrote:
> TextIOBase: this seems an odd mix of high-level and low-level. I'd
> remove "seek", "tell", "read", and "write". Remember that in Python,
> mixins actually work, so that you can provide a file object that
> combines several different I/O classes
35 matches
Mail list logo
