[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-dev
Subject:    Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
From:       "Gregory P. Smith" <greg () krypto ! org>
Date:       2012-01-29 21:39:10
Message-ID: CAGE7PNJv1Vqji49PeBz2xDjFrGUovXpUN5xWeC80ym7FYmP_yQ () mail ! gmail ! com
[Download RAW message or body]

On Fri, Jan 27, 2012 at 9:26 AM, Alex <alex.gaynor@gmail.com> wrote:
> Eli Bendersky <eliben <at> gmail.com> writes:
>
>>
>> Hello,
>>
>> Following an earlier discussion on python-ideas [1], we would like to
>> propose the following PEP for review. Discussion is welcome. The PEP
>> can also be viewed in HTML form at
>> http://www.python.org/dev/peps/pep-0408/
>>
>> [1] http://mail.python.org/pipermail/python-ideas/2012-January/013246.ht=
ml
>>
>
> I'm -1 on this, for a pretty simple reason. Something goes into __preview=
__,
> instead of it's final destination directly because it needs feedback/poss=
ibly
> changes. However, given the release cycle of the stdlib (~18 months), any
> feedback it gets can't be seen by actual users until it's too late. Essen=
tially
> you can only get one round of stdlib.
>
> I think a significantly healthier process (in terms of maximizing feedbac=
k and
> getting something into it's best shape) is to let a project evolve natura=
lly on
> PyPi and in the ecosystem, give feedback to it from an inclusion perspect=
ive,
> and then include it when it becomes ready on it's own merits. The counter
> argument to =A0this is that putting it in the stdlib gets you signficantl=
y more
> eyeballs (and hopefully more feedback, therefore), my only response to th=
is is:
> if it doesn't get eyeballs on PyPi I don't think there's a great enough n=
eed to
> justify it in the stdlib.

-1 from me as well.

How is the __preview__ namespace any different than the
PendingDeprecationWarning that nobody ever uses?  Nobody is likely to
write significant code depending on anything in __preview__ thus the
amount of feedback received would be low.

A better way to get additional feedback would be to promote libraries
that we are considering including by way of direct links to them on
pypi from the relevant areas of the Python documentation (including
the Module Reference / Index pages?) for that release and let the
feedback on them roll in via that route.

An example of this working: ipaddr is ready to go in. It got the
eyeballs and API modifications while still a pypi library as a result
of the discussion around the time it was originally suggested as being
added.  I or any other committers have simply not added it yet.

-gps
_______________________________________________
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/python-dev%4=
0progressive-comp.com
[prev in list] [next in list] [prev in thread] [next in thread]