[Python-ideas] working on a PEP for the __preview__ package

[Nick Coghlan]

On Wed, Jan 4, 2012 at 9:49 PM, Devin Jeanpierre <jeanpierreda at gmail.com> wrote:
>> A correct way IMO would be to introduce a versioned exp27, exp271 packages:
>
> +2. Rather than silently introducing subtle semantics changes,
> wouldn't it be better for older imports to fail with an ImportError?
> Since this is just for toying around, this shouldn't break any play,
> but it _should_ discourage (very strongly) people using experimental
> stuff in their published code.

__preview__ isn't just for toying around: so long as you don't need to
support multiple Python versions, it will be just as stable and well
supported as the rest of the standard library. That means people
deploying to controlled environments (such as the folks in corporate
and governmental environments that are intended to be the primary
beneficiaries) can use it quite happily (although keeping in mind the
potential for changes when finally upgrading in the future). That's
the entire point of the exercise.

It's unlikely that things will be in the __preview__ namespace for
more than one release - I expect that most packages that are of an
adequate standard to get added in the first place will make it through
their preview release period without significant changes. The process
just gives us one final chance to get broader feedback before we flip
the switch and lock in the API indefinitely.

For folks that have an easier time of dependency management, it's
likely a better bet for them to depend on a PyPI release of a package
rather than using the __preview__ version, but such folks don't depend
as much on the standard library in the first place.

People also shouldn't read too much into the relaxation of the
backwards compatibility guarantees - we aren't going to go nuts and
just change things on a whim. We'll just be a little less conservative
when we identify problems in the preview APIs that need to be fixed
before they're added to the main part of the standard library.

Deciding whether or not to rely on __preview__ modules, or to depend
on packages that in turn use __preview__ modules will still be a
decision developers need to make for themselves. That's no different
from any other form of due diligence that professional developers need
to conduct on their dependencies today.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia