[Python-Dev] PEP 3148 ready for pronouncement

Terry Reedy tjreedy at udel.edu
Wed May 26 18:27:17 CEST 2010


> On 26/05/10 20:57, Greg Ewing wrote:

>> (More generally, I'm inclined to think that introducing
>> a namespace package for a category of modules having
>> existing members in the stdlib is an anti-pattern,

As a user, I agree with this.

>> unless it's done during the kind of namespace refactoring
>> that we won't get another chance to perform until Py4k.)

Is Steven D'Aprano's suggestion (in another post) possible?
> I'm sure that it can be done easily, although not quickly. For
> instance, we move threading into the concurrent namespace, and leave
> behind in its place a stub:
>
> from concurrent.threading import *
>
> Then for (say) 3.3 the stub could gain a PendingDeprecation warning,
> then in 3.4 a Deprecation warning, and finally in 3.5 or 3.6 it
> could be removed.

On 5/26/2010 8:42 AM, Nick Coghlan wrote:
> _thread, threading, Queue and multiprocessing do likely belong here, but
> moving them isn't likely to be worth the pain.

As a user, I disagree and think collecting together these and future 
modules (pun intended) would be beneficial. There are, from my 
viewpoint, too many top level modules already.

[and in another thread]
> Yes, we're setting ourselves up for inevitable questions as to why
> the existing modules are top level rather than part of this package,

Yes, forever until they are put in the package.

> but the minimal pain responsethere

For the developers, for the short term

> would be to link to them from the
> package documentation with a note along the lines of "for historical
> reasons, some modules you might reasonably expect to find in this
> package are instead provided as top level modules".

You are, in my opinion, overly discounting the cognitive load and 
confusion on the part of new users. It would be much better to link *to* 
subpackage documentation *from* a top level entries (until deleted) and 
just say that the top level synonyms are present for the obvious 
historical reason that there once no package, just modules.


I am suggesting that if we add a package, we do it right, from the 
beginning.

Terry Jan Reedy







More information about the Python-Dev mailing list