Michael Foord wrote:
> On 28/01/2012 04:44, Stephen J. Turnbull wrote:
>> I think it's a bad idea to introduce a feature that's *supposed* to
>> break (in the sense of "make a break", ie, change the normal pattern)
>> with every release and then try to avoid breaking (in the sense of
>> "causing an unexpected failure") code written by people who don't want
>> to follow the discipline of keeping up with changing APIs. If they
>> want that stability, they should wait for the stable release.
>>
>> Modules should become unavailable from __preview__ as soon as they
>> have a stable home.
>>
> I like not breaking people's code where *possible*.
__preview__ is not about stability. It's about making code easily
available for testing before the API freezes.
If nothing has changed once it graduates, how hard is it to change a few
lines of code from
from __preview__ import blahblahblah
to
import blahblahblah
?
It seems to me that including a __preview__ package in production
software is a mistake, and not its intention.
~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4