On 24 May 2010 03:58, Cameron Simpson wrote:
> I almost am Brian's hypothetical user. I've got a "FuncMultiQueue" that
> accepts callables in synchronous and asynchronous modes for future
> possibly-concurrent execution, just as the futures module does. I've
> spent a _lot_ of time debugging it.
Am 24.05.2010 01:51, schrieb Greg Ewing:
> Brian Quinlan wrote:
>
>> The good news in this case is that the same API has been used
>> successfully in Java and C++ for years so it is unlikely that any major
>> changes will need to be made.
>
> That doesn't follow. An API that's appropriate for J
> Not top-posting, but gmane seems too finicky in this area.
I encountered what seems like an incompatibility between urllib and urllib2 in
the way they handle file:// URLs, is this a bug? I had a look on the bug tracker
and via Google to see if there were prior reports, but perhaps my search-fu i
On 2010-05-23, Terry Reedy wrote:
> On 5/22/2010 8:06 PM, Jeffrey Yasskin wrote:
> > On Sat, May 22, 2010 at 4:12 PM, Brian Quinlan wrote:
> >> Rename "executor" => "executer"
> >
> > -1 for consistency with Java.
>
> -10 for 'executer'. As far as I can find out, it is a misspelling of
> 'execut
On May 24, 2010, at 5:16 AM, Glyph Lefkowitz wrote:
On May 23, 2010, at 2:37 AM, Brian Quinlan wrote:
On May 23, 2010, at 2:44 PM, Glyph Lefkowitz wrote:
On May 22, 2010, at 8:47 PM, Brian Quinlan wrote:
Jesse, the designated pronouncer for this PEP, has decided to
keep discussion open
On Mon, May 24, 2010 at 08:49:56AM +, Vinay Sajip wrote:
> I encountered what seems like an incompatibility between urllib and urllib2 in
> the way they handle file:// URLs, is this a bug? I had a look on the bug
> tracker
> >>> s = 'file:tmp/hello.txt'
> >>> f1 = urllib.urlopen(s)
The a
Senthil Kumaran gmail.com> writes:
>
> The actual (and Valid) file:// url in your case is 'file:///tmp/hello.txt'
> And this was fine and consistent.
>
> The extra '/' is making it in invalid url in urllib2, I think that be
> tracked as bug at least to show a consistent behaviour. The local
>
Cameron Simpson writes:
> There's a lot to be said for a robust implementation of a well defined
> problem. Brian's module, had it been present and presuming it robust and
> debugged, would have been quite welcome.
That, of course, is the consensus view, both in general and with
respect to thi
On Sun, 23 May 2010 20:52:19 -0700
Steven Bethard wrote:
> I have a few feature
> requests, etc. for argparse, and I was planning to just copy them over
> to the Python bug tracker (and close them on the Google code tracker).
Yes, I think this is desireable. You should also maintain argparse
dire
On Fri, May 21, 2010 at 14:35, Andrew Svetlov wrote:
> For me it's the real bug in standard python import machinery.
> I don't see any backward incompatibilities.
> There are very hard to write any import-depended code based on
> decision: was module imported in absolute or relative way.
>
> If it
10 matches
Mail list logo
