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

[Devin Jeanpierre]

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

Ah, this would remove much of the point of explicit version numbering
wouldn't it?

Your other paragraphs make other good points against it too. It was a
good response.

I am no longer +2 on explicit versioning. I still find it nice for
"experimental" code to be a bit clear about which experiment you're
referring to, but it isn't very important if it doesn't last long and
doesn't go through that many breaking changes. In fact, the way the
use case is shaping up, it isn't important at all. I suspect I
misremembered or only selectively remembered the original __preview__
proposal.

I suppose this is a good reason to get a PEP out, huh.

-- Devin

On Wed, Jan 4, 2012 at 7:09 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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