[Python-Dev] PEP 408 -- Standard library __preview__ package
tjreedy at udel.edu
Sun Jan 29 00:47:23 CET 2012
On 1/28/2012 3:55 AM, Nick Coghlan wrote:
I am currently -something on the proposal as it because it will surely
create a lot of hassles and because I do not think it is necessary the
best solution to the motivating concerns.
> Don't consider this PEP a purely theoretical proposal, because it
> isn't. It's really being put forward to solve a specific problem: the
> fact that we need to do something about re's lack of proper Unicode
> support . Those issues are actually hard to solve, so replacing re
> with Matthew Barnett's regex module (just as re itself was a
> replacement for the original regex module) that already addresses most
> of them seems like a good way forward, but this is currently being
> blocked because there are still a few lingering concerns with
> maintainability and backwards compatibility.
I find the concern about 'maintainability' a bit strange as regex seems
to be getting more maintainance and improvement than re. The re author
is no longer active. If neither were in the library, and we were
considering both, regex would certainly win, at least from a user view.
Tom Christiansen reviewed about 8 unicode-capable extended r. e.
packages, including both re and regex, and regex came out much better.
The concern about back compatibility ignores the code that re users
cannot write. In any case, that problem would be solved by adding regex
in addition to re instead of as a replacement. If it were initially
added as __preview__.regex, would the next step be to call it regex? or
change it to re and remove the current package?. If the former, I think
we might as well do it now. If the latter, that is different from what
the pep proposes.
> While regex is the current poster-child for this problem,
I see it as a special case that is not really addressed by the Pep.
The other proposed use-case for __preview__ is packages whose api is not
stable. Such packages may need their api changed a lot sooner than 18-24
months. Or, their api may change for a lot longer than just one release
cycle. So the PEP would be best suited for packages who api may be fixed
but might need code-breaking adjustments *once* in 18 months.
A counter-proposal: add an __x__ package to site-packages. Document the
contents separately in an X-Library manual. Let the api of such packages
change with every micro release. Don't guarantee that modules won't
disappear completely. Don't put a time limit on residence there before
being moved up (to the stdlib) or out. Packages that track volatile
external standards could stay there indefinitely.
If an module is moved to stdlib, leave a stub for at least two versions
that emits a deprecation warning (to switch to import a instead of
__x__.a) and a notice that the doc has moved, along with importing the
contents of the stdlib version. (This would work for the __preview__
Terry Jan Reedy
More information about the Python-Dev