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

Barry Warsaw barry at python.org
Fri Jan 27 23:54:14 CET 2012

On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:

On Fri, 27 Jan 2012 16:10:51 -0500 Barry Warsaw <barry at python.org> wrote:

I'm -1 on this as well. It just feels like the completely wrong way to stabilize an API, and I think despite the caveats that are explicit in preview, Python will just catch tons of grief from users and haters about API instability anyway, because from a practical standpoint, applications written using preview APIs will be less stable. Well, obviously preview is not for the most conservative users. I think the name clearly conveys the idea that you are trying out something which is not in its definitive state, doesn't it?

Maybe. I could quibble about the name, but let's not bikeshed on that right now. The problem as I see it is that preview will be very tempting to use in production. In fact, its use case is almost predicated on that. (We want you to use it so you can tell us if the API is good.)

Once people use it, they will probably ship code that relies on it, and then the pressure will be applied to us to continue to support that API even if a newer, better one gets promoted out of preview. I worry that over time, for all practical purposes, there won't be much difference between preview and the stdlib.

>I think a significantly healthier process (in terms of maximizing feedback >and getting something into it's best shape) is to let a project evolve >naturally on PyPi and in the ecosystem, give feedback to it from an inclusion >perspective, and then include it when it becomes ready on it's own >merits. The counter argument to this is that putting it in the stdlib gets >you signficantly more eyeballs (and hopefully more feedback, therefore), my >only response to this is: if it doesn't get eyeballs on PyPi I don't think >there's a great enough need to justify it in the stdlib.

I agree with everything Alex said here. The idea that being on PyPI is sufficient is nice but flawed (the IPaddr example). PyPI doesn't guarantee any visibility (how many packages are there?). Furthermore, having users is not a guarantee that the API is appropriate, either; it just means that the API is appropriate for some users.

I can't argue with that, it's just that I don't think preview solves that problem. And it seems to me that preview introduces a whole 'nother set of problems on top of that.

So taking the IPaddr example further. Would having it in the stdlib, relegated to an explicitly unstable API part of the stdlib, increase eyeballs enough to generate the kind of API feedback we're looking for, without imposing an additional maintenance burden on us? If you were writing an app that used something in preview, how would you provide feedback on what parts of the API you'd want to change, and how would you adapt your application to use those better APIs once they became available 18 months from now? I think we'll just see folks using the unstable APIs and then complaining when we remove them, even though they know upfront that these APIs will go away.

I'm also nervous about it from an OS vender point of view. Should I reject any applications that import from preview? Or do I have to make a commitment to support those APIs longer than Python does because the application that uses it is important to me?

I think the OS vendor problem is easier with an application that uses some PyPI package, because I can always make that package available to the application by pulling in the version I care about. It's harder if a newer, incompatible version is released upstream and I want to provide both, but I don't think preview addresses that. A robust, standard approach to versioning of modules would though, and I think would better solve what preview is trying to solve.

On the other hand, preview would clearly signal that something is on the verge of being frozen as an official stdlib API, and would prompt people to actively try it.

I'm not so sure about that. If I were to actively try it, I'm not sure how much motivation I'd have to rewrite key parts of my code when an incompatible version gets promoted to the un__preview__d stdlib.

-Barry

More information about the Python-Dev mailing list