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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
