On Sat, Jan 28, 2012 at 6:43 AM, Steven D'Aprano <st...@pearwood.info> wrote:
> This PEP only makes sense if we assume that __preview__.spam and spam *will*
> be different, even if only in minor ways, and that there might not even be a
> spam. There should be no expectation that every __preview__ module must
> graduate, or that every standard library module must go through __preview__.
> If it is stable and uncontroversial, __preview__ adds nothing to the
> process.
Yes, the PEP already points to lzma as an example of a module with a
sufficiently obvious API that it didn't need to go through a preview
round.
> Keeping __preview__.spam around after graduation is, I believe, actively
> harmful. It adds complexity to the developer's decision-making process
> ("Should I import spam from __preview__, or just import spam? What's the
> difference?"). It gives a dangerous impression that code written for
> __preview__.spam will still work for spam.
Yes, this was exactly the reasoning behind removing the names from
__preview__ namespace when the modules graduated. It sets a line in
the sand: "An API compatibility break is not only allowed, it is 100%
guaranteed. If you are not prepared to deal with this, then you are
*not* part of the target audience for the __preview__ namespace. Wait
until the module reaches the main section of the standard library
before you start using it, or else download a third party supported
version with backwards compatibility guarantees from PyPI. The
__preview__ namespace is not designed for anything that requires long
term support spanning multiple Python version - it is intended for use
in single version environments, such as intranet web services and
student classrooms"
> I would go further and suggest that __preview__ be explicitly called
> __unstable__. If that name is scary, and it frightens some users off, good!
Hmm, the problem with "unstable" is that we only mean the *API* is
unstable. The software itself will be as thoroughly tested as
everything else we ship.
> I think the PEP needs more use-cases on who might use __preview__.spam, and
> why. These come to my mind:
>
> * if you don't care about Python 3.x+1, then there is no reason not to
> treat Python 3.x's __preview__.spam as stable;
>
> * rapid development proof-of-concept software ("build one to throw away")
> can safely use __preview__.spam, since they are expected to be replaced
> anyway;
>
> * one-use scripts;
>
> * use at the interactive interpreter;
>
> * any other time where forward-compatibility is not required.
A specific list of use cases is a good idea.
I'd add a couple more:
* in a student classroom where the concept of PyPI and third party
packages has yet to be introduced
* for an intranet web service deployment where due diligence adds
significant overhead to any use of third party packages
> I am reminded of the long, often acrimonious arguments that took place on
> Python-Dev a few years back about the API for the ipaddr library. A lot of
> the arguments could have been short-circuited if we had said "putting ipaddr
> into __preview__ does not constitute acceptance of its API".
Yep, there's a reason 'ipaddr' was high on the list of modules this
could be used for :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
