At 09:29 PM 5/29/2010 +0200, Martin v. Löwis wrote:
Am 29.05.2010 21:06, schrieb P.J. Eby:
At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote:
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I can't find any follow-up to this. I don't see any
discussion in PEP
On Sat, May 29, 2010 at 12:29, "Martin v. Löwis" wrote:
> Am 29.05.2010 21:06, schrieb P.J. Eby:
>>
>> At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote:
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I can't find any follow-up to this. I don't s
On Fri, May 28, 2010 at 17:12, Steven D'Aprano wrote:
> On Sat, 29 May 2010 08:28:46 am Vinay Sajip wrote:
>
>> I've not seen this mentioned, but on such a long thread I might have
>> missed it: we already have a "__future__" module, as in
>>
>> from __future__ import with_statement
>>
>> and to m
Am 29.05.2010 21:06, schrieb P.J. Eby:
At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote:
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I can't find any follow-up to this. I don't see any
discussion in PEP 382 about PEP 302 loaders, so I assume this issue wa
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I can't find any follow-up to this. I don't see any
discussion in PEP 382 about PEP 302 loaders, so I assume this issue was
never resolved. Does it need to be before PEP 382 is implemented? Are we
wasting our time b
Last night Barry Warsaw, Jason Coombs, and I met to work on implementing
PEP 382. As part of my research, I came across this email from Martin:
http://mail.python.org/pipermail/python-dev/2009-May/089316.html
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I c
On 29/05/10 22:46, Jesse Noller wrote:
On May 28, 2010, at 11:31 PM, Nick Coghlan wrote:
Since this topic keeps coming up, some reasoning along these lines
should go into PEP 3148.
I'll type something up this weekend and shoot it to Brian for inclusion.
I was hoping to be able to keep it out
On May 28, 2010, at 11:31 PM, Nick Coghlan wrote:
On 29/05/10 10:19, Jesse Noller wrote:
In my opinion, it is high time for the std lib to pay more
attention to
the final Zen:
Namespaces are one honking great idea -- let's do more of those!
Yes, your suggestion for how to move things i
On 29/05/10 20:20, Colin H wrote:
Perhaps the next step is to re-open the issue? If it is seen as a bug,
it would be great to see a fix in 2.6+ - a number of options which
will not break backward compatibility have been put forward - cheers,
A new feature request requesting a "closure" mode for
On Fri, 28 May 2010 20:31:02 -0400
Steve Holden wrote:
> I think it shows how developers can "get worked over" if they are
> insufficiently vigilant.
>
> 1) I completely agree, and adduce as evidence the fact that something
> like this always seems to happen when the rule is broken;
Well it's tr
Perhaps the next step is to re-open the issue? If it is seen as a bug,
it would be great to see a fix in 2.6+ - a number of options which
will not break backward compatibility have been put forward - cheers,
Colin
On Thu, May 27, 2010 at 9:05 PM, Reid Kleckner wrote:
> On Thu, May 27, 2010 at 11
11 matches
Mail list logo