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 [1]. 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__
proposal also.)
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
