Re: [Python-ideas] Proposal: Moratorium on Python language changes
[Guido van Rossum]
Note, the moratorium would only cover the language itself plus built-in functions, not the standard library.
That makes sense. There may be a few areas that still have some rough edges where you may want to allow changes if needed (tweaks to the nested with-statement syntax, bytes/text interaction, star-args unpacking, or string formatting). These areas probably have not been exercised much and there may still be problems that need to be ironed-out. I don't have anything specific in mind. Am just thinking that those features aren't yet mature. Also, do you know if there any plans afoot to do something with function annotations?
FWIW, I have pending updates for the set/frozenset implementation (no api change). Also, I'm hoping the recently submitted C implementation for decimal gets accepted (as performance issues seem to be slowing broader use of the module). It looks like substantial work has already been done.
Are you rejecting PEP 380? Raymond
On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <python@rcn.com> wrote:
No, the moratorium would freeze the language at the 3.1 version, at least for 3.2 and 2.7 and possibly 3.3 (see my earlier post). Allowing for exceptions like these provides too much wiggle room. (E.g is the decorator syntax broken?) Outright bugs in the implementation should be excepted (subject to discussion) but the accepted grammar and semantics should be frozen unless they are unimplementable.
Also, do you know if there any plans afoot to do something with function annotations?
I don't. Giving them more semantics would fall under the moratorium; however some implementations might have optional extensions that don't. I can also see that implementations which support interaction with APIs defined in other languages (chiefly IronPython and Jython) might define semantics for function annotation syntax in certain cases where it benefits interaction with other languages -- this would be in code that is naturally restricted to that implementation anyway.
If it's just performance that's fine. If there's more I'd like to hear more details first.
I don't think that "work on a feature has already begun" should be an argument for granting an exception. However I expect that in this specific case this falls under the library, which is not directly covered by the moratorium. I think I saw that it could be made optional, so that if the C implementation isn't found the Python implementation still works?
No, just deferring it. It didn't make Python 3.1 so I think we'll have to live without it for a long time no matter what. It could be revisited once the moratorium is lifted (for 3.3 or 3.4). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I'd like there to be the possibility of a change if we were to discover a case (a corner case, perhaps) where everyone agrees that what Python is actually doing is unPythonic due to some unforeseen combination of factors (and I'm not talking about mutable default parameters). Who knows, it could happen! :-)
MRAB schrieb:
Please relax. We're not going to pass a law, or institute a commit hook that will reject each and every change to the relevant files. Whatever eventual form the moratorium is going to take, it does not stand above reasonable discussion. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Guido van Rossum writes:
On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <python@rcn.com> wrote:
Would it be useful to allow work on it, maybe including a deferred approval (ie, PEP is approved for implementation in version 3.3 [or "when the moratorium is lifted"]), to proceed on a branch? Branches will be very cheap in hg. I realize this may "bring work forward" for you and other interested parties, on the other hand I think there is a "strike while the iron's hot" aspect for implementators of the PEP. In particular, having a working and approved feature on a branch would allow those interested in the deferred PEP to merge into a (private) fresh branch for compatibility testing of the work being done on the mainline.
On Thu, Oct 22, 2009 at 12:14 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I'd be okay with this, for the specific case of PEP 380. The work was all done but there was remaining discussion about precise semantics, which dragged the approval out enough to miss the 2.6 release. Looking back I still don't think the arguments put forward by a Danish gentleman (whose name I've forgotten, sorry) are worth the complications in semantics and implementation; but if there was a branch and some people tried to use it for real code it would be a lot easier to tell (especially if there were two branches implementing the competing proposals). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <python@rcn.com> wrote:
No, the moratorium would freeze the language at the 3.1 version, at least for 3.2 and 2.7 and possibly 3.3 (see my earlier post). Allowing for exceptions like these provides too much wiggle room. (E.g is the decorator syntax broken?) Outright bugs in the implementation should be excepted (subject to discussion) but the accepted grammar and semantics should be frozen unless they are unimplementable.
Also, do you know if there any plans afoot to do something with function annotations?
I don't. Giving them more semantics would fall under the moratorium; however some implementations might have optional extensions that don't. I can also see that implementations which support interaction with APIs defined in other languages (chiefly IronPython and Jython) might define semantics for function annotation syntax in certain cases where it benefits interaction with other languages -- this would be in code that is naturally restricted to that implementation anyway.
If it's just performance that's fine. If there's more I'd like to hear more details first.
I don't think that "work on a feature has already begun" should be an argument for granting an exception. However I expect that in this specific case this falls under the library, which is not directly covered by the moratorium. I think I saw that it could be made optional, so that if the C implementation isn't found the Python implementation still works?
No, just deferring it. It didn't make Python 3.1 so I think we'll have to live without it for a long time no matter what. It could be revisited once the moratorium is lifted (for 3.3 or 3.4). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I'd like there to be the possibility of a change if we were to discover a case (a corner case, perhaps) where everyone agrees that what Python is actually doing is unPythonic due to some unforeseen combination of factors (and I'm not talking about mutable default parameters). Who knows, it could happen! :-)
MRAB schrieb:
Please relax. We're not going to pass a law, or institute a commit hook that will reject each and every change to the relevant files. Whatever eventual form the moratorium is going to take, it does not stand above reasonable discussion. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Guido van Rossum writes:
On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <python@rcn.com> wrote:
Would it be useful to allow work on it, maybe including a deferred approval (ie, PEP is approved for implementation in version 3.3 [or "when the moratorium is lifted"]), to proceed on a branch? Branches will be very cheap in hg. I realize this may "bring work forward" for you and other interested parties, on the other hand I think there is a "strike while the iron's hot" aspect for implementators of the PEP. In particular, having a working and approved feature on a branch would allow those interested in the deferred PEP to merge into a (private) fresh branch for compatibility testing of the work being done on the mainline.
On Thu, Oct 22, 2009 at 12:14 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I'd be okay with this, for the specific case of PEP 380. The work was all done but there was remaining discussion about precise semantics, which dragged the approval out enough to miss the 2.6 release. Looking back I still don't think the arguments put forward by a Danish gentleman (whose name I've forgotten, sorry) are worth the complications in semantics and implementation; but if there was a branch and some people tried to use it for real code it would be a lot easier to tell (especially if there were two branches implementing the competing proposals). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
Georg Brandl -
Guido van Rossum -
MRAB -
Raymond Hettinger -
Stephen J. Turnbull