On Jan 7, 2008 5:16 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
