From brett at python.org Mon Jan 21 23:20:42 2008 From: brett at python.org (Brett Cannon) Date: Mon, 21 Jan 2008 14:20:42 -0800 Subject: [stdlib-sig] Added dbm package to PEP 3108 Message-ID: So the dbm package as discussed on the old list has now been added to PEP 3108. I also updated the spreadsheet. I went with 'dbm.tools' as I liked Steve's arguments for it plus I just plain prefer it. =) I expect we will tackle the http package next when I (or someone else) starts off an email with suggested names (I have some already in the spreadsheet, but I should be doing real work instead of this =). -Brett From mal at egenix.com Tue Jan 22 00:39:53 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 22 Jan 2008 00:39:53 +0100 Subject: [stdlib-sig] PEP 3108 Message-ID: <47952D49.1010902@egenix.com> 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 From brett at python.org Tue Jan 22 03:06:20 2008 From: brett at python.org (Brett Cannon) Date: Mon, 21 Jan 2008 18:06:20 -0800 Subject: [stdlib-sig] PEP 3108 In-Reply-To: <47952D49.1010902@egenix.com> References: <47952D49.1010902@egenix.com> Message-ID: On Jan 21, 2008 3:39 PM, M.-A. Lemburg 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 From mal at egenix.com Tue Jan 22 11:07:37 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 22 Jan 2008 11:07:37 +0100 Subject: [stdlib-sig] PEP 3108 In-Reply-To: References: <47952D49.1010902@egenix.com> Message-ID: <4795C069.8040808@egenix.com> On 2008-01-22 06:58, Steven Bethard wrote: > On Jan 21, 2008 4:39 PM, M.-A. Lemburg 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 From mal at egenix.com Tue Jan 22 11:20:03 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 22 Jan 2008 11:20:03 +0100 Subject: [stdlib-sig] PEP 3108 In-Reply-To: References: <47952D49.1010902@egenix.com> Message-ID: <4795C353.3080109@egenix.com> On 2008-01-22 03:06, Brett Cannon wrote: > On Jan 21, 2008 3:39 PM, M.-A. Lemburg 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 From barry at python.org Tue Jan 22 13:22:41 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 22 Jan 2008 07:22:41 -0500 Subject: [stdlib-sig] PEP 3108 In-Reply-To: <4795C069.8040808@egenix.com> References: <47952D49.1010902@egenix.com> <4795C069.8040808@egenix.com> Message-ID: -----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 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 . - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR5XgEXEjvBPtnXfVAQIbZwP/X8sWnnav6TWBuDnILlm6kavyR90rjgtd bHU4spMSCGP+OiVEXfpreB9i6MWhICF/Mx9Qb7wcWB229Y2eQyCvGwpMzyi5a7Uz PXSYNRK/n1btuyA2H+ickze41aM5nUj1YewsQGdUZmguViflOcTWO56pgcOD2iuz pvkSzZXkoFc= =F/D2 -----END PGP SIGNATURE----- From steven.bethard at gmail.com Tue Jan 22 06:58:51 2008 From: steven.bethard at gmail.com (Steven Bethard) Date: Mon, 21 Jan 2008 22:58:51 -0700 Subject: [stdlib-sig] PEP 3108 In-Reply-To: <47952D49.1010902@egenix.com> References: <47952D49.1010902@egenix.com> Message-ID: On Jan 21, 2008 4:39 PM, M.-A. Lemburg 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 From solipsis at pitrou.net Tue Jan 22 12:23:45 2008 From: solipsis at pitrou.net (Antoine) Date: Tue, 22 Jan 2008 12:23:45 +0100 (CET) Subject: [stdlib-sig] PEP 3108 - dbm In-Reply-To: <4795C353.3080109@egenix.com> References: <47952D49.1010902@egenix.com> <4795C353.3080109@egenix.com> Message-ID: <35281.82.66.243.168.1201001025.squirrel@webmail.nerim.net> >> 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" :-) From mal at egenix.com Tue Jan 22 16:33:21 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 22 Jan 2008 16:33:21 +0100 Subject: [stdlib-sig] PEP 3108 - dbm In-Reply-To: <35281.82.66.243.168.1201001025.squirrel@webmail.nerim.net> References: <47952D49.1010902@egenix.com> <4795C353.3080109@egenix.com> <35281.82.66.243.168.1201001025.squirrel@webmail.nerim.net> Message-ID: <47960CC1.5010500@egenix.com> 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 From solipsis at pitrou.net Tue Jan 22 16:42:43 2008 From: solipsis at pitrou.net (Antoine) Date: Tue, 22 Jan 2008 16:42:43 +0100 (CET) Subject: [stdlib-sig] PEP 3108 - dbm In-Reply-To: <47960CC1.5010500@egenix.com> References: <47952D49.1010902@egenix.com> <4795C353.3080109@egenix.com> <35281.82.66.243.168.1201001025.squirrel@webmail.nerim.net> <47960CC1.5010500@egenix.com> Message-ID: <59297.82.66.243.168.1201016563.squirrel@webmail.nerim.net> >> 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. From mal at egenix.com Tue Jan 22 16:49:26 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 22 Jan 2008 16:49:26 +0100 Subject: [stdlib-sig] PEP 3108 - dbm In-Reply-To: <59297.82.66.243.168.1201016563.squirrel@webmail.nerim.net> References: <47952D49.1010902@egenix.com> <4795C353.3080109@egenix.com> <35281.82.66.243.168.1201001025.squirrel@webmail.nerim.net> <47960CC1.5010500@egenix.com> <59297.82.66.243.168.1201016563.squirrel@webmail.nerim.net> Message-ID: <47961086.2090302@egenix.com> 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 From brett at python.org Tue Jan 22 21:31:00 2008 From: brett at python.org (Brett Cannon) Date: Tue, 22 Jan 2008 12:31:00 -0800 Subject: [stdlib-sig] PEP 3108 In-Reply-To: <4795C353.3080109@egenix.com> References: <47952D49.1010902@egenix.com> <4795C353.3080109@egenix.com> Message-ID: On Jan 22, 2008 2:20 AM, M.-A. Lemburg wrote: > On 2008-01-22 03:06, Brett Cannon wrote: > > On Jan 21, 2008 3:39 PM, M.-A. Lemburg 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 > From brett at python.org Wed Jan 30 00:38:34 2008 From: brett at python.org (Brett Cannon) Date: Tue, 29 Jan 2008 15:38:34 -0800 Subject: [stdlib-sig] http package proposal Message-ID: OK, to keep this ball rolling, here is my suggestion for reorganizing HTTP modules: httplib -> http.tools BaseHTTPServer -> http.server SimpleHTTPServer -> http.server CGIHTTPServer -> http.server cookielib -> http.cookies Since the various HTTP server modules have no name clashes we can consolidate them into a single module. -Brett From alexandre at peadrop.com Wed Jan 30 02:20:58 2008 From: alexandre at peadrop.com (Alexandre Vassalotti) Date: Tue, 29 Jan 2008 20:20:58 -0500 Subject: [stdlib-sig] http package proposal In-Reply-To: References: Message-ID: Sounds good. Is there any plan to do a similar packaging with the xmlrpc-related modules? For example, xmlrpclib -> xmlrpc.tools SimpleXMLRPCServer -> xmlrpc.server DocXMLRPCServer -> xmlrpc.server -- Alexandre On Jan 29, 2008 6:38 PM, Brett Cannon wrote: > OK, to keep this ball rolling, here is my suggestion for reorganizing > HTTP modules: > > httplib -> http.tools > BaseHTTPServer -> http.server > SimpleHTTPServer -> http.server > CGIHTTPServer -> http.server > cookielib -> http.cookies > > Since the various HTTP server modules have no name clashes we can > consolidate them into a single module. > From brett at python.org Wed Jan 30 03:04:50 2008 From: brett at python.org (Brett Cannon) Date: Tue, 29 Jan 2008 18:04:50 -0800 Subject: [stdlib-sig] xml-rpc package proposal (was: http package proposal) Message-ID: On Jan 29, 2008 5:20 PM, Alexandre Vassalotti wrote: > Sounds good. Is there any plan to do a similar packaging with the > xmlrpc-related modules? For example, > > xmlrpclib -> xmlrpc.tools > SimpleXMLRPCServer -> xmlrpc.server > DocXMLRPCServer -> xmlrpc.server I had not gotten that far (just doing them as I find time to bother to think about and send an email), but I like your proposal. What do others think? -Brett From solipsis at pitrou.net Wed Jan 30 08:58:47 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 30 Jan 2008 08:58:47 +0100 Subject: [stdlib-sig] xml-rpc package proposal (was: http package proposal) In-Reply-To: References: Message-ID: <1201679927.7588.0.camel@fsol> Le mardi 29 janvier 2008 ? 18:04 -0800, Brett Cannon a ?crit : > On Jan 29, 2008 5:20 PM, Alexandre Vassalotti wrote: > > Sounds good. Is there any plan to do a similar packaging with the > > xmlrpc-related modules? For example, > > > > xmlrpclib -> xmlrpc.tools > > SimpleXMLRPCServer -> xmlrpc.server > > DocXMLRPCServer -> xmlrpc.server > > I had not gotten that far (just doing them as I find time to bother to > think about and send an email), but I like your proposal. What do > others think? It sounds good. The WeirdCamelCaseModuleNames are simply very annoying. regards Antoine.