[Python-Dev] PEP 408 -- Standard library preview package (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Jan 28 08:10:22 CET 2012

On Sat, Jan 28, 2012 at 3:22 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

Executive summary:

If the promise to remove the module from preview is credible (ie, strictly kept), then preview will have a specific audience in those who want the stdlib candidate code and are willing to deal with a certain amount of instability in that code.

People need to remember there's another half to this equation: the core dev side.

The reason regex specifically isn't in the stdlib already is largely due to (perhaps excessive) concerns about the potential maintenance burden. It's not a small chunk of code and we don't want to deal with another bsddb.

That's the main roadblock to inclusion. Not lack of user demand. Not blindness to the problems with re. Just concerns about maintainability. Add to that some niggling concerns about backwards compatibility in obscure corner cases that may not be exercised by current users. And so we have an impasse. Matthew has indicated he's happy to include it and maintain it as part of the core, but it hasn't really gone anywhere because we don't currently have a good way to address those maintainability concerns (aside from saying "you're worrying about it too much", which isn't what I would call persuasive).

That's what preview gives us: a way to deal with the negative votes that keep positive additions out of the standard library. Most of the PEP's arguments for due diligence etc are actually talking about why we want things in the standard library in the first place, rather than about preview in particular.

The core idea behind the preview namespace is to allow 3 possible responses when a module is proposed for stdlib inclusion:

  1. Yes, that's a good idea, we'll add it (cf. lzma for 3.3)
  2. Maybe, so we'll add it to preview for a release and see if it blows up in our face (hopefully at least regex for 3.3, maybe ipaddr and daemon as well)
  3. No, not going to happen.

Currently, anything where we would answer "2" ends up becoming a "3" by default, and that's not a good thing for the long-term health of the language.

The reason this will be more effective in building core developer confidence than third party distribution via PyPI is due to a few different things:

As far as the criteria for failing to graduate goes, I'd say something that ends up in preview will almost always make it into the main part of the standard library, with the following exceptions:

Really, the main benefit for end users doesn't lie in preview itself: it lies in the positive effect preview will have on the long term evolution of the standard library, as it aims to turn python-dev's inherent conservatism (which is a good thing!) into a speed bump rather than a road block.

Cheers, Nick.

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

More information about the Python-Dev mailing list