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. 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 :-) 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. * "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 ? 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). * 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. Cheers, -- 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
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.
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.
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.
* "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.
* 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. But if an extension module does not get fixed it will just go away. -Brett
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" ?
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
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" ?
The point is that "*dbm" is the standard moniker for the underlying libraries. They are called "ndbm", "gdbm", etc., and people wanting to use them will look for them under that name, not under "datastore" or "dsm" :-)
On 2008-01-22 12:23, Antoine wrote:
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" ?
The point is that "*dbm" is the standard moniker for the underlying libraries. They are called "ndbm", "gdbm", etc., and people wanting to use them will look for them under that name, not under "datastore" or "dsm" :-)
I know, but that still doesn't make it a good name for *those* modules, IMHO. OTOH, sqlite *is* a dbm, but not in that package. Anyway, don't really think it's a big deal, just thought I'd mention it. -- 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
The point is that "*dbm" is the standard moniker for the underlying libraries. They are called "ndbm", "gdbm", etc., and people wanting to use them will look for them under that name, not under "datastore" or "dsm" :-)
I know, but that still doesn't make it a good name for *those* modules, IMHO. OTOH, sqlite *is* a dbm, but not in that package.
No, SQLite is just SQLite, not a *dbm variant (at least, not as far as I know). "dbm" is like "emacs": the designation of a quite specific family of software with a similar interface.
On 2008-01-22 16:42, Antoine wrote:
The point is that "*dbm" is the standard moniker for the underlying libraries. They are called "ndbm", "gdbm", etc., and people wanting to use them will look for them under that name, not under "datastore" or "dsm" :-) I know, but that still doesn't make it a good name for *those* modules, IMHO. OTOH, sqlite *is* a dbm, but not in that package.
No, SQLite is just SQLite, not a *dbm variant (at least, not as far as I know). "dbm" is like "emacs": the designation of a quite specific family of software with a similar interface.
Right. I meant SQLite is a database manager (dbm) in the true sense of the word, much like emacs is, well, an emacs :-) -- 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
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
On Jan 21, 2008 4:39 PM, M.-A. Lemburg <mal@egenix.com> wrote:
* 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.
The main reason for the move away from camelCase was that non-native English speakers claimed that it was easier to find the words when under_scores was used instead of camelCase. I assume the same argument applies here: under_scores is better than runtogetherwords. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy
On 2008-01-22 06:58, Steven Bethard wrote:
On Jan 21, 2008 4:39 PM, M.-A. Lemburg <mal@egenix.com> wrote:
* 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.
The main reason for the move away from camelCase was that non-native English speakers claimed that it was easier to find the words when under_scores was used instead of camelCase. I assume the same argument applies here: under_scores is better than runtogetherwords.
I guess it's a matter of taste. Either way, please stick to one convention instead of mixing the two, ie. "socket_server", "tk_inter", etc. FWIW: I always liked the CamelCase module names and still use them in projects. Never understood the reason for outlawing them in PEP8 - even less so, since there was a time when using CamelCase was actually considered better than all-lower-case (ok, that's probably about 10 years ago :-). 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 22, 2008, at 5:07 AM, M.-A. Lemburg wrote:
On 2008-01-22 06:58, Steven Bethard wrote:
On Jan 21, 2008 4:39 PM, M.-A. Lemburg <mal@egenix.com> wrote:
* 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.
The main reason for the move away from camelCase was that non-native English speakers claimed that it was easier to find the words when under_scores was used instead of camelCase. I assume the same argument applies here: under_scores is better than runtogetherwords.
I agree. Hopefully with a sensible reorganization, multi-word module names can be reduced as much as possible (e.g. email.MIMEText -> email.mime.text), but if not, then I don't have a problem with underscored module names in general. socket_server is fine, but I also think tkinter is fine since the later doesn't even contain real words <wink>. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR5XgEXEjvBPtnXfVAQIbZwP/X8sWnnav6TWBuDnILlm6kavyR90rjgtd bHU4spMSCGP+OiVEXfpreB9i6MWhICF/Mx9Qb7wcWB229Y2eQyCvGwpMzyi5a7Uz PXSYNRK/n1btuyA2H+ickze41aM5nUj1YewsQGdUZmguViflOcTWO56pgcOD2iuz pvkSzZXkoFc= =F/D2 -----END PGP SIGNATURE-----
participants (5)
-
Antoine -
Barry Warsaw -
Brett Cannon -
M.-A. Lemburg -
Steven Bethard