on 2009-03-27 05:17 P.J. Eby said the following:
At 04:08 PM 3/27/2009 +1300, Greg Ewing wrote:
You can't expect to improve something like that by
stuffing yield-from into the existing framework, because
the point of yield-from is to render the framework
itself unnecessary.
But it doesn't. Yo
on 01.04.2007 17:23 Guido van Rossum said the following:
> It's out of character for the standard library, since (regardless of
> whether it's implemented in Python or part of the standard library)
> it's a stand-alone utility. I don't see much use for this as a library
> module.
I use it as a lib
on 31.03.2007 22:39 Guido van Rossum said the following:
> If you ask me, having it hosted by Trent is probably more helpful for
> its popularity than putting it in the Python source distro; the Tools
> directory is mostly a poorly-maintained collection of trivia I wrote
> many years ago that is no
on 13.07.2006 10:26 Mike Brown said the following:
> Stefan Rank wrote:
>> on 12.07.2006 07:53 Martin v. Löwis said the following:
>>> Anthony Baxter wrote:
>>>>> The right thing to do is IRIs.
>>>> For 2.5, should we at least detect that it's un
on 12.07.2006 07:53 Martin v. Löwis said the following:
> Anthony Baxter wrote:
>>> The right thing to do is IRIs.
>> For 2.5, should we at least detect that it's unicode and raise a
>> useful error?
>
> That can certainly be done, sure.
>
> Martin
That would be great.
And I agree that updati
Hi,
urllib.quote fails on unicode strings and in an unhelpful way::
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib
>>> urllib.quote('a\xf1a')
'a%F1a'
>>> url
on 04.05.2006 16:18 Paul Moore said the following:
> On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> My inclination was to have a PlatformPath subclass that accepted 'os', 'sep'
>> and 'extsep' keyword arguments to the constructor, and provided the
>> appropriate 'sep' and 'extsep' attributes
on 04.05.2006 14:57 Nick Coghlan said the following:
> Mike Orr wrote:
>> Intriguing idea, Noam, and excellent thinking. I'd say it's worth a
>> separate PEP. It's too different to fit into PEP 355, and too big to
>> be summarized in the "Open Issues" section. Of course, one PEP will
>> be rejec
on 16.02.2006 06:59 Alex Martelli said the following:
> On Feb 15, 2006, at 9:51 AM, Barry Warsaw wrote:
>
>> On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:
>>
>>> Regarding open vs. opentext, I'm still not sure. I don't want to
>>> generalize from the openbytes precedent to openstr or
on 03.02.2006 00:16 Delaney, Timothy (Tim) said the following:
> Andrew Koenig wrote:
>>> I definately agree with the 0c664 octal literal. Seems rather more
>>> intuitive.
>> I still prefer 8r664.
> The more I look at this, the worse it gets. Something beginning with
> zero (like 0xFF, 0c664) immed
on 27.01.2006 11:16 Paul Moore said the following:
> [...]
>>> Arguably, Path objects should always maintain an absolute path - there
>>> should be no such thing as a relative Path. So you would have
>> you realise that one might need and/or want to represent a relative path?
>
> Absolutely. But n
on 26.01.2006 16:34 Aaron Bingham said the following:
> Stefan Rank wrote:
>> on 26.01.2006 14:15 Paul Moore said the following:
>> [snip]
>>
>>> Arguably, Path objects should always maintain an absolute path - there
>>> should be no such thing as a relative
on 26.01.2006 14:15 Paul Moore said the following:
[snip]
>
> Also note that my example Path("C:", "Windows", "System32") above is
> an *absolute* path on Windows. But a relative (albeit stupidly-named
> :-)) path on Unix. How would that be handled?
wrong, Path("C:", "Windows", "System32") is a r
on 18.10.2005 19:17 Antoine Pitrou said the following:
>>What would this mythical block statement look like that would make
>>properties easier to write than the above late-binding or the subclass
>>Property recipe?
>
> I suppose something like:
>
> class C(object):
> x = prop:
>
14 matches
Mail list logo
