[Python-3000] Comments on PEP-3108: Standard Library Reorganization

[Brett Cannon]

On Jan 7, 2008 5:16 PM, Raymond Hettinger <python at rcn.com> wrote:
> 1) The repr module is marked as hardly used, but it may have a fan base (not me). It is covered in the tutorial's guided tour, so it has been held-up as being active and useful.  There are a few hits on google's codesearch:
> http://www.google.com/codesearch?hl=en&q=+lang:python+%22import+repr%22&start=20&sa=N
> http://www.google.com/codesearch?hl=en&lr=&q=lang%3Apython+repr.repr&btnG=Search
> So, perhap this one should be discussed further before being zapped.
>

This can be discussed.  So does anyone use it and want to fight to
keep it around as a separate API?

> 2) The opcode module is slated for renaming to _opcode on the theory that it doesn't have a documented interface. If needed, I can make docs for the module. I think it should continue to exist with its current name.
>

That would be great.  I am fine with saving stuff if people are
willing to put the time and effort into maintaining it.  Doing the
docs falls under that.

> 3) The PEP says that the idea to introduce new, theme-related packages was tabled for a variety of reasons; however, the active discussions on python-3000 suggest otherwise (i.e. discussion of a database package).  Please expand the rationale to include my earlier comment about how the Library Reference table of contents serves as a strong indicator that introducing package hierarchies will be detrimental. I'm hoping that bit of analysis doesn't get lost.
>

Well, as Guido has suggested, any new modules will be to make names
more reasonable (e.g., organizing HTTP modules so we have http.lib or
http.tools, http.server.cgi, etc.).  Adding general organization like
compression.gzip, etc. has essentially been shot down at this point.
Does this address your concern?

> 4) The Cookie module should be considered for removal. It is very short and adds little value -- half of the tools are deprecated -- it appears that this module is no longer receiving love from a maintainer that cares about its future.  Removing it will make space for a better implementation (if needed) in the future.

Fine by me.  Anyone care to fight for saving the Cookie module?

-Brett