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? > 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/archive%40mail-archive.com