[Python-Dev] PEP 408 -- Standard library __preview__ package

[Terry Reedy]

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