On Fri, 27 Jan 2012 17:54:14 -0500 Barry Warsaw <ba...@python.org> wrote: > On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote: > > >On Fri, 27 Jan 2012 16:10:51 -0500 > >Barry Warsaw <ba...@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.)
That's my opinion too. But using it in production doesn't mean you lose control on the code and its users. Perhaps you are used to a kind of production where the code gets disseminated all over the GNUniverse :) But for most people "production" means a single server or machine where they have entire control. > 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? For the former, the normal channels probably apply (bug tracker or python-dev). For the latter, depending on the API change, catching e.g. AttributeError on module lookup, or TypeError on function call, or explicitly examining the Python version are all plausible choices. Let's take another example: the regex module, where the API is unlikely to change much (since it's meant to be re-compatible), and the main concerns are ease of maintenance, data-wise compatibility with re (rather than API-wise), performance, and the like. > 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. Hmm, isn't that a bit pessimistic about our users? > 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? Well, is the application supported upstream? If yes, then there shouldn't be any additional burden. If no, then you have a complication indeed. > A robust, standard approach to > versioning of modules would though, and I think would better solve what > __preview__ is trying to solve. I don't think versioning can replace API stability. __preview__ is explicitly and visibly special, and that's a protection against us becoming too complacent. > >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. Obviously you would only use a module from __preview__ if the functionality is exciting enough for you (or the cost/benefit ratio is good enough). Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
