[stdlib-sig] PEP 3108

[M.-A. Lemburg]

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" ?

>>    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.

>>  * "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.

>>  * 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 ?

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