[Python-Dev] PEP 408 -- Standard library __preview__ package
steve at pearwood.info
Sat Jan 28 03:51:41 CET 2012
Michael Foord wrote:
> On 27/01/2012 20:48, Steven D'Aprano wrote:
>> Eli Bendersky wrote:
>>>> from __preview__ import thing
>>>> except ImportError:
>>>> import thing
>>>> So no need to target a very specific version of Python.
>>> Yep, this is what I had in mind. And it appeared too trivial to place
>>> it in the PEP.
>> Trivial and wrong.
>> Since thing and __preview__.thing may have subtle, or major, API
>> differences, how do you use it?
> 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.
In the case of the typical __preview__ module, one of the motivations of
adding it to __preview__ is to test the existing API. We should expect
changes, even if in practice often there won't be. We might hope for no API
changes, but we should plan for the case where there will be.
And that rules out the "try import" dance for the typical __preview__ module.
There may be modules which graduate and keep the same API. In those cases,
people will quickly work out the import dance on their own, it's a very common
But we shouldn't advertise it as the right way to deal with __preview__, since
that implies the expectation of API stability, and we want to send the
opposite message: __preview__ is the last time the API can change without a
big song and dance, so be prepared for it to change.
I'm with Nick on this one: if you're not prepared to change "from __preview__
import module" to "import module" in your app, then you certainly won't be
prepared to deal with the potential API changes and you aren't the target
audience for __preview__.
 I am fully aware of the folly of referring to a "typical" example of
something that doesn't exist yet <wink>
More information about the Python-Dev