On Jan 22, 2008 2:20 AM, M.-A. Lemburg <mal@egenix.com> wrote:
On 2008-01-22 03:06, Brett Cannon wrote:
On Jan 21, 2008 3:39 PM, M.-A. Lemburg <mal@egenix.com> wrote:
Hi all,
just skimmed through PEP 3108. A few comments:
* The renaming is done inconsistently, e.g.
"simple_http_server", "simple_xmlrpc_server", but "socketserver"
There should either always be an underscore to separate words, or none.
I don't think that underscores in module names are particularly nice, so I'd opt for going with the no-underscores versions.
* dbm renaming is going to cause trouble
The reason is that there already is a dbm module with a defined interface which the package is likely not going to provide.
Right, but 2to3 will handle the renaming. That will lead to dbm being imported in legacy code as ``import dbm.ndbm as dbm``. That's actually fine as the package itself will have no API.
Ok.
I also don't think that "dbm" meaning database manager is really what the modules are all about. They usually just implement on-disk dictionaries, nothing more complicated. A DBM usually has a bit more to offer, e.g. think Oracle :-)
If you have another package name I am open to hear it.
Ideal would be data storage manager, since that's what they are all about, but "dsm" isn't intuitive enough. How about "datastore" ?
Maybe. The problem is that dbm, at least to me, doesn't mean "database management", it means "the dbm application" which is what the modules are for. What do other people think?
All in all, I'm not sure whether this is worth the trouble. sqlite is a far better choice than any of the dbm-style modules, IMHO, and it provides an upgrade path to more sophisticated RDBMs.
True, but people still use these modules so it isn't like they are going away.
Oh well.
Well, if you want to push for some or all of their removal you can.
* "All database related modules will be moved to a database package. These modules include: bsddb, dbm, gdbm, sqlite, anydbm, dbhash, dumbdbm, whichdb."
Does this refer to the proposed "dbm" package or is there going to be a new "database" package ?
It was an old idea that is now gone. This was in relation to the discussion that sprung up on python-dev which lead to Guido suggesting the dbm packaging and giving guidelines on how to handle packages.
Please be careful not to introduce *new* generic and widely used names for stdlib modules or packages or alternatively, go for the stdlib-in-a-package approach to work around any such issues (this is what I did for the mx packages when it became obvious that DateTime was an overly generic package name).
As the PEP says, the packaging will only occur when naming is easier. And this also came out of the python-dev discussion.
I'm +0 on packaging things in the stdlib. It's just that because the stdlib (currently) lives at top-level, new names have to be chose with care. Otherwise you end up overriding modules which are part of existing scripts or modules which live at the top-level as well and make it difficult for the users of those modules to port to 3k, esp. if those modules are used in pickles or referenced other external storage mechanisms.
Right, which is why the original idea was to try to package as much as possible. But Guido nixed that idea. I am just glad to get any packaging done at this point.
* Integrating the C performance boost modules into the Python versions
Most of the C extensions do not implement the complete set of APIs that are available in the Python version, or they work differently / do not allow sub-classing.
Eg. if you want to write an extended pickle mechanism, you can do so by subclassing from the Python version, but not from the cPickle version.
Ideal would be to rewrite the C code to work like the Python code (or vice-versa), but this seems outside the scope of the PEP.
Might be, but it has already been done. =) Alexandre has already taken care of cString and cPickle is being dealt with. And I believe Armin started off with cProfile working in a backwards-compatible fashion.
Great !
But if an extension module does not get fixed it will just go away.
cStringIO and cPickle are the most commonly used ones, so those are important to have.
How do the XML modules fit this scheme ?
I think ElementTree is the only blatent offender (unless you consider expat a C implementation of sax). That will probably need changes as well, but it has the sticky situation of being an external package that has been brought in. -Brett
Thanks,
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Jan 22 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611