On 4/4/06, Aahz <[EMAIL PROTECTED]> wrote: > On Tue, Apr 04, 2006, Just van Rossum wrote: > > Has there been any discussion yet about StringIO vs cStringIO and pickle > > vs cPickle? > > Now there is! > > > While I appreciate that there are maintained pure Python versions of > > those modules, as a user it irritates me that I have the choice. The > > argument so far for not replacing StringIO with cStringIO was that > > they're subtly incompatible (mostly StringIO's "feature" to support > > unicode, right?), so Python 3000 seems like a good time to reconsider > > that option. I don't see any reason to not always want to prefer the > > faster version. > > Suggestion: make string_io (we're renaming the module, right?)
Yes, but I don't like module names with underscores. We don't have to decide now though. > and pickle > contain a UserStringIO and UserPickle class. Ah, yuck. UserThis and UserThat classes are a thing from the past, when you couldn't subclass the built-in types. I like what Raymond did with DictMixin though (which should really be called SequenceMixin) -- if you want to create your own mapping type *without* inheriting from dict, you can still get a bunch of standard implementation boilerplate via inheritance. This is what Java does with AbstractList etc. > Alternatively, they could > be moved wholesale into a python_types module, where we collectively > maintain Python versions of *all* Python types, including lists and > tuples. Sorry, another bad idea. The hope of having a comprehensive collection of *all* "standard" types is misguided. Types should go in the appropriate module given their application area. There are tons of types that don't have global names and don't need them (e.g. various iterators). > IOW, I do argue for keeping the Python code somehow, and keeping them > officially maintained. Obviously it gets a little absurd with lists and > numbers, for example, but I think that showing off good use of __new__ > would be a Good Thing. I'm in agreement with the sentiment of keeping the Python code though -- it's incredibly useful for example in Jython and IronPython. Perhaps we should switch to a naming scheme where we have a "pickle" module that you're supposed to import, which dynamically tries to import first "_pickle" and if that fails imports "_pypickle" (or some such naming scheme). If you specifically need to use one or the other you can import it explicitly (assuming it exists). This is a bit similar to how we have os.path and posixpath (although the decision regarding which one os.path refers to is different). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
