[stdlib-sig] PEP 3108

[Brett Cannon]

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
>