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

[Steven D'Aprano]

Michael Foord wrote:
> On 27/01/2012 20:48, Steven D'Aprano wrote:
>> Eli Bendersky wrote:
>>
>>>> try:
>>>>    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[1] __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 
idiom.

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




[1] I am fully aware of the folly of referring to a "typical" example of 
something that doesn't exist yet <wink>


-- 
Steven