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 main
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 24May2010 10:47, Stephen J. Turnbull 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 aren't likely t
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
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 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 disc
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. Sl
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.
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
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
'executor'. If the designers of some other language made a
Jesse Noller wrote:
> On Sun, May 23, 2010 at 7:52 AM, Steve Holden 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.
>>>
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 other things will be part
of the "conc
On Sun, May 23, 2010 at 7:52 AM, Steve Holden 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 think
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 implement it. That means it's not a trivial m
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
>> whe
On 23 May 2010, at 21:17, Lennart Regebro wrote:
On Sun, May 23, 2010 at 12:15, Brian Quinlan
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 eas
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'.
I
On Sun, May 23, 2010 at 12:15, Brian Quinlan 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 functionality. urlpar
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 wrote:
>
> On May 23, 2010,
On Sun, May 23, 2010 at 12:51, Antoine Pitrou 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 as that harsh... b
On May 23, 2010, at 8:43 PM, Dirkjan Ochtman wrote:
On Sun, May 23, 2010 at 12:15, Brian Quinlan
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
On Sun, 23 May 2010 12:43:57 +0200
Dirkjan Ochtman 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 (that is, ripen
On May 23, 2010, at 8:43 PM, Robert Collins wrote:
On Sun, May 23, 2010 at 10:15 PM, Brian Quinlan
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. Th
On Sun, May 23, 2010 at 12:15, Brian Quinlan 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
> PyPI.
simp
On Sun, May 23, 2010 at 10:15 PM, Brian Quinlan 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 release it as a
On May 23, 2010, at 7:54 PM, Lennart Regebro wrote:
On Sun, May 23, 2010 at 11:39, Brian Quinlan
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
On Sun, May 23, 2010 at 11:39, Brian Quinlan 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
> that executes (e
On May 23, 2010, at 7:15 PM, geremy condra wrote:
On Sun, May 23, 2010 at 2:37 AM, Brian Quinlan
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 - except m
On Sun, May 23, 2010 at 2:37 AM, Brian Quinlan 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 - except maybe to prompt feedback like this :).
>
> We've alread
29 matches
Mail list logo
