[stdlib-sig] PEP 3108
Brett Cannon
brett at python.org
Tue Jan 22 21:31:00 CET 2008
On Jan 22, 2008 2:20 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-01-22 03:06, Brett Cannon wrote:
> > On Jan 21, 2008 3:39 PM, M.-A. Lemburg <mal at 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
>
More information about the stdlib-sig
mailing list