[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)

Steve Holden steve at holdenweb.com
Sun May 23 13:52:10 CEST 2010

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 were on the emitting side of a Deferred or the consuming side. That seems to be the case with these internal methods - they are not so much "internal" as they are for the producer of the Future (whether a unit test or executor) so you might want to put them on a different object that it's easy for the thing creating a Future() to get at but hard for any subsequent application code to fiddle with by accident. Off the top of my head, I suggest naming it "Invoker()". A good way to do this would be to have an Invoker class which can't be instantiated (raises an exception from init or somesuch), then a Future.create() method which returns an Invoker, which itself has a '.future' attribute.

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 already had this discussion before. Could you explain why this module should not be in the stdlib e.g. does it have significantly less utility than other modules in stdlib? Is it significantly higher risk? etc? Given that its author was ready to go for pronouncement and is still responding to pretty serious philosophical questions about the API I'd say that it was at least worth talking about. The thing that's needed (isn't it?) of stdlib modules is API stability.

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 that is a convincing argument. A subset of the functionality provided by this module is already available in Java and C++ and (at least in Java) it is used extensively and without too much trouble. If there are implementation bugs then we can fix them just like we would with any other module. I don't see the availability of this functionality in those languages as any kind of reason why this needs to go into the stdlib now. Is there some desperate rush to get it in? If it were used extensively from PyPi that would be a recommendation ...

regards Steve

Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000

More information about the Python-Dev mailing list