Sorry for top posting and replying to a random message. I'm on a mobile device, and I fear a decision will be reached before I'm back at a real computer. It would be a shame to prevent any enhancements that would enable us to move forward on the distutils front, now that we finally have some momentum there. I'm thinking primarily of namespace packages (can't easily search for Martin's PEP just now). Most of the work will be in libraries, but adding a few core features might make things easier or better. But even if that didn't make the cut, I'm at least +0 on the idea. -- Eric. "Guido van Rossum" <guido@python.org> wrote:

On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <python@rcn.com> wrote:

...

[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.

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.

...

...

 I also want to exclude details of the CPython implementation, including the C API from being completely frozen -- for example, if someone came up with (otherwise acceptable) changes to get rid of the GIL I wouldn't object.

FWIW, I have pending updates for the set/frozenset implementation (no api change).

If it's just performance that's fine. If there's more I'd like to hear more details first.

...

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.

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?

...

...

But the moratorium would clearly apply to proposals for anonymous blocks, "yield from" (PEP 380), changes to decorator syntax, and the like. (I'm sure it won't stop *discussion* of those proposals, and that's not the purpose of the moratorium; but at least it will stop worries elsewhere that such proposals might actually be *accepted* any time soon.)

Are you rejecting PEP 380?

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/) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas