Re: [Python-Dev] PEP 3148 ready for pronouncement

2010-05-25 Thread Nick Coghlan
On 23/05/10 22:47, Antoine Pitrou wrote: On Sun, 23 May 2010 08:34:22 -0400 Jesse Noller wrote: Brian has already agreed to name spacing it to "concurrent.futures" - this means it will be a small part to a much larger concurrent.* implementation ala Java. What I would question here is what o

Re: [Python-Dev] PEP 3148 ready for pronouncement

2010-05-25 Thread Nick Coghlan
On 23/05/10 21:56, Lennart Regebro wrote: On Sun, May 23, 2010 at 13:29, Brian Quinlan wrote: Parts of it, yes. Just like I can replace most operations in os.path and urlparse with a few lines of code. Yeah, but "parts of" is not the question. I've read the PEP, and I do *not* know how to imp

Re: [Python-Dev] Dead modules

2010-05-25 Thread Nick Coghlan
(Sending again - I didn't mean to drop python-dev from the cc list when I originally sent this via the gmail web interface) On Sun, May 23, 2010 at 9:00 PM, Dirkjan Ochtman > wrote: Right, it wasn't intended as that harsh... but it does come with a rather impre

Re: [Python-Dev] Documenting [C]Python's Internals

2010-05-25 Thread Nick Coghlan
On 20/05/10 08:13, Yaniv Aknin wrote: Hi, I wanted to let python-dev know about a series of articles about CPython's internals I'm publishing under the collective title "Guido's Python"* (http://tech.blog.aknin.name/tag/guidos-python/). A resource that may be useful to you is a 2.5 focused man

Re: [Python-Dev] PEP 3148 ready for pronouncement

2010-05-25 Thread Jesse Noller
On Tue, May 25, 2010 at 7:54 PM, Nick Coghlan wrote: > On 23/05/10 22:47, Antoine Pitrou wrote: >> >> On Sun, 23 May 2010 08:34:22 -0400 >> Jesse Noller  wrote: >>> >>> Brian has already agreed to name spacing it to "concurrent.futures" - >>> this means it will be a small part to a much larger con

Re: [Python-Dev] PEP 3148 ready for pronouncement

2010-05-25 Thread Lennart Regebro
On Wed, May 26, 2010 at 02:10, Nick Coghlan wrote: > Those that say "just put it on PyPI" may not recognise the additional ... Just a note, so we don't get sidelined by misunderstandings: I don't think anybody said that. ;-) There are two issues here, one generic and one specific: Generic: Modu

Re: [Python-Dev] PEP 3148 ready for pronouncement

2010-05-25 Thread Nick Coghlan
On 26/05/10 12:29, Lennart Regebro wrote: On Wed, May 26, 2010 at 02:10, Nick Coghlan wrote: Those that say "just put it on PyPI" may not recognise the additional ... Just a note, so we don't get sidelined by misunderstandings: I don't think anybody said that. ;-) Nah, that pseudo-quote was

Re: [Python-Dev] PEP 3148 ready for pronouncement

2010-05-25 Thread Nick Coghlan
On 24/05/10 20:46, Stephen J. Turnbull wrote: 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 c

Re: [Python-Dev] PEP 3148 ready for pronouncement

2010-05-25 Thread Stephen J. Turnbull
Nick Coghlan writes: > Those that say "just put it on PyPI" Nobody is saying that, AFAICS. Nobody is saying that *some* futures module shouldn't *eventually* go into the stdlib. The question is whether *this* futures module should go into the stdlib *now*. And it is clear that more time on Py

Re: [Python-Dev] PEP 3148 ready for pronouncement

2010-05-25 Thread Nick Coghlan
On 26/05/10 13:51, Stephen J. Turnbull wrote: People have been asking "what's special about this module, to violate the BCP principle?" There's nothing special about the fact that several people would use a "robust and debugged" futures module if it were in the stdlib. That's true of *every* mo