On 27/01/2012 15:09, Antoine Pitrou wrote: > On Fri, 27 Jan 2012 15:21:33 +0200 > Eli Bendersky<eliben at 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 at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4