> I think the PEP is almost ready for approval. Congratulations! A few comments:
>
> - I'd leave some wiggle room for the docs owner (Georg) about the
> exact formulation of the text blurb included for provisional modules
> and the glossary entry; I don't want the PEP to have the last word
> here.
Sure, Georg is free to modify the pep to amend the formulation if he wants to.
>
> - I think we are settling on the term "feature release" instead of the
> somewhat ambiguous "minor release".
Fixed
>
> - As was discussed at the language summit, I'd like to emphasize that
> the bar for making changes to a provisional package should be
> considered pretty high. That is, while we don't make guarantees about
> backward compatibility, we still expect that most of the API of most
> provisional packages will be unchanged at graduation. Withdrawals
> should also be pretty rare.
>
Added this emphasis at the end of the "Criteria for graduation" section.
> - Should we limit the duration of the provisional state to 1 or 2
> feature releases?
Initially the PEP came out with a 1-release limit, but some of the
devs pointed out
(http://mail.python.org/pipermail/python-dev/2012-February/116406.html)
that me should not necessarily restrict ourselves.
>
> - I'm not sure what to do with regex -- it may be better to just
> include in as "re" and keep the old re module around under another
> name ("sre" has been proposed half jokingly).
>
Document updated in the PEPs Hg, rev a1bb0a9af63f.
Eli
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