[Python-ideas] Proposal: Moratorium on Python language changes

Bruce Frederiksen dangyogi at gmail.com
Wed Oct 21 20:14:06 CEST 2009


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 at 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/<http://www.python.org/%7Eguido/>
> )
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20091021/4bd3fff5/attachment.html>


More information about the Python-ideas mailing list