On 27/01/2012 15:09, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Bendersky<eli...@gmail.com> wrote:
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/
A big +1 from me.
Assuming the module is then promoted to the the standard library proper in
release ``3.X+1``, it will be moved to a permanent location in the library::
import example
And importing it from ``__preview__`` will no longer work.
Why not leave it accessible through __preview__ too?
+1
The point about pickling is one good reason, minimising code breakage
(due to package name changing) is another.
Michael
Benefits for the core development team
--------------------------------------
Currently, the core developers are really reluctant to add new interfaces to
the standard library.
A nit, but I think "reluctant" is enough and "really" makes the
tone very defensive :)
Relationship with PEP 407
=========================
PEP 407 proposes a change to the core Python release cycle to permit interim
releases every 6 months (perhaps limited to standard library updates). If
such a change to the release cycle is made, the following policy for the
``__preview__`` namespace is suggested:
* For long term support releases, the ``__preview__`` namespace would always
be empty.
* New modules would be accepted into the ``__preview__`` namespace only in
interim releases that immediately follow a long term support release.
Well this is all speculative (due to the status of PEP 407) but I think
a simpler approach of having a __preview__ namespace in all releases
(including LTS) would be easier to handler for both us and our users.
People can refrain from using anything in __preview__ if that's what
they prefer. The naming and the double underscores make it quite
recognizable at the top of a source file :-)
Preserving pickle compatibility
-------------------------------
A pickled class instance based on a module in ``__preview__`` in release 3.X
won't be unpickle-able in release 3.X+1, where the module won't be in
``__preview__``. Special code may be added to make this work, but this goes
against the intent of this proposal, since it implies backward compatibility.
Therefore, this PEP does not propose to preserve pickle compatibility.
Wouldn't it be a good argument to keep __preview__.XXX as an alias?
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/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
