Reading the latest discussion about PEP 622/634-636 on the Python Dev mailing
list, I've noticed there appears to be confusion about what `__future__`
imports are supposed to be used for. Multiple people in that thread (and
probably elsewhere in one of the many many threads about these PEPs) have
suggested including pattern matching as a "provisional" or "experimental"
feature that is enabled by an import from `__future__`.
I don't want to discuss whether `__future__` is the correct place for this
however (and I also don't want to discuss PEP 622/634-636 specifically).
Instead I'd like to propose a `__provisional__` namespace (or whatever color
you favor for your bike shed) for new language features/ standard library
modules that might undergo breaking changes over a couple of subsequent python
releases. This is similar to how many applications start in a version V0.1 and
undergo changes until they mature and reach V1.0.
>From the user perspective this would allow more "adventurous" users to play
>with the latest features (with the clear warning attached that they might have
>to adapt their own code over subsequent python releases) while anyone else can
>just ignore the new feature for now. From the perspective of the language
>designers the advantage I see is that they can get a first version of a
>feature out to real users to collect feedback on whether the feature is used
>as they imagined it being used and change/iterate the design if need be. It is
>simply unrealistic to get something like `asyncio` or PEP 622/634-636 perfect
>and feature complete on the first try or otherwise wait indefinitely until
>something is ready.
Some thoughts what `__provisional__` SHOULD and SHOULD NOT be used for:
- `__provisional__` SHOULD be useable at the users own discretion (e.g. no use
of provisional features in the standard library etc. )
- `__provisional__` SHOULD be a place for features with a vast design space
that need to "ripen" as use cases are explored (`asyncio` would have been the
poster child candidate for `__provisional__`)
- features SHOULD only be placed in `__provisional__` if there is a clear
commitment to the feature (the general feature is accepted by the SC before
being included in `__provisional__`). `__provisional__` SHOULD NOT be a place
where contentious PEPs are thrown into willy-nilly and postpone the decision of
whether to accept a PEP or not. Otherwise users would not only have to deal
with changes to a feature (they obviously showed interest in using) but also
with complete removal/deprecation.
- `__provisional__` SHOULD only be used for features that are additive to the
language and don't change existing code (which is what imho. what `__future__`
is for).
- `__provisional__` SHOULD have a clearly defined process (timelines etc.)
Alternative ideas that have been mentioned (in threads about PEP 622/634-636
and elsewhere) and why I personally don't think they are sufficient:
- "just throw together a library that parses strings and uses `eval`, put it
on pypi to see how that goes": For features that require new syntax this just
doesn't work imho. Using `pep622_lib.match("put your match statement here")` is
a very poor substitute for trying this out due to the influence design choices
such as keywords, indentation etc. have on usability. Examples for this are
syntax highlighting, autocomplete/autoindent/autoformat and linting which you
just don't get this way.
- various degrees of: "solve the issue of contention over new languages
features once and for all by introducing macros/preprocessors to the language":
Against this I have just my personal plea "please don't turn python into
lisp/c++".
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3MOCAHEFPQDITY6AHRDIILDB5MZNTYKP/
Code of Conduct: http://python.org/psf/codeofconduct/
