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 for a few more days.
So fire away!
As you wish!
I retract my request ;-)
The PEP should be
On Sun, May 23, 2010 at 2:37 AM, Brian Quinlan br...@sweetapp.com wrote:
snip
Finally, why isn't this just a module on PyPI? It doesn't seem like there's
any particular benefit to making this a stdlib module and going through the
whole PEP process - except maybe to prompt feedback like this
On May 23, 2010, at 7:15 PM, geremy condra wrote:
On Sun, May 23, 2010 at 2:37 AM, Brian Quinlan br...@sweetapp.com
wrote:
snip
Finally, why isn't this just a module on PyPI? It doesn't seem
like there's
any particular benefit to making this a stdlib module and going
through the
whole
On Sun, May 23, 2010 at 11:39, Brian Quinlan br...@sweetapp.com wrote:
This package eliminates the need to construct the boilerplate present in
many Python applications i.e. a thread or process pool, a work queue and
result queue. It also makes it easy to take an existing Python application
On May 23, 2010, at 7:54 PM, Lennart Regebro wrote:
On Sun, May 23, 2010 at 11:39, Brian Quinlan br...@sweetapp.com
wrote:
This package eliminates the need to construct the boilerplate
present in
many Python applications i.e. a thread or process pool, a work
queue and
result queue. It
On Sun, May 23, 2010 at 10:15 PM, Brian Quinlan br...@sweetapp.com wrote:
Also, you can't fix bugs except by
releasing new versions of Python. Therefore the API must be completely
stable, and the product virtually bugfree before it should be in
stdlib. The best way of ensuring that is to
On Sun, May 23, 2010 at 12:15, Brian Quinlan br...@sweetapp.com wrote:
I doubt it. Simple modules are unlikely to develop a following because it is
too easy to partially replicate their functionality. urlparse and os.path
are very useful modules but I doubt that they would have been successful
On May 23, 2010, at 8:43 PM, Robert Collins wrote:
On Sun, May 23, 2010 at 10:15 PM, Brian Quinlan br...@sweetapp.com
wrote:
Also, you can't fix bugs except by
releasing new versions of Python. Therefore the API must be
completely
stable, and the product virtually bugfree before it
On Sun, 23 May 2010 12:43:57 +0200
Dirkjan Ochtman dirk...@ochtman.nl wrote:
In general, this reminds me of the ipaddr discussions. I read through
the thread from March real quick to see if there was reasoning there
why this package should be an exception from the normal standards
track
On May 23, 2010, at 8:43 PM, Dirkjan Ochtman wrote:
On Sun, May 23, 2010 at 12:15, Brian Quinlan br...@sweetapp.com
wrote:
I doubt it. Simple modules are unlikely to develop a following
because it is
too easy to partially replicate their functionality. urlparse and
os.path
are very useful
On Sun, May 23, 2010 at 12:51, Antoine Pitrou solip...@pitrou.net wrote:
I disagree that a stdlib module is a dead module. It is perfectly
possible to augment the API with new functionality without breaking
compatibility. You can also deprecate old APIs if you want.
Right, it wasn't intended
Is there any reason to have Future .cancelled, .done, .running as methods?
From my perspective they are really readonly properties.
BTW, is 'cancelled' correct name? Spell-checkers likes only single 'l'
form: 'canceled'.
On Sun, May 23, 2010 at 2:47 PM, Brian Quinlan br...@sweetapp.com wrote:
On Sun, May 23, 2010 at 12:15, Brian Quinlan br...@sweetapp.com wrote:
You could make the same argument about any module in the stdlib.
Yeah, and that's exactly what I did.
I doubt it. Simple modules are unlikely to develop a following because it is
too easy to partially replicate their
On Sun, May 23, 2010 at 03:16:27PM +0400, Andrew Svetlov wrote:
Is there any reason to have Future .cancelled, .done, .running as methods?
From my perspective they are really readonly properties.
BTW, is 'cancelled' correct name? Spell-checkers likes only single 'l'
form: 'canceled'.
In
On 23 May 2010, at 21:17, Lennart Regebro wrote:
On Sun, May 23, 2010 at 12:15, Brian Quinlan br...@sweetapp.com
wrote:
You could make the same argument about any module in the stdlib.
Yeah, and that's exactly what I did.
I doubt it. Simple modules are unlikely to develop a following
Brian Quinlan wrote:
On May 23, 2010, at 2:44 PM, Glyph Lefkowitz wrote:
[...]
One minor suggestion on the internal future methods bit - something
I wish we'd done with Deferreds was to put 'callback()' and
'addCallbacks()' on separate objects, so that it was very explicit
whether you
On Sun, May 23, 2010 at 13:29, Brian Quinlan br...@sweetapp.com 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 implement it. That means it's
On Sun, May 23, 2010 at 7:52 AM, Steve Holden st...@holdenweb.com wrote:
...snip...
Issues like the ones I'm bringing up could be fixed pretty
straightforwardly if it were just a matter of filing a bug on a small
package, but fixing a stdlib module is a major undertaking.
True but I don't
On Sun, 23 May 2010 08:34:22 -0400
Jesse Noller jnol...@gmail.com 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 other things will be part
Jesse Noller wrote:
On Sun, May 23, 2010 at 7:52 AM, Steve Holden st...@holdenweb.com wrote:
...snip...
Issues like the ones I'm bringing up could be fixed pretty
straightforwardly if it were just a matter of filing a bug on a small
package, but fixing a stdlib module is a major
On 5/22/2010 8:06 PM, Jeffrey Yasskin wrote:
On Sat, May 22, 2010 at 4:12 PM, Brian Quinlanbr...@sweetapp.com wrote:
Rename executor = executer
-1 for consistency with Java.
-10 for 'executer'. As far as I can find out, it is a misspelling of
'executor'. If the designers of some other
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 for a few more days.
So fire away!
As you
Glyph Lefkowitz wrote:
Finally, why isn't this just a module on PyPI? It doesn't seem like
there's any particular benefit to making this a stdlib module and going
through the whole PEP process
I'm inclined to agree. This needs to be field-tested before
being considered for stdlib inclusion.
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 Java or
C++ is not necessarily appropriate for Python.
Brian Quinlan wrote:
Simple modules are unlikely to develop a following because it is too
easy to partially replicate their functionality.
I don't think it needs a particularly large following.
What it does need is at least a few people using it in
some real projects.
No matter how much
Andrew Svetlov wrote:
BTW, is 'cancelled' correct name? Spell-checkers likes only single 'l'
form: 'canceled'.
I think this is an English vs. American thing. Double 'l'
looks right to me, but then I was brought up as a loyal
subject of the antipodean branch of the British Empire. :-)
--
Greg
Brian Quinlan writes:
If you are familiar with threads then writing a good enough solution
without futures probably won't take you very long. Also, unless you
are familiar with another futures implementation, you aren't likely to
know where to look.
That looks like an argument
On 24May2010 10:47, Stephen J. Turnbull step...@xemacs.org wrote:
| Brian Quinlan writes:
| If you are familiar with threads then writing a good enough solution
| without futures probably won't take you very long. Also, unless you
| are familiar with another futures implementation, you
Before I go and add about 30 open issues to the Python tracker, I
figured I should ask. What's the normal process for the bug trackers
of modules that move to the standard library? I have a few feature
requests, etc. for argparse, and I was planning to just copy them over
to the Python bug tracker
On Sun, May 23, 2010 at 08:52:19PM -0700, Steven Bethard wrote:
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).
I think, this is a good idea. +1 from me. There is only one module,
bsddb, which is
30 matches
Mail list logo
