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

[Eli Bendersky]

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

Eli