Nuts, I accidentally sent this just to Guido (again...)  Sorry Guido!

-------------------------------------

I, for one, am very glad to see this!

I might suggest that changes to correct "bugs" in the language definition (and I don't just mean the documentation) should still be allowed.

I'd like to also point out that the import mechanism (including the concept of the python path, packages, and module initialization) seems to still be messy.  For example, getting two copies of the same module when imported with and without a package prefix, and weird import ordering dependencies.  I guess these would be covered under the "bugs in the language definition" above.  I've wondered too about opening up the whole import process with more hooks to allow other notions of "compiling" and "loading" (for example, being able to import pickles of complex object networks that have been created through some other "compile" process that might still need file modification times checked, but with different file suffixes).  This might help to give some degree of extensibility and support for domain specific languages, for example.

I agree that Python will gain much more through better implementations than through further additions to the language.  (And I don't mean to put down the CPython implementation in any way, it's carried us all a very long way!)  Excluding the C implementation from the moratorium makes sense.

+1

-Bruce

On Wed, Oct 21, 2009 at 12:42 PM, Guido van Rossum <guido@python.org> wrote:
I propose a moratorium on language changes. This would be a period of
several years during which no changes to Python's grammar or language
semantics will be accepted. The reason is that frequent changes to the
language cause pain for implementors of alternate implementations
(Jython, IronPython, PyPy, and others probably already in the wings)
at little or no benefit to the average user (who won't see the changes
for years to come and might not be in a position to upgrade to the
latest version for years after).

The main goal of the Python development community at this point should
be to get widespread acceptance of Python 3000. There is tons of work
to be done before we can be comfortable about Python 3.x, mostly in
creating solid ports of those 3rd party libraries that must be ported
to Py3k before other libraries and applications can be ported. (Other
work related to Py3k acceptance might be tools to help porting, tools
to help maintaining multiple versions of a codebase, documentation
about porting to Python 3, and so on. Also, work like that going on in
the distutils-sig is very relevant.)

Note, the moratorium would only cover the language itself plus
built-in functions, not the standard library. Development in the
standard library is valuable and much less likely to be a stumbling
block for alternate language implementations. 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.

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

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