On 27/01/2012 22:54, Barry Warsaw 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.)
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?
I think the answer is yes. That's kind of the crux of the matter I guess.
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,
The bugtracker.
*and* how would you adapt your
application to use those better APIs once they became available 18 months from
now?
How do users do it for the standard library? Using the third party
version is one way.
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.
Don't OS vendors go further and say "pin your dependency to the version
we ship", whether it's in the Python standard library or not?
So "just use a more recent version from pypi" is explicitly not an
option for people using system packages. As OS packagers tend to target
a specific version of python, using __preview__ for that version would
be fine - and when they upgrade to the next version applications may
need fixing in the same way as they would if the system packaged a new
release of the third party library. (When moving between Ubuntu
distributions I've found that my software using system packages often
needs to change because the version of some library has now changed.)
Plus having a package in __preview__ has no bearing on whether or not
the system packages the third party version, so I think it's a bit of a
red-herring.
Michael
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
_______________________________________________
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/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
_______________________________________________
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
