[Python-ideas] working on a PEP for the preview package (original) (raw)

Devin Jeanpierre jeanpierreda at gmail.com
Wed Jan 4 13:30:51 CET 2012

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

More information about the Python-ideas mailing list