[Python-Dev] PEP 408 -- Standard library __preview__ package

Eli Bendersky eliben at gmail.com
Sat Jan 28 04:11:14 CET 2012

>> No, potentially wrong in cases where the APIs are different. Even with the
>> try...except ImportError dance around StringIO / cStringIO there are some
>> API differences. But for a lot of use cases it works fine (simplejson and
>> json aren't *identical*, but it works for most people).
> Okay, granted, I accept your point.
> But I think we need to distinguish between these cases.
> In the case of StringIO and cStringIO, API compatibility is expected, and
> differences are either bugs or implementation differences that you shouldn't
> be relying on.

I just recently ran into a compatibility of StringIO and cStringIO.
It's a good thing it's documented:

   "Another difference from the StringIO module is that calling
StringIO() with a string parameter creates a read-only object. Unlike
an object created without a string parameter, it does not have write
methods. These objects are not generally visible. They turn up in
tracebacks as StringI and StringO."

But it did cause me a couple of minutes of grief until I found this
piece in the docs and wrote a work-around. But no, even in the current
stable stdlib, the "try import ... except import from elsewhere" trick
doesn't "just work" for StringIO/cStringIO. And as far as I can
understand this is documented, not a bug or some obscure
implementation detail.

My point is that if our users accept *this*, in the stable stdlib, I
see no reason they won't accept the same happening between __preview__
and a graduated module, when they (hopefully) understand the intention
of __preview__.


More information about the Python-Dev mailing list