[Python-ideas] Proposal: Moratorium on Python language changes
Guido van Rossum
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...@python.org
http://mail.python.org/mailman/listinfo/python-ideas
Stefan Behnel
> 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)
As one of the lead developers of the Cython project, which is following
CPython at some distance but at fast pace (and high speed ;), I honestly
wouldn't mind such a moratorium.
As a Python language user, I must say that I cannot remember any recent(?)
language syntax proposal on python-ideas that would have made the language
substantially better. Plus, a lot of the code that gets written even today
is still required to stay Py2.x compatible, sometimes as old as 2.3.
Especially library or tooling code will often not even use Python 2.6
features for a while, let alone Python 3.x features. That doesn't mean you
can't 2to3 it, it just means that it won't use the new syntax features.
I guess that makes a +1 from my side.
Stefan
Jesse Noller
+1; modulo getting PEP 380 in before the moratorium ;)
I think a fair amount of our time and work is better spent on the
stdlib, various implementation(s) and things of that nature
(ecosystem).
jesse
Calvin Spealman
+1 to speeding up the gap-closing between 2.x and 3.x maturity and
making the fielding of "When shoudl I start using 3.x?" questions
easier.
--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
Collin Winter
> 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).
+1
Guido van Rossum
> +1; modulo getting PEP 380 in before the moratorium ;)
I see the smiley, but just in case you were half serious, I really
think we should stick to the policy and not make exceptions for
personal pet peeves.
> I think a fair amount of our time and work is better spent on the
> stdlib, various implementation(s) and things of that nature
> (ecosystem).
Of course, no moratorium can stop people from *proposing* changes, but
it helps core developers and others who "just want to get stuff done"
focus if they know we're not changing the language for quite a while.
Effectively the moratorium would freeze the language at the 3.1
version at least for 3.2 and possibly for 3.3. Also 2.7 could not add
language changes except possibly changes to keep up with 3.1 (but only
if *very* strict backwards compatibility with 2.6 is maintained also
-- I want the upgrade from 2.6 to 2.7 to be a breeze for everyone).
Obviously there are many things we could change in the standard
library that would still affect the ability to upgrade easily (see the
recent issues with 2.6.3 and 2.6.4), and we should be exercising a lot
of restraint in this are as well. But language changes affect other
implementations the most (I think). They also coincidentally speak
most to the imagination of the young, eager-to-add-their-pet-feature
amateur language designer crowd who so often fill python-ideas with
heated discussions.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Bruce Frederiksen
-------------------------------------
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
Jesse Noller
> I see the smiley, but just in case you were half serious, I really
> think we should stick to the policy and not make exceptions for
> personal pet peeves.
The only reason I would argue against that would be for the fact that
AFAIK, it's "nearly done and ready" - that being said, that is a
specious argument.
But I agree - no exceptions makes sense.
> Obviously there are many things we could change in the standard
> library that would still affect the ability to upgrade easily (see the
> recent issues with 2.6.3 and 2.6.4), and we should be exercising a lot
> of restraint in this are as well. But language changes affect other
> implementations the most (I think). They also coincidentally speak
> most to the imagination of the young, eager-to-add-their-pet-feature
> amateur language designer crowd who so often fill python-ideas with
> heated discussions.
Agreed; there's been discussion on disutils-sig and other places (such
as the language summit) revolving around a "single, shared" standard
library for all of the implementations. So long as the syntax is
unchanged, we can upgrade/improve the stdlib over time, and make it
used for the various implementations.
jesse
Raymond Hettinger
> 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?
> 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).
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.
> 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?
Raymond
Guido van Rossum
> I might suggest that changes to correct "bugs" in the language definition
> (and I don't just mean the documentation) should still be allowed.
Depends on your definition of "bug". I would like to see this on a
case-by-case basis.
> 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.
Well, for better or for worse, changing that is *also* going to be
messy and a compatibility nightmare. To some extent the details of the
import mechanism is up to the implementation anyway, so this may not
realistically be affected by the moratorium. If you want to discuss
these issues in detail I recommend that you start a new thread and be
prepared to hear "but that's just pilot error" about many of the
perceived "bugs".
> 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.
Actually, I think we already have enough import hooks, and this is an
area where I would tread very carefully. There is nothing stopping
people from using these mechanisms now, but still they are rarely used
-- I don't expect that adding new types of hooks will change that.
> 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
--
Georg Brandl
> On Wed, Oct 21, 2009 at 10:43 AM, Jesse Noller <jno...@gmail.com> wrote:
>> +1; modulo getting PEP 380 in before the moratorium ;)
>
> I see the smiley, but just in case you were half serious, I really
> think we should stick to the policy and not make exceptions for
> personal pet peeves.
Well, the moratorium isn't yet in place (which I also gather from you
posting that on the ideas list), so would be nothing wrong implementing
something before it starts... :)
Anyway, I'm not sure how much impact this will have; already there are
very few real language changes going on; after 2.6, whose such changes
mostly were Python 3 backports. In 2.7, the multi-with syntax is the
only real language change so far.
(When you say "builtins", do you e.g. include the str.format() mini-language?
There has been a lot of work on that lately, to fix ambiguous corner-cases.)
I'm not saying it's a bad idea, but while it might stop a few threads on
python-dev, it won't change a lot in terms of how core development
time is spent.
cheers,
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
> [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/)
Guido van Rossum
> Well, the moratorium isn't yet in place (which I also gather from you
> posting that on the ideas list), so would be nothing wrong implementing
> something before it starts... :)
No, the moratorium would freeze the language at the version
implemented in 3.1. If necessary we'd have to roll back core language
changes (primarily syntax, or new builtins) made since 3.1 was
released.
> Anyway, I'm not sure how much impact this will have; already there are
> very few real language changes going on; after 2.6, whose such changes
> mostly were Python 3 backports. In 2.7, the multi-with syntax is the
> only real language change so far.
>
> (When you say "builtins", do you e.g. include the str.format() mini-language?
> There has been a lot of work on that lately, to fix ambiguous corner-cases.)
I think fixing ambiguous corner cases can proceed.
> I'm not saying it's a bad idea, but while it might stop a few threads on
> python-dev, it won't change a lot in terms of how core development
> time is spent.
My main goal is to set expectations right -- people who spend effort
porting to 3.1 should not be confronted with further effort caused by
the upgrade to 3.2.
(An alternative would be to postpone the release of 3.2 until the
moratorium is over, but this would unnecessarily constrain further
development of the library.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Daniel Stutzbach
I might suggest that changes to correct "bugs" in the language definition (and I don't just mean the documentation) should still be allowed.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC
geremy condra
I can't disagree with the sentiment, and I wholeheartedly agree with
the idea that shifting the focus from language development to library
development is a good idea- but I would caution against making the
moratorium too hard-and-fast, or too long lasting, assuming that
the goal isn't to make it de facto permanent.
Towards that end, I'd also like to propose a very public, very
accessible 'sandbox' specifically for the development and testing of
new language features while the moratorium is in effect. Its goal
would be to keep interest in changes to core language design
ongoing by keeping the barrier to entry low, while simultaneously
separating it from core development. With any luck, it would mean
that when the moratorium lifts, Python will be able to take its pick
from the best of the language proposals, while still having given
other implementations the opportunity to study their behavior
"in the wild" for a period of months or years.
Geremy Condra
Guido van Rossum
<dan...@stutzbachenterprises.com> wrote:
> On Wed, Oct 21, 2009 at 1:14 PM, Bruce Frederiksen <dang...@gmail.com>
> wrote:
>>
>> 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 suggest allowing an exception for changes that make life *easier* for
> alternative implementations. That would allow for fixing "bugs", making
> small improvements to new features added in Python 3, etc. As long as it
> passes the test of making life easier for alternative implementations
> instead of more difficult.
This is reasonable. We should discuss this at the Language Summit at
the next PyCon.
Daniel Stutzbach
Towards that end, I'd also like to propose a very public, veryaccessible 'sandbox' specifically for the development and testing of
new language features while the moratorium is in effect.
Guido van Rossum
> Towards that end, I'd also like to propose a very public, very
> accessible 'sandbox' specifically for the development and testing of
> new language features while the moratorium is in effect. Its goal
> would be to keep interest in changes to core language design
> ongoing by keeping the barrier to entry low, while simultaneously
> separating it from core development. With any luck, it would mean
> that when the moratorium lifts, Python will be able to take its pick
> from the best of the language proposals, while still having given
> other implementations the opportunity to study their behavior
> "in the wild" for a period of months or years.
I can't stop people from forking the language to do experiments, but
one of the goals I have for the moratorium is actually to *reduce* the
interest in core language changes, and to *raise* the barrier to
entry. Most language change proposals are just fluff, and they will be
just as unneeded three years from now as they are today. Once the
moratorium is lifted, users should be able expect the normal, slow,
conservative evolution of the language to continue -- not to see the
floodgates lifted for a barrage of new features.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Dino Viehland
> > I think a fair amount of our time and work is better spent on the
> > stdlib, various implementation(s) and things of that nature
> > (ecosystem).
>
> Of course, no moratorium can stop people from *proposing* changes, but
> it helps core developers and others who "just want to get stuff done"
> focus if they know we're not changing the language for quite a while.
>
> Effectively the moratorium would freeze the language at the 3.1
> version at least for 3.2 and possibly for 3.3. Also 2.7 could not add
> language changes except possibly changes to keep up with 3.1 (but only
> if *very* strict backwards compatibility with 2.6 is maintained also
> -- I want the upgrade from 2.6 to 2.7 to be a breeze for everyone).
>
> Obviously there are many things we could change in the standard
> library that would still affect the ability to upgrade easily (see the
> recent issues with 2.6.3 and 2.6.4), and we should be exercising a lot
> of restraint in this are as well. But language changes affect other
> implementations the most (I think). They also coincidentally speak
> most to the imagination of the young, eager-to-add-their-pet-feature
> amateur language designer crowd who so often fill python-ideas with
> heated discussions.
This generally sounds nice for us and will make it easier to catch up
to 3.x as well as make it easier to continue to flush out other missing
built-in modules. But I would actually be really happy with just a partial
freeze though - I actually find support for new standard library features
is typically the biggest hit for us and that core language features (modulo
import related features which are always difficult ) have generally not
been an issue.
For example consider multiprocessing - which IronPython still doesn't
support. That's a much bigger work item than everything that changed
related to parsing in 2.6. New built-in functions can also be a huge
pain - again compare float.fromhex to everything that happened to the
parser in 2.6. I'm pretty sure I spent more time on float.fromhex even
w/ the already existing awesome test suite.
So I definitely think not adding significant new functionality to the core
interpreter would be great but from an alternate implementation perspective
I'd also be happy to see some wiggle room on small new features.
Jesse Noller
> For example consider multiprocessing - which IronPython still doesn't
> support. That's a much bigger work item than everything that changed
> related to parsing in 2.6. New built-in functions can also be a huge
> pain - again compare float.fromhex to everything that happened to the
> parser in 2.6. I'm pretty sure I spent more time on float.fromhex even
> w/ the already existing awesome test suite.
I don't think IronPython should support multiprocessing, personally.
While there are a few things within it that probably make sense
(managers and the like) does it really make a ton of sense to run
multiple iron python VMs from a single parent?
The same applies (in the case of multiprocessing) to Jython - a single
JVM forking multiple JVMs doesn't necessarily make sense when you have
perfectly functional threads. Then again, this depends on your
perspective.
When splitting out the stdlib was discussed at the language summit
last year, this was discussed, and at the time a few people suggested
allowing some stdlib modules to be marked at "cpython-only" - this
means other implementations could omit/skip those modules (and not
ship them).
jesse
Antoine Pitrou
>
> Once the transition to Mercurial is complete, making experimental forks of
> CPython to play with new language features will be a breeze.
There are already Mercurial branches, they are read-only but it's sufficient if
you want to clone them and create your own branches while still tracking
upstream changes.
Regards
Antoine.
MRAB
> On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <pyt...@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.
>
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! :-)
Fred Drake
> several years during which no changes to Python's grammar or language
> semantics will be accepted.
+1
While there are changes that I'd like to see, a moratorium for a few
years would benefit all of us in the long run:
- It's easier for companies to justify training.
- It's easier to gain adoption for long-term projects.
- It's easier to hold the attention of potential contributors for bug fixes.
(And for many other reasons, but those are big ones in my book these days.)
-Fred
--
Fred L. Drake, Jr. <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller
Eric Smith
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" <gu...@python.org> wrote:
>On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <pyt...@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/)
Jesse Noller
> 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.
Distutils != core language syntax. Distutils was already mentioned in
guido's original email, and given it's a standard library module, it
can continue to evolve.
jesse
Dino Viehland
> I don't think IronPython should support multiprocessing, personally.
> While there are a few things within it that probably make sense
> (managers and the like) does it really make a ton of sense to run
> multiple iron python VMs from a single parent?
The problem w/ this is that people are going to use multiprocessing
and then someone is going to try running code which uses it on
IronPython/Jython and it isn't going to work. So maybe we could have
a version of multiprocessing that transparently works in a completely
different fashion under the hood but it seems like the module should
still exist and be usable.
geremy condra
> On Wed, Oct 21, 2009 at 11:52 AM, geremy condra <deba...@gmail.com> wrote:
>> Towards that end, I'd also like to propose a very public, very
>> accessible 'sandbox' specifically for the development and testing of
>> new language features while the moratorium is in effect. Its goal
>> would be to keep interest in changes to core language design
>> ongoing by keeping the barrier to entry low, while simultaneously
>> separating it from core development. With any luck, it would mean
>> that when the moratorium lifts, Python will be able to take its pick
>> from the best of the language proposals, while still having given
>> other implementations the opportunity to study their behavior
>> "in the wild" for a period of months or years.
>
> I can't stop people from forking the language to do experiments, but
> one of the goals I have for the moratorium is actually to *reduce* the
> interest in core language changes, and to *raise* the barrier to
> entry. Most language change proposals are just fluff, and they will be
> just as unneeded three years from now as they are today. Once the
> moratorium is lifted, users should be able expect the normal, slow,
> conservative evolution of the language to continue -- not to see the
> floodgates lifted for a barrage of new features.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
Granted that most language change proposals could only be
described as "terrible" by a person of unusual charity, but if
the goal here isn't to permanently forbid all changes, then it
makes sense (to me) to ensure that we're in a better position
when we leave the moratorium than when we go into it.
Right now, the barrier for proposing a language change is
pretty much nonexistent- you dreamed it up in the shower,
read about it in a trade magazine, your dog told you it was
a good idea, doesn't matter- put it on python-ideas. The
problem (as I see it) is that after proposing the idea,
wasting a lot of time, and causing a lot of drama, the fact
remains that even if the OP finally gets their way, the odds
are good that it will take a substantial amount of work from
people who have better things to do- the core developers-
to make it work. And it only gets worse for the other
implementors, who probably didn't have as much input in
the process as the CPython devs did.
Changing the way that core language changes are proposed
and evaluated changes that a lot, though. In the scenario
I've proposed, we are in effect saying "write the code and
if it gets a lot of support we'll talk about including it in a few
years". It shifts the responsibility for development from the
core dev team to the one proposing the change. I'm
confident that that alone would cut out most of the proposals
on python-ideas, while ensuring that whatever was up for
consideration at the point where the moratorium lifts
was high-quality, well thought out code that had probably
been looked at pretty closely by other implementors for
several years. Personally, I think that's a much better
place to be than either where we are now or where
we'll be in a few years without some sort of brainstorm
bin.
Geremy Condra
Georg Brandl
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.
_______________________________________________
Jesse Noller
> Jesse wrote:
>> I don't think IronPython should support multiprocessing, personally.
>> While there are a few things within it that probably make sense
>> (managers and the like) does it really make a ton of sense to run
>> multiple iron python VMs from a single parent?
>
> The problem w/ this is that people are going to use multiprocessing
> and then someone is going to try running code which uses it on
> IronPython/Jython and it isn't going to work. So maybe we could have
> a version of multiprocessing that transparently works in a completely
> different fashion under the hood but it seems like the module should
> still exist and be usable.
>
I'm game, I just have reservations about doing this - something like
multiprocessing that isn't multiprocessing means certain
things/expectations applications might have could break in a dummy
context.
Since we're derailing, I'm game talking about this privately so we can
pass ideas back and forth.
jesse
Mathias Panzenböck
feature freeze of the version that will represent the feature set of the
moratorium. So this should have been announced before 3.1 was released.
-panzi
Brett Cannon
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.)
Antoine Pitrou
>
> Note, the moratorium would only cover the language itself plus
> built-in functions, not the standard library.
Out of curiousity, would it preclude adding e.g. a method to a built-in type?
(I'm not saying this with anything specific in mind)
Regards
Antoine.
Brett Cannon
I think if such a moratorium is instated it should be announced way before the
feature freeze of the version that will represent the feature set of the
moratorium. So this should have been announced before 3.1 was released.
Sturla Molden
> 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
(as in ISO, ECMA, ANSI, IEEE) for the Python language? ISO
standardization of C++ has not prevented GNU, Borland, Microsoft, and
others to implement proprietary language extensions in their C++
compilers. But if we stick to writing standard C++, it will compile on
standard compliant C++ compilers from any vendor. As I see it, the
problem is not "language changes", but one implementation (CPython)
being the "de facto" Python language standard. Maybe there should be a
real Python standard? A syntax change in CPython would be a CPython
specific language extension (like GNU extensions to C), not a language
change. Today, a syntax change in CPython is a redefinition of the
Python language. That will be avoided with a standard.
Cython (and Pyrex before) adds many extensions to the Python language,
while aiming at being compliant with "pure Python". But what is "pure
Python" anyway? It would be much easier for everyone if there was a
piece of paper defining the Python language -- and possibly certain
critical parts of the standard library.
Also, an industry standard for the Python language would help adoption
of Python in many organizations. Except for Java, only standardized
languages tend to be considered for large projects. Many has strict
policies of only using standardized languages to ensure availability of
compilers/interpreters in the future.
Personally I think Python 3000 is mature enough for a standard.
Sturla Molden
Antoine Pitrou
>
> Isn't this the same as saying it is time to produce an industry standard
> (as in ISO, ECMA, ANSI, IEEE) for the Python language?
If we had plenty of workforce available it might be an idea.
But we have not, and fixing bugs and making improvements is a much better use of
volunteer time than language lawyering, IMO.
> Except for Java, only standardized
> languages tend to be considered for large projects.
The "except for Java" statement makes me think that standardization isn't a real
criterion here. Stability may be, however.
Antoine.
Guido van Rossum
> Guido van Rossum <guido@...> writes:
>>
>> Note, the moratorium would only cover the language itself plus
>> built-in functions, not the standard library.
>
> Out of curiousity, would it preclude adding e.g. a method to a built-in type?
> (I'm not saying this with anything specific in mind)
And I can't answer without anything specific in front of me.
I think it's time for someone to draft a PEP for me summarizing some
of the points of this discussion.
Some specific quick responses before I run off to do real work:
- no, I don't think it should have been announced before 3.1 was frozen
- no, I don't think we need an ISO standard
- no, it's not decided yet
- no, it's not an absolute law (actually typical laws have lots of
gray areas too)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Georg Brandl
> 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).
>
>
> +1 from me. In this rather long thread someone proposed allowing changes
> that make implementation of the language easier, which I am also fine
> with, but that could almost be classified a bug fix and taken on a
> case-by-case basis. But completely new exposed syntax or semantics for
> the language and built-ins should be off limits.
>
> And for the "several years", I say make through 3.4, letting in new
> features for Python 3.5 which should be open for development in mid 2013.
That's a looong time (for me at least), but still an acceptable timeframe.
> 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.)
>
>
> The moratorium should also give us time and space to focus on bug fixes
> for the language which is good.
Do you really think so, or do you say it because you wish it was true?
The occasional syntax change doesn't block many developer resources.
IMO it's the tedious interminable discussions on library and infrastructure
issues, e.g. distribution/packaging or the future of WSGI, and none of these
is going to be cut off or settled.
+1 for predictable release schedules.
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.
_______________________________________________
Christian Heimes
> As a Python language user, I must say that I cannot remember any recent(?)
> language syntax proposal on python-ideas that would have made the language
> substantially better. Plus, a lot of the code that gets written even today
> is still required to stay Py2.x compatible, sometimes as old as 2.3.
> Especially library or tooling code will often not even use Python 2.6
> features for a while, let alone Python 3.x features. That doesn't mean you
> can't 2to3 it, it just means that it won't use the new syntax features.
Dito! The last useful (and today widely used) syntax change in the 2.x
series was the 'with' statement. I don't see urgent need for any syntax
or language chances in the next couple of year. The only new feature I
can think of, that might require new syntax, is parallel processing and
executing multithreaded, GIL-less code. Such a feature is going to take
a long time before it's implemented.
I'm +1 on your proposal, Guido. Do you propose a fixed time span for the
moratorium or a status quo? Can we continue changing the language once
Jython and IronPython have fully implemented Python 2.7 / 3.2?
Christian
Eric Smith
> Distutils != core language syntax.
This, I know :)
> Distutils was already mentioned in
> guido's original email, and given it's a standard library module, it
> can continue to evolve.
I was specifically referring to PEP 382, which I'm hoping can be used to
solve some of the heartburn that setuptools causes some people. I
believe we'll need to modify the import machinery for it, since the PEP
itself says "The import statement is extended so that it directly
considers *.pth files during import".
But I'll admit that I've not studied the PEP enough to know to implement
it or how much it helps the situation.
Eric.
Fred Drake
> "The import statement is extended so that it directly considers *.pth files
> during import".
This sounds like the implementation of the import statement, not the
language definition.
-Fred
--
Fred L. Drake, Jr. <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller
Brett Cannon
On Wed, Oct 21, 2009 at 6:18 PM, Eric Smith <er...@trueblade.com> wrote:This sounds like the implementation of the import statement, not the
> "The import statement is extended so that it directly considers *.pth files
> during import".
language definition.
Antoine Pitrou
>
> One thing I would like to see happen for this moratorium is us following
> a more rigid release schedule in terms of feature freeze. So I would propose
> that starting with 3.2 we feature freeze 18 months after 3.2's feature
> freeze.
Time-based releases can be good, but 18 months until the feature freeze (which,
realistically, gives us a new release every 2 years) sounds much too long to me.
Regards
Antoine.
Jesse Noller
> Brett Cannon <brett@...> writes:
>>
>> One thing I would like to see happen for this moratorium is us following
>> a more rigid release schedule in terms of feature freeze. So I would propose
>> that starting with 3.2 we feature freeze 18 months after 3.2's feature
>> freeze.
>
> Time-based releases can be good, but 18 months until the feature freeze (which,
> realistically, gives us a new release every 2 years) sounds much too long to me.
>
> Regards
>
> Antoine.
+1 18 months seems too long.
Xavier Ho
Time-based releases can be good, but 18 months until the feature freeze (which,
realistically, gives us a new release every 2 years) sounds much too long to me.
Agreed. We'll need to first list out the goals of what we can accomplish within the frozen syntax timeframe, and then look at how long it will take to reach those goals. Only then can we decide how long it would be ideal.
Also, even if when this is in effect (+1 fro me by the way), we also need to agree on some kind of exceptions so we're not shooting down at our own feet.
Steven D'Aprano
> On Wed, Oct 21, 2009 at 11:52 AM, geremy condra <deba...@gmail.com>
wrote:
> > Towards that end, I'd also like to propose a very public, very
> > accessible 'sandbox' specifically for the development and testing
> > of new language features while the moratorium is in effect.
>
> I can't stop people from forking the language to do experiments, but
> one of the goals I have for the moratorium is actually to *reduce*
> the interest in core language changes, and to *raise* the barrier to
> entry. Most language change proposals are just fluff, and they will
> be just as unneeded three years from now as they are today. Once the
> moratorium is lifted, users should be able expect the normal, slow,
> conservative evolution of the language to continue -- not to see the
> floodgates lifted for a barrage of new features.
I was going to make a similar suggestion to Geremy, an official
experimental branch in perpetual alpha, specifically to allow people to
experiment with language changes. This doesn't mean that when the
moratorium is lifted there will be a sudden flood of new features,
radically changing the language: features will still need to go through
precisely the same procedure to be accepted into the language as they
do now. But it will be a place to point people and tell them "don't
just tell us how you imagine this feature will work, show us".
(For the record, I'm not suggesting that this experimental branch should
be open to commits from anyone. You still have to convince those with
privileges that your patch is worth looking at.)
As far as the moratorium goes, I'm going to be the negative-nellie who
says that I don't think this will actually make much practical
difference. Python is, and always has been, very conservative about
adding new language features. And so far, we've only heard from one
developer of another Python implementation, Dino Viehland of
IronPython, who said that language features are generally not a problem
for him.
As far as I can see, the only practical difference it will make is that
it will cut short some (but not all) threads on python-ideas and
comp.lang.python: anyone who suggests a language change will be
told "Moratorium. Come back in 2013."
This risks giving newbies the impression that Python is moribund and
closed to new ideas -- not just the amateur language designers who have
a wild and wacky ideas, but also those with clue who have good,
thought-out ideas, as well as the quiet ones who don't have ideas but
like those who do. Programming language popularity is not quite a
zero-sum game, but languages do live or die by the ability to attract
and keep new users. Particularly in Open Source languages, those users
tend to be attracted more by "fresh and lively" than "stable and
boring". So this is a cost that needs to be considered against the
dubious (to me at least) proposition that a feature-freeze in the
language will speed up uptake of 3.1.
If library authors are going to support 3.x, they need to pick a minimum
version and write for that. A new-feature freeze for 3.2 and 3.3 isn't
going to make their life easier if they're writing for 3.1, for the
obvious reason that they need to use only features available in 3.1.
The only language changes that hurt them are non-backward compatible
changes like the removal of features, but even there the benefit is
minimal because Python already is very cautious about backwards
compatibility. Features aren't removed or functionality changed without
a long deprecation period, possibly even longer than the proposed
moratorium. So I'm not convinced that this moratorium will actually
give any advantage.
--
Steven D'Aprano
Jesse Noller
> On Wed, Oct 21, 2009 at 1:28 PM, Antoine Pitrou <soli...@pitrou.net> wrote:
>> Guido van Rossum <guido@...> writes:
>>>
>>> Note, the moratorium would only cover the language itself plus
>>> built-in functions, not the standard library.
>>
>> Out of curiousity, would it preclude adding e.g. a method to a built-in type?
>> (I'm not saying this with anything specific in mind)
>
> And I can't answer without anything specific in front of me.
>
> I think it's time for someone to draft a PEP for me summarizing some
> of the points of this discussion.
>
> Some specific quick responses before I run off to do real work:
>
> - no, I don't think it should have been announced before 3.1 was frozen
>
> - no, I don't think we need an ISO standard
>
> - no, it's not decided yet
>
> - no, it's not an absolute law (actually typical laws have lots of
> gray areas too)
>
I'll volunteer to write it up; I like writing. I'll send it to
python-dev when it's ready.
jesse
Ron Adam
Guido van Rossum 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.)
++1 Yay!
I really like the idea of keeping the core small, simple, and efficient,
and having most of the real interfacing and data processing *magic* done
through libraries. So yes, please refocus development efforts to improving
the library.
I think if a library could benifit substantually from some core
improvement, then that can be discussed at that time. Such improvement to
the core will be for a real concrete need to enable functionality in an
extension or library, rather than improving the core with expectations of
having some unknown abstract or perceived benefit later.
Ron Adam
Larry Bugbee
> 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.
I agree with a moratorium. I cannot imagine it doing any harm.
I'd even go so far as to say new language syntax and semantics should
only come in only at top level version numbers like 2.0, 3.0, 4.0,
etc. ...not at 3.2, 3.3, 3.4, etc. And at this later date, I submit
language changes should not come in unless there is a compelling reason.
That said, two areas where language support would be welcome:
- the optional declaration of data types
- parallel processing
FWIW, I do a lot of crypto and for now have chosen to remain at
2.5.x. For me, byte strings are all important, and a few quick forays
into Python 3 and its default Unicode suggested I should proceed very
carefully. My experiments with Python 2.6 left me uncomfortable as
well. There I ran into a couple of standard libraries that had the
same API but their implementation/behavior was different. (No, that
was many months ago and I do not remember which. Sorry.) In time I
will move to Py3.
Larry Bugbee
> 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.
I think a moratorium would be Goodness. I cannot imagine it doing any
harm. I'd even go so far as to say new language syntax and semantics
should only come in only at top level version numbers like 2.0, 3.0,
4.0, etc. ...not at 3.2, 3.3, 3.4, etc. And at this later date, I
submit language changes should not come in unless there is a
compelling reason.
Two areas where language support would be welcome:
Stephen J. Turnbull
> On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <pyt...@rcn.com> wrote:
> > 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).
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.
Stephen J. Turnbull
> Guido van Rossum skrev:
> > I propose a moratorium on language changes.
> Isn't this the same as saying it is time to produce an industry standard
> (as in ISO, ECMA, ANSI, IEEE) for the Python language?
No. The language reference is quite precise and accurate AFAICS.
There may be an argument for an industry standard, but this isn't it.
> As I see it, the problem is not "language changes", but one
> implementation (CPython) being the "de facto" Python language
> standard. Maybe there should be a real Python standard?
Would it make a difference? Surely the CPython implementation would
still be the de facto "reference interpretation" for resolving
ambiguities.
Note that many argue that the success of the Internet is due to
deliberate adherence to a PEP-like process that involves actually
implementing and demonstrating usefulness of new features. OTOH, the
ISO and other standards bodies are famous for standards produced by
language lawyers. These standards are sometimes unusable, and too
often ignored in favor of well-known best practices.
In the end, I think it would be hard to convince the developer
community to abandon the PEP process. So any ISO effort would be
layered on top of it, and CPython would still have distinguished
status.
Yuvgoog Greenle
> On Thu, 22 Oct 2009 06:02:29 am Guido van Rossum wrote:
>> On Wed, Oct 21, 2009 at 11:52 AM, geremy condra <deba...@gmail.com>
> wrote:
>> > Towards that end, I'd also like to propose a very public, very
>> > accessible 'sandbox' specifically for the development and testing
>> > of new language features while the moratorium is in effect.
> ...
> experimental branch in perpetual alpha,
+1 for the sandbox idea.
If crazy suggestions that come to python-ideas are plainly rejected
because of the moratorium then I'm -1 on inventing discussion killers.
If the moratorium PEP shows how a new language feature is to be
introduced in an official sandbox etc, then I'm +1 for the moratorium.
--yuv
Daniel Fetchinson
> several years during which no changes to Python's grammar or language
> semantics will be accepted.
+1
I only wish that the leads of many other software projects I use would
be equally wise to declare a moratorium once in a while. It's a sign
of maturity and sadly many developers don't realize this and keep
adding features all the time for the sake of adding features.
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Oleg Broytman
> 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
> language cause pain for implementors of alternate implementations
+1 for the moratorium during the life of 3.2.
+0.5 for 3.3.
-1 for the reason. In my no so humble opinion the moratorium is a
benefit for the language, the implementation (CPython), the developers and
the users (software developers that use CPython). If alternative
implementations see their benefits - well, good for them.
Oleg.
--
Oleg Broytman http://phd.pp.ru/ p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
Stephen J. Turnbull
> official sandbox
That's an oxymoron, IMHO.
Guido van Rossum
<ste...@xemacs.org> wrote:
> Guido van Rossum writes:
> > On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <pyt...@rcn.com> wrote:
>
> > > 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).
>
> 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.
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/)
Guido van Rossum
> I agree with a moratorium. I cannot imagine it doing any harm.
> That said, two areas where language support would be welcome:
This is the typical response I expected. It is however internally
inconsistent. Either you agree with a moratorium or you don't.
Agreeing with a moratorium except for your personal pet peeve equals
no moratorium, since there are too many pet peeves.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Patrick Laban
My only concern would be that the technology field is always changing and some great new technologies may come up during the moratorium. To alleviate this concern I propose that the primary Python core developers either meet once a year, or at the halfway point of the moratorium. They would then discuss whether or not any changes within the field are major enough to warrant a change within Python core.
With these meetings we would be able to ensure that the Python core is only worked on if absolutely necessary, leaving us free to concentrate on library development.
--Patrick Laban
Tim Peters
> 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.
Eh. I'll be a solid +1 on this /if/ you use your time machine to
begin the moratorium right after the "with" statement was introduced.
The rationale you gave applied as much then as it does now -- and if
you do this, then we won't need to discuss it now, since it will
already have been done.
If you won't use your time machine, fine, +0.9. I'm taking off a
tenth so you realize there's a steep cost for refusing it interfere
with history.
Brett Cannon
Please forgive me if anything I say has already been mentioned. I am certainly in support of a moratorium on Python core and switch the focus to Python libraries. I'm sure others have noticed that as of late many proposals have been of lower quality or are the same old ideas that keep getting requested.
My only concern would be that the technology field is always changing and some great new technologies may come up during the moratorium. To alleviate this concern I propose that the primary Python core developers either meet once a year, or at the halfway point of the moratorium. They would then discuss whether or not any changes within the field are major enough to warrant a change within Python core.
Guido van Rossum
That's the moratorium-with-exceptions again, which cannot work because
everyone has their favorite "can't wait" exception.
New technology should be dealt with in a library first anyway.
Anyway, the "Python core" includes a lot of stuff that isn't covered
by the moratorium (which only prohibits changes to syntax and
associated semantics, not implementation issues).
I expect that any issues with the moratorium will be discussed on
python-dev first; but the yearly language summit will be a good point
to review it too.
Guido van Rossum
> [Guido]
>> 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.
>
> Eh. I'll be a solid +1 on this /if/ you use your time machine to
> begin the moratorium right after the "with" statement was introduced.
> The rationale you gave applied as much then as it does now -- and if
> you do this, then we won't need to discuss it now, since it will
> already have been done.
Well, my intention is for it to begin right after 3.1 was released.
While the time machine can do stuff with SVN or Hg branches, it's not
powerful enough to mess with code already released.
Though honestly I don't recall exactly what was added between the with
statement and the 3.1 release apart from 'nonlocal'.
> If you won't use your time machine, fine, +0.9. I'm taking off a
> tenth so you realize there's a steep cost for refusing it interfere
> with history.
Ah, you've moved from fractional winks to fractional votes. A nice upgrade. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Patrick Laban
That's the moratorium-with-exceptions again, which cannot work because
everyone has their favorite "can't wait" exception.
New technology should be dealt with in a library first anyway.
Anyway, the "Python core" includes a lot of stuff that isn't covered
by the moratorium (which only prohibits changes to syntax and
associated semantics, not implementation issues).
I expect that any issues with the moratorium will be discussed on
python-dev first; but the yearly language summit will be a good point
to review it too.
--Patrick Laban
Tarek Ziadé
[..]
> That's the moratorium-with-exceptions again, which cannot work because
> everyone has their favorite "can't wait" exception.
>
> New technology should be dealt with in a library first anyway.
So.. (just a thought) could that possibly mean we could have a
different release cycle for the stdlib ?
(this has been suggested lately)
Or its just a "freeze" of what's not located in /Lib, with the usual
release cycle ?
Regards
Tarek
Larry Bugbee
>
I was very careful to not say when. ;-))
Robert Kern
> On Thu, Oct 22, 2009 at 11:40 AM, Tim Peters<tim.p...@gmail.com> wrote:
>> [Guido]
>>> 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.
>>
>> Eh. I'll be a solid +1 on this /if/ you use your time machine to
>> begin the moratorium right after the "with" statement was introduced.
>> The rationale you gave applied as much then as it does now -- and if
>> you do this, then we won't need to discuss it now, since it will
>> already have been done.
>
> Well, my intention is for it to begin right after 3.1 was released.
> While the time machine can do stuff with SVN or Hg branches, it's not
> powerful enough to mess with code already released.
>
> Though honestly I don't recall exactly what was added between the with
> statement and the 3.1 release apart from 'nonlocal'.
Can you recall, off the top of your head, what language changes would need to be
rolled back between the trunk and 3.1? I'm basically +1 from the peanut gallery,
but I'm not really sure what changes have already been committed to the trunk.
>> If you won't use your time machine, fine, +0.9. I'm taking off a
>> tenth so you realize there's a steep cost for refusing it interfere
>> with history.
>
> Ah, you've moved from fractional winks to fractional votes. A nice upgrade. :-)
It's one of the things I miss about the good old days of c.l.py, actually. :-(
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
geremy condra
<ste...@xemacs.org> wrote:
> Yuvgoog Greenle writes:
>
> > official sandbox
>
> That's an oxymoron, IMHO.
We can call it "the officially sanctioned area for the discussion and
development of
unsanctioned extensions to Python", then. Or TOSAFTDADOUETP, for short.
I kind of like that last one.
Geremy Condra
Brett Cannon
On Thu, Oct 22, 2009 at 9:08 PM, Guido van Rossum <gu...@python.org> wrote:
[..]
> That's the moratorium-with-exceptions again, which cannot work becauseSo.. (just a thought) could that possibly mean we could have a
> everyone has their favorite "can't wait" exception.
>
> New technology should be dealt with in a library first anyway.
different release cycle for the stdlib ?
(this has been suggested lately)
Guido van Rossum
> Can you recall, off the top of your head, what language changes would need
> to be rolled back between the trunk and 3.1? I'm basically +1 from the
> peanut gallery, but I'm not really sure what changes have already been
> committed to the trunk.
Not off the top of my head, but a diff between the Grammar file tagged
with r31 and the py3k branch's head suggests that the only grammatical
change was a refactoring of star-expressions which just fixed an
ambiguity.
The change of the 'with' statement to allow multiple handlers made it
into 3.1 so it's safe.
I haven't researched recent changes to the builtins, but
svn.python.org is your friend.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Nick Coghlan
> Sturla Molden <sturla@...> writes:
>> Isn't this the same as saying it is time to produce an industry standard
>> (as in ISO, ECMA, ANSI, IEEE) for the Python language?
>
> But we have not, and fixing bugs and making improvements is a much better use of
> volunteer time than language lawyering, IMO.
>
>> Except for Java, only standardized
>> languages tend to be considered for large projects.
>
> The "except for Java" statement makes me think that standardization isn't a real
> criterion here. Stability may be, however.
I know of a number of large projects that are quite happy to make
extensive use of Python. They tend to standardise on older versions
(more precisely, versions that were current when the project started),
but they use it.
Cheers,
Nick.
--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
Ben Finney
writes:
> Yuvgoog Greenle writes:
>
> > official sandbox
>
> That's an oxymoron, IMHO.
Perhaps you're interpreting it as “sandbox of official things”? That
would appear to be an oxymoron.
My interpretation of it was more like “place with official status as a
sandbox”, which isn't an oxymoron IMO.
--
\ “I still have my Christmas Tree. I looked at it today. Sure |
`\ enough, I couldn't see any forests.” —Steven Wright |
_o__) |
Ben Finney
Tim Peters
>>> 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.
[Tim]
>> Eh. I'll be a solid +1 on this /if/ you use your time machine to
>> begin the moratorium right after the "with" statement was introduced.
>> The rationale you gave applied as much then as it does now -- and if
>> you do this, then we won't need to discuss it now, since it will
>> already have been done.
[Guido]
> Well, my intention is for it to begin right after 3.1 was released.
Well, I believe that /was/ your intention.
> While the time machine can do stuff with SVN or Hg branches, it's not
> powerful enough to mess with code already released.
LOL -- say that often enough, and the newbies might even believe it <0.6 wink>.
> Though honestly I don't recall exactly what was added between the with
> statement and the 3.1 release apart from 'nonlocal'.
Excellent! My plan worked, then. I looked, and, e.g., both the
switch statement and anonymous inline meta-decorators no longer exist
in current Pythons. I can live with nonlocal -- its continued
existence was probably just due to a local leak in the time machine's
rear Tesla coils. They've always been a bit flaky.
>> If you won't use your time machine, fine, +0.
> Ah, you've moved from fractional winks to fractional votes. A nice upgrade. :-)
I have no idea what you're talking about.
the-more-things-change-the-more-i-don't-ly y'rs - tim
Gregory P. Smith
>> 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.
>
> Eh. I'll be a solid +1 on this /if/ you use your time machine to
> begin the moratorium right after the "with" statement was introduced.
> The rationale you gave applied as much then as it does now -- and if
> you do this, then we won't need to discuss it now, since it will
> already have been done.
>
> If you won't use your time machine, fine, +0.9. I'm taking off a
> tenth so you realize there's a steep cost for refusing it interfere
> with history.
+1.1 from me. Someone's gotta pick up Tim's 0.1 slack. ;)
Jared Grubb
> As far as I can see, the only practical difference it will make is
> that
> it will cut short some (but not all) threads on python-ideas and
> comp.lang.python: anyone who suggests a language change will be
> told "Moratorium. Come back in 2013."
It would be a shame to discourage new ideas just because we are not
willing to implement them "now".
I hope that any moratorium would not cut discussions of new ideas
short, would not change the tone of python-ideas, and would not
discourage writing PEP's for new language features (with the
understanding that it will be a while before they actually get
implemented).
Jared
Guido van Rossum
> It would be a shame to discourage new ideas just because we are not willing
> to implement them "now".
>
> I hope that any moratorium would not cut discussions of new ideas short,
> would not change the tone of python-ideas, and would not discourage writing
> PEP's for new language features (with the understanding that it will be a
> while before they actually get implemented).
Actually one of my goals with the moratorium is to discourage
discussion of certain ideas that keep coming up forever and draining
the energy of the list. Also, I certainly don't hope that when the
moratorium is lifted there are 20 language PEPs waiting for approval.
Python's evolution needs to slow down as the user community grows.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
geremy condra
> On Thu, Oct 22, 2009 at 5:15 PM, Jared Grubb <jared...@gmail.com> wrote:
>> It would be a shame to discourage new ideas just because we are not willing
>> to implement them "now".
>>
>> I hope that any moratorium would not cut discussions of new ideas short,
>> would not change the tone of python-ideas, and would not discourage writing
>> PEP's for new language features (with the understanding that it will be a
>> while before they actually get implemented).
>
> Actually one of my goals with the moratorium is to discourage
> discussion of certain ideas that keep coming up forever and draining
> the energy of the list.
Personally, I think mandating that you bring working code to the table
when proposing a language change would take the number of requests
for, say, removing the GIL to pretty much nil.
> Also, I certainly don't hope that when the
> moratorium is lifted there are 20 language PEPs waiting for approval.
> Python's evolution needs to slow down as the user community grows.
Again, I doubt that very many of the people proposing some of these
changes have either the technical skills to pull them off or the
patience to maintain them for a year and a half while waiting for the
moratorium to lift. My guess is that you'll have about 300 half-baked
or just-started projects and only one or two good ones ready for PEP
consideration. Over the period of time you're talking about, that
doesn't seem -IMO- to be too much, too fast. Your mileage may
certainly vary.
Geremy Condra
Guido van Rossum
> On Thu, Oct 22, 2009 at 8:31 PM, Guido van Rossum <gu...@python.org> wrote:
>> On Thu, Oct 22, 2009 at 5:15 PM, Jared Grubb <jared...@gmail.com> wrote:
>>> It would be a shame to discourage new ideas just because we are not willing
>>> to implement them "now".
>>>
>>> I hope that any moratorium would not cut discussions of new ideas short,
>>> would not change the tone of python-ideas, and would not discourage writing
>>> PEP's for new language features (with the understanding that it will be a
>>> while before they actually get implemented).
>>
>> Actually one of my goals with the moratorium is to discourage
>> discussion of certain ideas that keep coming up forever and draining
>> the energy of the list.
>
> Personally, I think mandating that you bring working code to the table
> when proposing a language change would take the number of requests
> for, say, removing the GIL to pretty much nil.
Actually removing the GIL is not subject to the moratorium, and it
seems that some people *are* working on code.
>> Also, I certainly don't hope that when the
>> moratorium is lifted there are 20 language PEPs waiting for approval.
>> Python's evolution needs to slow down as the user community grows.
>
> Again, I doubt that very many of the people proposing some of these
> changes have either the technical skills to pull them off or the
> patience to maintain them for a year and a half while waiting for the
> moratorium to lift. My guess is that you'll have about 300 half-baked
> or just-started projects and only one or two good ones ready for PEP
> consideration. Over the period of time you're talking about, that
> doesn't seem -IMO- to be too much, too fast. Your mileage may
> certainly vary.
I hope to discourage those 300 people to the point where there won't
be any half-baked or unbaked projects. Let them contribute to Perl 6.
:-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Jim Jewett
> Anyway, the "Python core" includes a lot of stuff that isn't covered
> by the moratorium (which only prohibits changes to syntax and
> associated semantics, not implementation issues).
Changes to semantics are rare enough that I'm not sure a moratorium
(but allowing bug fixes) would matter. (Particularly if you stick to
the claim that details of import resolution are
implementation-specific.)
I have no opinion on changes to syntax; they're already uncommon, but
saying they'll wait until 2013 doesn't bother me.
The limit on builtins may be more of a problem. For example, I liked
Brett's work on signatures. If he gets motivated to work on it again,
I don't want him to say "Drat; I really need access to this one extra
function attribute, which isn't currently exposed at the python level.
I guess I'll have to wait a few years."
It would be reasonable to say that changes to builtins will be rare,
and will typically be strictly additions to functionality, as though
they were replaced by a subclass which overrode nothing except that
certain Exceptions were now handled internally. (In other words, *if*
the name previously existed, it either keeps the same meaning, or gets
wrapped in something that just calls the old meaning as a try suite,
with all new functionality inside the except suite.)
-jJ
Brett Cannon
On Thu, Oct 22, 2009 at 3:08 PM, Guido van Rossum <gu...@python.org> wrote:Changes to semantics are rare enough that I'm not sure a moratorium
> Anyway, the "Python core" includes a lot of stuff that isn't covered
> by the moratorium (which only prohibits changes to syntax and
> associated semantics, not implementation issues).
(but allowing bug fixes) would matter. (Particularly if you stick to
the claim that details of import resolution are
implementation-specific.)
I have no opinion on changes to syntax; they're already uncommon, but
saying they'll wait until 2013 doesn't bother me.
The limit on builtins may be more of a problem. For example, I liked
Brett's work on signatures. If he gets motivated to work on it again,
I don't want him to say "Drat; I really need access to this one extra
function attribute, which isn't currently exposed at the python level.
I guess I'll have to wait a few years."
It would be reasonable to say that changes to builtins will be rare,
and will typically be strictly additions to functionality, as though
they were replaced by a subclass which overrode nothing except that
certain Exceptions were now handled internally. (In other words, *if*
the name previously existed, it either keeps the same meaning, or gets
wrapped in something that just calls the old meaning as a try suite,
with all new functionality inside the except suite.)
geremy condra
> On Thu, Oct 22, 2009 at 5:57 PM, geremy condra <deba...@gmail.com> wrote:
>> On Thu, Oct 22, 2009 at 8:31 PM, Guido van Rossum <gu...@python.org> wrote:
>>> On Thu, Oct 22, 2009 at 5:15 PM, Jared Grubb <jared...@gmail.com> wrote:
>>>> It would be a shame to discourage new ideas just because we are not willing
>>>> to implement them "now".
>>>>
>>>> I hope that any moratorium would not cut discussions of new ideas short,
>>>> would not change the tone of python-ideas, and would not discourage writing
>>>> PEP's for new language features (with the understanding that it will be a
>>>> while before they actually get implemented).
>>>
>>> Actually one of my goals with the moratorium is to discourage
>>> discussion of certain ideas that keep coming up forever and draining
>>> the energy of the list.
>>
>> Personally, I think mandating that you bring working code to the table
>> when proposing a language change would take the number of requests
>> for, say, removing the GIL to pretty much nil.
>
> Actually removing the GIL is not subject to the moratorium, and it
> seems that some people *are* working on code.
>
Alright then, adding default arguments that evaluate when the
function is called.
>>> Also, I certainly don't hope that when the
>>> moratorium is lifted there are 20 language PEPs waiting for approval.
>>> Python's evolution needs to slow down as the user community grows.
>>
>> Again, I doubt that very many of the people proposing some of these
>> changes have either the technical skills to pull them off or the
>> patience to maintain them for a year and a half while waiting for the
>> moratorium to lift. My guess is that you'll have about 300 half-baked
>> or just-started projects and only one or two good ones ready for PEP
>> consideration. Over the period of time you're talking about, that
>> doesn't seem -IMO- to be too much, too fast. Your mileage may
>> certainly vary.
>
> I hope to discourage those 300 people to the point where there won't
> be any half-baked or unbaked projects. Let them contribute to Perl 6.
> :-)
The trick is figuring out in advance which is the 300 and which is the
1 or 2. My suggestion is that we allow them to effectively self-select;
that we allow those who are skilled enough and patient enough- and
who happen to have ideas of unusual merit- to prove that to the
Python community. If the results are great, great! Two years down the
line Python has a great new feature. If not, oh well- it's not like you
are under any obligation to merge it. And there's probably merit in
keeping the really wretched ones around too, if only to say "no way,
tried it, had to kill it with fire". Either way, Python wins.
Geremy Condra
Guido van Rossum
> The trick is figuring out in advance which is the 300 and which is the
> 1 or 2. My suggestion is that we allow them to effectively self-select;
> that we allow those who are skilled enough and patient enough- and
> who happen to have ideas of unusual merit- to prove that to the
> Python community. If the results are great, great! Two years down the
> line Python has a great new feature. If not, oh well- it's not like you
> are under any obligation to merge it. And there's probably merit in
> keeping the really wretched ones around too, if only to say "no way,
> tried it, had to kill it with fire". Either way, Python wins.
I hope so.
But no feature is an island. They must work together. Two or three
features that are each individually well thought-out and implemented
in separate branches might still be a disaster when combined.
Also, ten new features, even if they all fit together, may just be too
much new stuff for the user community to digest at once.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
geremy condra
> On Thu, Oct 22, 2009 at 8:04 PM, geremy condra <deba...@gmail.com> wrote:
>> The trick is figuring out in advance which is the 300 and which is the
>> 1 or 2. My suggestion is that we allow them to effectively self-select;
>> that we allow those who are skilled enough and patient enough- and
>> who happen to have ideas of unusual merit- to prove that to the
>> Python community. If the results are great, great! Two years down the
>> line Python has a great new feature. If not, oh well- it's not like you
>> are under any obligation to merge it. And there's probably merit in
>> keeping the really wretched ones around too, if only to say "no way,
>> tried it, had to kill it with fire". Either way, Python wins.
>
> I hope so.
>
> But no feature is an island. They must work together. Two or three
> features that are each individually well thought-out and implemented
> in separate branches might still be a disaster when combined.
>
> Also, ten new features, even if they all fit together, may just be too
> much new stuff for the user community to digest at once.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
Exactly- with a sandbox in place, the community could look at
real code and evaluate features not just as abstract ideas, but
as real working implementations- a first chance to see how
well they might work in practice, how much code they break,
and how well those changes work together, or, as you point
out, don't.
Geremy Condra
Guido van Rossum
> Exactly- with a sandbox in place, the community could look at
> real code and evaluate features not just as abstract ideas, but
> as real working implementations- a first chance to see how
> well they might work in practice, how much code they break,
> and how well those changes work together, or, as you point
> out, don't.
You keep stressing the opportunities for new features, but I want to
crush that hope -- new features should be rare, and should become
rarer as the user community grows. The time to experiment was
approximately 10 years ago. Go invent a new language (and hope for it
to become popular :-) if you want to experiment.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
geremy condra
> On Thu, Oct 22, 2009 at 8:45 PM, geremy condra <deba...@gmail.com> wrote:
>> Exactly- with a sandbox in place, the community could look at
>> real code and evaluate features not just as abstract ideas, but
>> as real working implementations- a first chance to see how
>> well they might work in practice, how much code they break,
>> and how well those changes work together, or, as you point
>> out, don't.
>
> You keep stressing the opportunities for new features, but I want to
> crush that hope -- new features should be rare, and should become
> rarer as the user community grows. The time to experiment was
> approximately 10 years ago. Go invent a new language (and hope for it
> to become popular :-) if you want to experiment.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
I don't know how many more language changes we'll see in
Python- I don't think anybody does- but if the intent is that
the moratorium lift at some point, then I would suggest that
we should start preparing for that time now.
Geremy Condra
geremy condra
> On Thu, Oct 22, 2009 at 8:45 PM, geremy condra <deba...@gmail.com> wrote:
>> Exactly- with a sandbox in place, the community could look at
>> real code and evaluate features not just as abstract ideas, but
>> as real working implementations- a first chance to see how
>> well they might work in practice, how much code they break,
>> and how well those changes work together, or, as you point
>> out, don't.
>
> You keep stressing the opportunities for new features, but I want to
> crush that hope -- new features should be rare, and should become
> rarer as the user community grows. The time to experiment was
> approximately 10 years ago. Go invent a new language (and hope for it
> to become popular :-) if you want to experiment.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
Let me add an addendum to my previous comment, because
as I reread this it just strikes me as sounding so ominous.
Is it really your intent that Python's development slow to the
same crawl as Fortran or C? Put another way, is it your intent
to eventually raise the moratorium?
Geremy Condra
geremy condra
>
>
> On Wed, Oct 21, 2009 at 09:42, Guido van Rossum <gu...@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
>> 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).
>>
>
> +1 from me. In this rather long thread someone proposed allowing changes
> that make implementation of the language easier, which I am also fine with,
> but that could almost be classified a bug fix and taken on a case-by-case
> basis. But completely new exposed syntax or semantics for the language and
> built-ins should be off limits.
> And for the "several years", I say make through 3.4, letting in new features
> for Python 3.5 which should be open for development in mid 2013.
>
>>
>> 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.)
>>
>
> The moratorium should also give us time and space to focus on bug fixes for
> the language which is good.
>
>>
>> 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.
>>
>
> Sounds reasonable to me.
>
>>
>> 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.)
>
> Sounds good to me. While I heard some people on Twitter want PEP 380, if we
> are going to freeze it should be across the board. I can see someone arguing
> that at least PEP 380 is in a PEP format, but even then that doesn't mean
> its fully thought out (and I am not explicitly talking about PEP 380 as I
> have not read it in ages).
> A side benefit to this is it will give us time to come up with a PEP that
> clearly defines exactly what is required to propose and get accepted changes
> to the language (I also want to do this for the standard library, but I view
> that as a different PEP). Hopefully that will cut down on the wild proposal
> on python-ideas and give people a much clearer idea of what is required of
> them. As I view this as a developer doc thing I am willing to write these
> PEPs (eventually =).
I second this- especially if it includes a code-first requirement.
> One thing I would like to see happen for this moratorium is us following a
> more rigid release schedule in terms of feature freeze. So I would propose
> that starting with 3.2 we feature freeze 18 months after 3.2's feature
> freeze. Now I am not suggesting we lock down the final release date to 18
> months as who knows how long it would take to shake out the bugs, but we can
> easily say that every 18 months we feature freeze for the next minor release
> (major releases don't apply to this schedule and I am not worrying about
> micro releases as that is not under discussion here).
Ditto.
> This would give us and the community a much clearer indication of when the
> moratorium will be lifted. So we could say that 3.2 is feature frozen on
> June 15, 2010, Python 3.3 on January 15, 2012, and Python 3.4 on June 15,
> 2013. We can obviously choose some other set of dates (went with this to
> avoid releasing on New Years, although it might be fun to shift to Oct 5 as
> that's the date Flying Circus was first broadcast), but it would be nice to
> be able to say that "after Python 3.4, which is feature frozen on XXX, we
> will start looking at new features again for Python 3.5".
> -Brett
Sounds good to me.
Yuvgoog Greenle
> You keep stressing the opportunities for new features, but I want to
> crush that hope
> Go invent a new language (and hope for it
> to become popular :-) if you want to experiment.
Crushing hope and pointing people to the door is ugly [*].
Why freeze? Instead, define how change occurs and make it as slow as
you like. Define the python kilo (1000x) development cycle. For
example the "moratorium" could state:
---
S&B = syntax and builtins
Python only introduces syntax and builtins once every X years[**] and
only in major version changes. Between pyNk releases S&B are locked.
New S&B can and should be tested on the next major revision's
experimental branch(es). New S&B will only be considered for inclusion
during the 2 years prior a pyNk major version.
If a core language feature is to be accepted it needs:
1. A community tested and reviewed patch
2. A migration strategy (ie 3to4 code).
3. Python-dev acceptance (which can only be applied for during the 2
year S&B period).
---
I suggest a new mailing list titled "python-experimental" for
discussion and development of experimental branches. Also, commit
privileges should be really common and easy to get for this branch of
branches. Mercurial could help in implementing this. I realize that
anyone can take the python source and do whatever they want on any
free source host but having an official lab[***] for this can give
another step between code that's in the wild and code that's in an
official (non-experimental) branch and thus save core developer's
time.
--yuv
[*] Beautiful is better than ugly.
[**] There were about 8 years between python 2 and python 3,
extrapolating from the discussion that this was too fast, lets say
X=10, sound reasonable?
[***] I prefer to call it a "playground" but now that python's all
serious business and not a language for fun I don't know how well that
would go.
ps (short for pike shedding) - the "moratorium" has an evil sound to
it. All python needs is a Core-Feature-Development-Cycle-Roadmap or
something catchier.
Bruce Frederiksen
On Fri, Oct 23, 2009 at 5:50 AM, Guido van Rossum <gu...@python.org> wrote:> [ snip ]
> You keep stressing the opportunities for new features, but I want to
> crush that hope
> Go invent a new language (and hope for itCrushing hope and pointing people to the door is ugly [*].
> to become popular :-) if you want to experiment.
Why freeze? Instead, define how change occurs and make it as slow as
you like.
"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
What I see happening is a realization as we move into 2010 that the C language is no longer the future. We may not know yet what language is the future. And we might imagine that it ought to be Python. This discussion is being done within the CPython group. That has two parts: C and Python. I see the moratorium as a declaration that Python needs a new implementation. It needs a new horse to ride on.
What the moratorium is saying is that the Python language will no longer evolve on the CPython implementation. The moratorium will never be lifted for CPython. When a new implementation comes along, that new implementation will necessitate it's own language changes and have it's own future. The moratorium will be lifted when this new implementation (whatever that ends up being) is chosen. And then the Python language will be riding a new horse, with a new reference implementation.
The real questions (if this is even in the right ballpark), are along the lines of:
- How will this new implementation be chosen? What qualities are we looking for? Are we opening up a contest? Are there deadlines?
- Will there only be one winner, or might there be multiple winners (perhaps one for each platform)?
- How will the group of developers now working on CPython transition to this new implementation? This is especially ticklish when we realize that it will be some other group that initially develops the new implementation to the point of being accepted. Does the current CPython group simply ride off into the sunset at that point? Is Guido really the BDFL (Benevolent Dictator For the Language), or only the BDFC (Benevolent Dictator For CPython)? (I, for one, would very much like to see the current group continue to hold the reins on the language. They have an outstanding track record in language design!)
- What are the legal issues? Are there restrictions on which license the new implementation can use? How is it adopted by the PSF? What limits does that place on the other group that developed this thing? What do they have to agree to?
Oleg Broytman
> The moratorium will never be lifted
> for CPython.
Why do you think so?
Oleg.
--
Oleg Broytman http://phd.pp.ru/ p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
Guido van Rossum
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Jesse Noller
> Let's wait for the PEP before derailing this discussion any more.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
I'm crossing my fingers to crank on it this weekend. Sorry for the delay
jesse
Nick Coghlan
> OK, I'm an outsider here. But looking at this whole discussion a
> picture emerges. So I'll toss this out here for discussion (and I'm
> really going out on a limb here, but it's OK to shoot the outsider!)
>
> "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..."
>
> What I see happening is a realization as we move into 2010 that the C
> language is no longer the future. We may not know yet what language is
> the future. And we might imagine that it ought to be Python. This
> discussion is being done within the CPython group. That has two parts:
> C and Python. I see the moratorium as a declaration that Python needs a
> new implementation. It needs a new horse to ride on.
I don't believe this is an accurate characterisation of the situation
(neither in regards to the state of C, nor in regards to the state of
Python).
C isn't going anywhere - it is still massively important as a portable
language that can be made to run pretty much anywhere with minimal
application overhead relative to raw assembler (and often faster than
hand-coded assembler, since humans aren't smart enough to manually
optimise code for many modern processors). Developers of new platforms
don't need to tediously hand code lots of tools - they just need to
teach a C compiler to generate code for their platform and the
bootstrapping process gets off to a flying start.
However, C retains that relevance without the core language changing
very much - the last major update was C99, and the update before that
was C89, which was itself a consolidation of assorted features
introduced by various alternative implementations since K&R C was
documented in 1978. Some would even say that it is the very simplicity
and stability of C that has lead to its ubiquity.
So that's 2 language updates in more than 30 years since a C language
spec was first articulated. Python has had more major updates than that
in barely half the time. Now, for a long time, that didn't really matter
because only the reference interpreter saw serious use. Stackless was
around, but able to pick up most changes directly from the reference
implementation (since it only modified the VM and was able to retain
most of the rest of the core C code), while Jython fell by the wayside
for a while when new style objects were introduced in Python 2.2.
The situation now is significantly different. There are at least 3 major
Python implementations under active development and in production use
that I know of (CPython, Jython, IronPython), other major
implementations that, if not in production use yet, will be eventually
(e.g. PyPy, Unladen Swallow) and various other tools based around
existing Python syntax (Pyrex, Cython).
Changes to the core language spec now affect a *lot* more than just
CPython - there are ripple effects that spread out through the whole
language ecosystem. On the other hand, standard library changes to
modules that other Python implementations are able to use without
modification don't generally have anywhere near the same impact.
Guido's proposed moratorium is a formal recognition of the fact that
tinkering with the underlying language isn't what Python really needs
right now. It *is* possible for a language to become "feature complete"
from a practical point of view, after which tinkering at the edges and
introducing special syntax for niche use cases becomes a distraction
from more productive endeavours.
We changed a lot of things in Py3k - by saying "no, we aren't going to
change anything else in the core language spec for at least the next few
years" we would be consciously taking a step back and waiting to see how
all those changes play out in the real world before we start trying to
build on them.
We would be giving the alternative implementations a chance to come up
to speed with their own Python 3.x implementations, giving major
applications and frameworks a chance to do forward ports without
difficult decisions as to which version to target and giving users a
chance to get used to a new feature set before throwing yet more deltas
at them (e.g. I don't think anyone has even begun to scratch the surface
of the power and flexibility provided by PEP 3115).
Are language changes going to be completely impossible under such a
moratorium? Of course they aren't - if a solid enough case is made for a
change, then we aren't going to dig our heels in just because we made a
formal statement that we didn't want to change certain things for the
next few years. If somebody comes up with a language improvement that is
as groundbreaking as the with statement was for Python, or as
asynchronous blocks would be for C, then of course we would still give
it serious consideration.
However, even a cursory glance at Python ideas shows that most current
suggestions for tweaks to the core language don't really measure up to
that standard. Even PEP 380 (generator delegation), which is a decent,
well thought out suggestion, has to rely fairly heavily on language
consistency and coherency arguments because the real world use cases
that can't already be handled a different way are fairly minimal.
Thanks for posting what you did though - while I believe your perception
of the situation is incorrect, it helped crystalise in my mind *why* I
think Guido's suggestion is a good idea. Previously I hadn't posted
anything, as I wasn't sure whether or not I agreed with the concept.
Regards,
Nick.
--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
geremy condra
> Bruce Frederiksen wrote:
>> OK, I'm an outsider here. But looking at this whole discussion a
>> picture emerges. So I'll toss this out here for discussion (and I'm
>> really going out on a limb here, but it's OK to shoot the outsider!)
>>
>> "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..."
>>
>> What I see happening is a realization as we move into 2010 that the C
>> language is no longer the future. We may not know yet what language is
>> the future. And we might imagine that it ought to be Python. This
>> discussion is being done within the CPython group. That has two parts:
>> C and Python. I see the moratorium as a declaration that Python needs a
>> new implementation. It needs a new horse to ride on.
>
> I don't believe this is an accurate characterisation of the situation
> (neither in regards to the state of C, nor in regards to the state of
> Python).
>
Agreed.
> C isn't going anywhere - it is still massively important as a portable
> language that can be made to run pretty much anywhere with minimal
> application overhead relative to raw assembler (and often faster than
> hand-coded assembler, since humans aren't smart enough to manually
> optimise code for many modern processors). Developers of new platforms
> don't need to tediously hand code lots of tools - they just need to
> teach a C compiler to generate code for their platform and the
> bootstrapping process gets off to a flying start.
>
> However, C retains that relevance without the core language changing
> very much - the last major update was C99, and the update before that
> was C89, which was itself a consolidation of assorted features
> introduced by various alternative implementations since K&R C was
> documented in 1978. Some would even say that it is the very simplicity
> and stability of C that has lead to its ubiquity.
>
Importantly, while Python is not Java, Python is also not C.
The analogy between Python's life cycle and that of a language
that was designed entirely in-house and before the words
"internet" or "open source" were coined is at best flawed and
at worst dangerously misleading. I would point instead to the
development of a language like PHP as the more accurate
metaphor- and despite its syntax and core language changes,
it remains more popular than Python.
> So that's 2 language updates in more than 30 years since a C language
> spec was first articulated. Python has had more major updates than that
> in barely half the time. Now, for a long time, that didn't really matter
> because only the reference interpreter saw serious use. Stackless was
> around, but able to pick up most changes directly from the reference
> implementation (since it only modified the VM and was able to retain
> most of the rest of the core C code), while Jython fell by the wayside
> for a while when new style objects were introduced in Python 2.2.
>
> The situation now is significantly different. There are at least 3 major
> Python implementations under active development and in production use
> that I know of (CPython, Jython, IronPython), other major
> implementations that, if not in production use yet, will be eventually
> (e.g. PyPy, Unladen Swallow) and various other tools based around
> existing Python syntax (Pyrex, Cython).
>
> Changes to the core language spec now affect a *lot* more than just
> CPython - there are ripple effects that spread out through the whole
> language ecosystem. On the other hand, standard library changes to
> modules that other Python implementations are able to use without
> modification don't generally have anywhere near the same impact.
>
Granted, and this is why I support the moratorium. However,
I also support eventually *lifting* the moratorium- Python
competes more against today's highly dynamic languages
than yesterday's quite static languages. Stand too still for
too long and we risk standing nowhere at all.
> Guido's proposed moratorium is a formal recognition of the fact that
> tinkering with the underlying language isn't what Python really needs
> right now. It *is* possible for a language to become "feature complete"
> from a practical point of view, after which tinkering at the edges and
> introducing special syntax for niche use cases becomes a distraction
> from more productive endeavours.
>
And I agree that it isn't what Python needs *right now*. But that
is totally different from saying that there simply aren't any good
ideas left. We should give those ideas an opportunity to be
heard so that in a few years when everybody is caught up we
stand in a position to make good, well-informed decisions
about what the language needs.
> We changed a lot of things in Py3k - by saying "no, we aren't going to
> change anything else in the core language spec for at least the next few
> years" we would be consciously taking a step back and waiting to see how
> all those changes play out in the real world before we start trying to
> build on them.
>
Agreed.
> We would be giving the alternative implementations a chance to come up
> to speed with their own Python 3.x implementations, giving major
> applications and frameworks a chance to do forward ports without
> difficult decisions as to which version to target and giving users a
> chance to get used to a new feature set before throwing yet more deltas
> at them (e.g. I don't think anyone has even begun to scratch the surface
> of the power and flexibility provided by PEP 3115).
>
Agreed.
> Are language changes going to be completely impossible under such a
> moratorium? Of course they aren't - if a solid enough case is made for a
> change, then we aren't going to dig our heels in just because we made a
> formal statement that we didn't want to change certain things for the
> next few years. If somebody comes up with a language improvement that is
> as groundbreaking as the with statement was for Python, or as
> asynchronous blocks would be for C, then of course we would still give
> it serious consideration.
>
Actually, that's almost exactly the opposite of what Guido said- that there
will be no one-change exceptions.
> However, even a cursory glance at Python ideas shows that most current
> suggestions for tweaks to the core language don't really measure up to
> that standard. Even PEP 380 (generator delegation), which is a decent,
> well thought out suggestion, has to rely fairly heavily on language
> consistency and coherency arguments because the real world use cases
> that can't already be handled a different way are fairly minimal.
>
Arguments against past proposals are not arguments against
future proposals. Unless Guido's time machine got an extra
supercollider while I wasn't looking, nobody on this board knows
what's coming down the pipe next, and my argument is that if
the suggestion is super-awesome, popularly supported, and
maintained until the end of the moratorium, then it should have
a really good chance of getting in. To paraphrase a discussion
I had on this topic last night, the fact that there's a long, hard
road to getting a feature into the language isn't a problem. The
idea that there shouldn't be a road is.
Geremy Condra
Guido van Rossum
> Arguments against past proposals are not arguments against
> future proposals. Unless Guido's time machine got an extra
> supercollider while I wasn't looking, nobody on this board knows
> what's coming down the pipe next, and my argument is that if
> the suggestion is super-awesome, popularly supported, and
> maintained until the end of the moratorium, then it should have
> a really good chance of getting in. To paraphrase a discussion
> I had on this topic last night, the fact that there's a long, hard
> road to getting a feature into the language isn't a problem. The
> idea that there shouldn't be a road is.
I need to give my elbow more rest for a couple weeks, so I'm limiting
myself to ultra-short emails.
I take exception to "popularly supported" above. Python is still not a
democracy. You can fill in the rest.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Michael Foord
On Fri, Oct 23, 2009 at 9:18 AM, geremy condra <deba...@gmail.com> wrote:I need to give my elbow more rest for a couple weeks, so I'm limiting
> Arguments against past proposals are not arguments against
> future proposals. Unless Guido's time machine got an extra
> supercollider while I wasn't looking, nobody on this board knows
> what's coming down the pipe next, and my argument is that if
> the suggestion is super-awesome, popularly supported, and
> maintained until the end of the moratorium, then it should have
> a really good chance of getting in. To paraphrase a discussion
> I had on this topic last night, the fact that there's a long, hard
> road to getting a feature into the language isn't a problem. The
> idea that there shouldn't be a road is.
myself to ultra-short emails.
I take exception to "popularly supported" above. Python is still not a
democracy. You can fill in the rest.
Despite the title this was never really a 'proposal' was it. ;-)
All the best,
Michael
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
--
http://www.ironpythoninaction.com/
geremy condra
> On Fri, Oct 23, 2009 at 9:18 AM, geremy condra <deba...@gmail.com> wrote:
>> Arguments against past proposals are not arguments against
>> future proposals. Unless Guido's time machine got an extra
>> supercollider while I wasn't looking, nobody on this board knows
>> what's coming down the pipe next, and my argument is that if
>> the suggestion is super-awesome, popularly supported, and
>> maintained until the end of the moratorium, then it should have
>> a really good chance of getting in. To paraphrase a discussion
>> I had on this topic last night, the fact that there's a long, hard
>> road to getting a feature into the language isn't a problem. The
>> idea that there shouldn't be a road is.
>
> I need to give my elbow more rest for a couple weeks, so I'm limiting
> myself to ultra-short emails.
>
> I take exception to "popularly supported" above. Python is still not a
> democracy. You can fill in the rest.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
Didn't say it was a democracy. Assumed that it would still involve
some input from its user base. Is that wrong?
Geremy Condra
Steven D'Aprano
> However, C retains that relevance without the core language changing
> very much - the last major update was C99, and the update before that
> was C89, which was itself a consolidation of assorted features
> introduced by various alternative implementations since K&R C was
> documented in 1978. Some would even say that it is the very
> simplicity and stability of C that has lead to its ubiquity.
In other words, there were various (I'd say "many") incompatible
implementations of C that introduced their own core changes over the
years, and eventually the C standard caught up with what those
implementations had already done. And the process continues: google
on "non-standard C" for examples. E.g.:
"C has followed the standardization path of most languages. First, the
language was created and used. As its popularity grew, it began to
spawn a number of different dialects. Then, C went through a
standardization process, with the main core of the language being
standardized. It is common for compiler implementations to support
standard C with additional, system-dependent features. This results in
the creation of much non-standard C code."
"C is standardized by both ANSI and ISO. However, there is no reasonable
expectation that a C compiler will follow the standard without
including additional features."
http://archive.adaic.com/docs/reports/lawlis/k.htm
That's hardly the same as saying that C was unchanging or that there was
a moratorium on changes to the language. That's more like the language
continued to evolve, in mutually inconsistent directions, and it was
merely the standard that was out of touch with the practice of C across
various incompatible implementations.
There's plenty of working non-standard C code in the world. I'm not sure
that it's even possible to write non-standard Python code. There are,
naturally, libraries that only exist for one platform or one
implementation, but that's not the same thing.
> Python has had more major updates than
> that in barely half the time. Now, for a long time, that didn't
> really matter because only the reference interpreter saw serious use.
> Stackless was around, but able to pick up most changes directly from
> the reference implementation (since it only modified the VM and was
> able to retain most of the rest of the core C code), while Jython
> fell by the wayside for a while when new style objects were
> introduced in Python 2.2.
"Fell by the wayside"? Are you saying that the popularity of Jython
*declined* because of the introduction of newstyle classes in CPython?
I have an alternative interpretation. Jython 2.2 (equivalent to CPython
2.2, including new-style classes) was finally released in August 2007,
a year after CPython had released 2.5. This was Jython's first
production release in six years:
http://www.jython.org/archive/22/news.html
If so, that suggests to me that Jython developers abandoned Jython
(probably for CPython) because they thought Jython was moribund. They
voted with their feet in favour of an implementation with regular and
useful changes to the core over an implementation which was stable and
unchanging.
[...]
> Changes to the core language spec now affect a *lot* more than just
> CPython - there are ripple effects that spread out through the whole
> language ecosystem. On the other hand, standard library changes to
> modules that other Python implementations are able to use without
> modification don't generally have anywhere near the same impact.
We keep being told this, but so far only one developer of an alternative
implementation has spoken up. According to IronPython's Dino Viehland,
language features are rarely a problem for him, but some library
modules are.
I would really like to hear from some other implementation developers.
I'd also like to hear from the maintainers of large Python projects or
libraries -- why aren't they migrating to 3.1? Is it because they fear
3.2 will include new core features? I can't imagine this is a problem,
because if they're supporting 3.1, they have to use the features in 3.1
and not those in 3.2 -- whether those features are in the core or the
library. Adding features to newer versions can't hurt them, although
obviously changing or removing features will. But Python is already
conservative about changing and removing features, so a moratorium
doesn't change that.
> Guido's proposed moratorium is a formal recognition of the fact that
> tinkering with the underlying language isn't what Python really needs
> right now. It *is* possible for a language to become "feature
> complete" from a practical point of view, after which tinkering at
> the edges and introducing special syntax for niche use cases becomes
> a distraction from more productive endeavours.
Perhaps so, but many of the changes being suggested are better described
as "filing off the rough edges". Not every new feature has to be as big
a change as the introduction of while, or decorators. Small changes
which are easy to implement can make a big difference to usability to.
--
Steven D'Aprano
Stephen J. Turnbull
> Didn't say it was a democracy. Assumed that it would still involve
> some input from its user base. Is that wrong?
Your phrase "popularly supported" is ambiguous. If you mean "attracts
widespread support in the form of description of varied and plausible
use cases" for new syntax and built-ins, or something like that, I'm
sure the answer is "yes". The question posed by the moratorium
proposal is, "When?"
It seems to me that what Guido is heading for here is very similar to
the "punctuated equilibrium" concept (associated with the evolutionary
biologist Stephen Jay Gould, the wikipedia article is pretty good, and
fairly short). The basic idea is that long periods of relative
stability are "punctuated" by periods of rapid evolution. In biology,
the "bleeding edge" involves literal deaths, and Nature doesn't
hesitate to waste large percentages of a population over the "stable"
period as well as decimating it during the rapid evolution phases.
In software, it may make sense to have the stable periods be *much*
more stable, since artificial systems are more fragile than natural
ones. C, because it occupies an "ecological niche" as a high-level
assembly language, has been quite static since its original
definition, even when it evolves. Python need not be, since its niche
is very different. But it makes sense to propose to compress the
evolution into short periods with many changes, and have very stable
periods of "moratorium" between. Whether it will work well or not,
we'll have to try it to see. But it's not just Guido's intuition that
says it will work to the advantage of Python.
Scott Dial
> In software, it may make sense to have the stable periods be *much*
> more stable, since artificial systems are more fragile than natural
> assembly language, has been quite static since its original
> definition, even when it evolves.
I was going to stay out of this discussion, but I find it highly
annoying to see all these references to C being "static". One need only
glance at the length of GCC's changes for the major version numbers to
see that it is not static by any stretch of the imagination.
Furthermore, the abundance of code revision (even in Python itself!) to
compile without warning or error in various version of C compilers over
the years makes the label "quite static" as laughable.
I believe what you really mean, and what everyone really means, is that
there is a core language that is unchanged over long periods of time.
Changes that caused previously compiling C programs to no longer compile
correctly would be considered a blatant failure of the compiler. That is
not to say there are "no new features," rather only features that are
backwards compatible. As is repeatedly pointed out, people who really do
high-quality, professional development for Python do not develop for the
latest release of Python, they standardize on a minimum version number
and use only the features in that language; this is no different than
writing ISO C90 code rather than ISO C99.
I fail to see how this is not *already* the model that Python and Python
developers are already using. At it's heart, I think the point of what
Guido proposed is for everyone to stop fscking with the language and
just start using it (specifically the 3.x version of it). But, I think
Guido's frustration with the lack of traction of 3.x is misplaced; it's
less than a year ago that it was released, and many ignored 3.0 due to
the io module.
Nevertheless, it is Guido's language and he can do whatever he wants.
--
Scott Dial
sc...@scottdial.com
sco...@cs.indiana.edu
Stephen J. Turnbull
> I was going to stay out of this discussion, but I find it highly
> annoying to see all these references to C being "static". One need only
> glance at the length of GCC's changes for the major version numbers
What does the ChangeLog for an implementation have to do with the
stability of the language definition?
Guido's moratorium does not attempt to regulate adaptation to new
platforms, optimizations, or changes to improve conformance to the
language reference, and (AIUI) not even changes to improve conformance
of the implementation to programmer expectation where the language
reference was ambiguous. Surely the vast majority of GCC changes fit
one of those categories.
Seems to me you have made a very powerful argument-by-analogy that
Guido's moratorium provides plenty of room for hyperactive core
development.