When I think of why Python is so far ahead of Perl in language design, I think it's simply that Python is the result of cautious design, and Perl is the result of exuberant design. I think Python is in danger of becoming a large language - which isn't a good thing. A great language, like Scheme or Python or even C, is a language that has a small, very useful core, and large _libraries_. I'd very much like a live in a world where Jython and IronPython and MicroPython and Cython and Pyjamas can all catch up and implement Python 3.7, 3.8, and so forth.
On 7 May 2018 at 11:30, Dan Stromberg <drsalists@gmail.com> wrote:
I'd very much like a live in a world where Jython and IronPython and MicroPython and Cython and Pyjamas can all catch up and implement Python 3.7, 3.8, and so forth.
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea. Between matrix multiplication, enhanced tuple unpacking, native coroutines, f-strings, and type hinting for variable assignments, we've had quite a bit of syntactic churn in the past few releases, and the rest of the ecosystem really hasn't caught up on it all yet (and that's not just other implementations - it's training material, online courses, etc, etc). If we're going to take such a step, now's also the time to do it, since 3.8 feature development is only just getting under way, and if we did decide to repeat the language moratorium, we could co-announce it with the Python 3.7 release. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, 7 May 2018 12:25:46 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 7 May 2018 at 11:30, Dan Stromberg <drsalists@gmail.com> wrote:
I'd very much like a live in a world where Jython and IronPython and MicroPython and Cython and Pyjamas can all catch up and implement Python 3.7, 3.8, and so forth.
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea. Between matrix multiplication, enhanced tuple unpacking, native coroutines, f-strings, and type hinting for variable assignments, we've had quite a bit of syntactic churn in the past few releases, and the rest of the ecosystem really hasn't caught up on it all yet (and that's not just other implementations - it's training material, online courses, etc, etc).
Not to mention people themselves. Regards Antoine.
On 7 May 2018 at 03:25, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 7 May 2018 at 11:30, Dan Stromberg <drsalists@gmail.com> wrote:
I'd very much like a live in a world where Jython and IronPython and MicroPython and Cython and Pyjamas can all catch up and implement Python 3.7, 3.8, and so forth.
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea. Between matrix multiplication, enhanced tuple unpacking, native coroutines, f-strings, and type hinting for variable assignments, we've had quite a bit of syntactic churn in the past few releases, and the rest of the ecosystem really hasn't caught up on it all yet (and that's not just other implementations - it's training material, online courses, etc, etc).
If we're going to take such a step, now's also the time to do it, since 3.8 feature development is only just getting under way, and if we did decide to repeat the language moratorium, we could co-announce it with the Python 3.7 release.
These are all god points. I think it will be a good idea to take a little pause with syntactic additions and other "cognitively loaded" changes. On the other hand, I think it is fine to work on performance improvements (start-up time, import system etc.), internal APIs (like simplifying start-up sequence and maybe even C API), and polishing corner cases/simplifying existing constructs (like scoping in comprehensions that many people find confusing). IOW, I think the PEP should describe precisely what is OK, and what is not OK during the moratorium. -- Ivan
Hi, I would like to see this go even further and have a tick-tock approach to python versions, i.e. adopt new syntax and other large changes on one version (for example odd versions) and polish everything up in the next (even versions). Best regards, João Santos On Mon, 7 May 2018 at 11:19 Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 7 May 2018 at 03:25, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 7 May 2018 at 11:30, Dan Stromberg <drsalists@gmail.com> wrote:
I'd very much like a live in a world where Jython and IronPython and MicroPython and Cython and Pyjamas can all catch up and implement Python 3.7, 3.8, and so forth.
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea. Between matrix multiplication, enhanced tuple unpacking, native coroutines, f-strings, and type hinting for variable assignments, we've had quite a bit of syntactic churn in the past few releases, and the rest of the ecosystem really hasn't caught up on it all yet (and that's not just other implementations - it's training material, online courses, etc, etc).
If we're going to take such a step, now's also the time to do it, since 3.8 feature development is only just getting under way, and if we did decide to repeat the language moratorium, we could co-announce it with the Python 3.7 release.
These are all god points. I think it will be a good idea to take a little pause with syntactic additions and other "cognitively loaded" changes. On the other hand, I think it is fine to work on performance improvements (start-up time, import system etc.), internal APIs (like simplifying start-up sequence and maybe even C API), and polishing corner cases/simplifying existing constructs (like scoping in comprehensions that many people find confusing).
IOW, I think the PEP should describe precisely what is OK, and what is not OK during the moratorium.
-- Ivan
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/jmcs%40jsantos.eu
On Mon, 7 May 2018 at 08:18 João Santos <jmcs@jsantos.eu> wrote:
Hi,
I would like to see this go even further and have a tick-tock approach to python versions, i.e. adopt new syntax and other large changes on one version (for example odd versions) and polish everything up in the next (even versions).
That's basically an LTS release cycle and discussions of changing how we do releases is a massive discussion that ultimately goes nowhere, so I would advise we stick to the discussion on a moratorium before trying to change how we release Python. :) -Brett
Best regards, João Santos
On Mon, 7 May 2018 at 11:19 Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 7 May 2018 at 03:25, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 7 May 2018 at 11:30, Dan Stromberg <drsalists@gmail.com> wrote:
I'd very much like a live in a world where Jython and IronPython and MicroPython and Cython and Pyjamas can all catch up and implement Python 3.7, 3.8, and so forth.
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea. Between matrix multiplication, enhanced tuple unpacking, native coroutines, f-strings, and type hinting for variable assignments, we've had quite a bit of syntactic churn in the past few releases, and the rest of the ecosystem really hasn't caught up on it all yet (and that's not just other implementations - it's training material, online courses, etc, etc).
If we're going to take such a step, now's also the time to do it, since 3.8 feature development is only just getting under way, and if we did decide to repeat the language moratorium, we could co-announce it with the Python 3.7 release.
These are all god points. I think it will be a good idea to take a little pause with syntactic additions and other "cognitively loaded" changes. On the other hand, I think it is fine to work on performance improvements (start-up time, import system etc.), internal APIs (like simplifying start-up sequence and maybe even C API), and polishing corner cases/simplifying existing constructs (like scoping in comprehensions that many people find confusing).
IOW, I think the PEP should describe precisely what is OK, and what is not OK during the moratorium.
-- Ivan
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/jmcs%40jsantos.eu
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
On 7 May 2018 at 17:32, Brett Cannon <brett@python.org> wrote:
On Mon, 7 May 2018 at 08:18 João Santos <jmcs@jsantos.eu> wrote:
Hi,
I would like to see this go even further and have a tick-tock approach to python versions, i.e. adopt new syntax and other large changes on one version (for example odd versions) and polish everything up in the next (even versions).
[...], so I would advise we stick to the discussion on a moratorium [...]
Btw the upcoming Language Summit may be a good opportunity for such discussion. -- Ivan
On Mon, 7 May 2018 at 09:55 Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 7 May 2018 at 17:32, Brett Cannon <brett@python.org> wrote:
On Mon, 7 May 2018 at 08:18 João Santos <jmcs@jsantos.eu> wrote:
Hi,
I would like to see this go even further and have a tick-tock approach to python versions, i.e. adopt new syntax and other large changes on one version (for example odd versions) and polish everything up in the next (even versions).
[...], so I would advise we stick to the discussion on a moratorium [...]
Btw the upcoming Language Summit may be a good opportunity for such discussion.
If it's not already on the schedule for discussion then the best you are going to get is a lightning talk to bring up the idea which will definitely not enough time ;) . Otherwise the schedule is full and locked down at this point.
On May 7, 2018, at 9:57 AM, Brett Cannon <brett@python.org> wrote:
On Mon, 7 May 2018 at 09:55 Ivan Levkivskyi <levkivskyi@gmail.com <mailto:levkivskyi@gmail.com>> wrote: On 7 May 2018 at 17:32, Brett Cannon <brett@python.org <mailto:brett@python.org>> wrote: On Mon, 7 May 2018 at 08:18 João Santos <jmcs@jsantos.eu <mailto:jmcs@jsantos.eu>> wrote: Hi,
I would like to see this go even further and have a tick-tock approach to python versions, i.e. adopt new syntax and other large changes on one version (for example odd versions) and polish everything up in the next (even versions).
[...], so I would advise we stick to the discussion on a moratorium [...]
Btw the upcoming Language Summit may be a good opportunity for such discussion.
If it's not already on the schedule for discussion then the best you are going to get is a lightning talk to bring up the idea which will definitely not enough time ;) . Otherwise the schedule is full and locked down at this point.
FWIW I'm hearing the 3.8 release manager has a short talk related to this subject! - Ł
On 7 May 2018 at 19:17, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
These are all god points. I think it will be a good idea to take a little pause with syntactic additions and other "cognitively loaded" changes. On the other hand, I think it is fine to work on performance improvements (start-up time, import system etc.), internal APIs (like simplifying start-up sequence and maybe even C API), and polishing corner cases/simplifying existing constructs (like scoping in comprehensions that many people find confusing).
IOW, I think the PEP should describe precisely what is OK, and what is not OK during the moratorium.
Aye, for folks that haven't read it before, https://www.python.org/dev/peps/pep-3003/#details is worth a look as to the specifics of what a language moratorium entails. While only 3.2 was specifically covered by the moratorium, from 3.2 through to 3.4, the only language level changes we made were to allow "yield from x" as a coroutine-friendly alternative to "for x in iterable: yield x", and to reinstate support for the "u" prefix on strings. The main builtin changes in that period were to rework the exception hierarchy to make it more descriptive of what *caused* an error, rather than where the error was raised, and those were deliberately designed to be almost entirely backwards compatible. Since that last period of calm, 3.5 and 3.6 both introduced a broad selection of syntax changes, and even 3.7 has introduced a new __future__ statement to change the way annotations are handled. And as the current python-ideas discussion about accessing paths relative to __file__ shows, even core devs (i.e. me) are still digesting the full implications that pathlib and the os.fspath protocol may have for the recommendations that we should be giving to new (and existing!) developers that don't need to worry about Python 2.7 compatibility. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
May it is important to note that Python 3.7 already has very little syntactic changes. Actually, there are no new syntac changes with PEP 563 - (Postponed Evaluation of Annotations) being maybe the only change to existing behavior, and PEP 562 as new "non-library-dependent" feature, even though no new syntax is added. (contextvars - PEP 567 - is a big change, but is constrained to a new stdlib module). On the other hand, one of the hottest topics being discussed now - PEP 572 - would be quite a change that would violate such a moratorium. What would happen if we wd'd take such a moratorium now? Have Python with no real syntactic changes since f-strings up to version 3.9 (~4.5 years after 3.6)? Allow just whatever is already being discussed - introducing a major change (local assignments) in 3.8, but just bar others because people did not think of then before this moratorium was proposed? Maybe simply there is just no need for such a moratorium mechanism, and the natural barriers for new features can work to keep things in manageable pace, as we can see by the release getting ready right now. best regards, js -><- On 7 May 2018 at 10:20, Serhiy Storchaka <storchaka@gmail.com> wrote:
07.05.18 14:19, Nick Coghlan пише:
And as the current python-ideas discussion about accessing paths relative to __file__ shows,
I can't believe this is discussed seriously. Forgot about the Python 2 legacy, just use importlib.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
07.05.18 16:50, Joao S. O. Bueno пише:
May it is important to note that Python 3.7 already has very little syntactic changes. Actually, there are no new syntac changes with PEP 563 - (Postponed Evaluation of Annotations) being maybe the only change to existing behavior, and PEP 562 as new "non-library-dependent" feature, even though no new syntax is added. (contextvars - PEP 567 - is a big change, but is constrained to a new stdlib module).
It looks to me that Python 3.7 may cause the largest breakage since 3.2 because of "async". It is pretty popular name for arguments, attributes and methods. Many third-party projects needed to fix this now (despites it was deprecated since 3.5). Many third-party projects depends on libraries which needed the "async" fix for 3.7. But in general this breakage is very small. It just looks larger than in previous versions.
On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea.
Note that the PEP specifically applies to "syntax, semantics, and built-ins". Here's the full abstract [1]: This PEP proposes a temporary moratorium (suspension) of all changes to the Python language syntax, semantics, and built-ins for a period of at least two years from the release of Python 3.1. In particular, the moratorium would include Python 3.2 (to be released 18-24 months after 3.1) but allow Python 3.3 (assuming it is not released prematurely) to once again include language changes. This suspension of features is designed to allow non-CPython implementations to "catch up" to the core implementation of the language, help ease adoption of Python 3.x, and provide a more stable base for the community. -eric [1] https://www.python.org/dev/peps/pep-3003/#abstract
On 5/7/2018 7:59 AM, Eric Snow wrote:
On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea. Note that the PEP specifically applies to "syntax, semantics, and built-ins". Here's the full abstract [1]:
This PEP proposes a temporary moratorium (suspension) of all changes to the Python language syntax, semantics, and built-ins for a period of at least two years from the release of Python 3.1. In particular, the moratorium would include Python 3.2 (to be released 18-24 months after 3.1) but allow Python 3.3 (assuming it is not released prematurely) to once again include language changes.
This suspension of features is designed to allow non-CPython implementations to "catch up" to the core implementation of the language, help ease adoption of Python 3.x, and provide a more stable base for the community.
-eric Here's my "lightning" response to a "lightning talk" about a moratorium:
So if other implementations didn't catch up during the last moratorium, either the moratorium then was lifted too soon, or the other implementations don't really want to catch up, or the thought that they should catch up was deemed less important than making forward progress with the language. Have any of those opinions changed? While async is a big change that I personally haven't grasped, but which has little impact (a couple keywords) on code that doesn't use it, a new moratorium wouldn't impact it, and nothing else that is happening seems too much or too fast from my perspective. Dan's original comment about language versus library is interesting, though. It is probably true that one should resist adding language where library suffices, but sometimes a lack of certain expressiveness in the language causes cumbersome implementations of library routines to achieve the goal. f-strings and binding expressions are cases where (1) the functionality is certainly possible via library (2) there is a large amount of code that uses the functionality, and (3) said code is more cumbersome without the expressiveness of the newer syntax.
On Mon, May 07, 2018 at 10:21:13AM -0700, Glenn Linderman wrote:
Dan's original comment about language versus library is interesting, though. It is probably true that one should resist adding language where library suffices, but sometimes a lack of certain expressiveness in the language causes cumbersome implementations of library routines to achieve the goal.
+1 -- Steve
On Mon, May 7, 2018 at 10:21 AM, Glenn Linderman <v+python@g.nevcal.com> wrote:
On 5/7/2018 7:59 AM, Eric Snow wrote:
On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea.
Note that the PEP specifically applies to "syntax, semantics, and built-ins". Here's the full abstract [1]:
This PEP proposes a temporary moratorium (suspension) of all changes to the Python language syntax, semantics, and built-ins for a period of at least two years from the release of Python 3.1. In particular, the moratorium would include Python 3.2 (to be released 18-24 months after 3.1) but allow Python 3.3 (assuming it is not released prematurely) to once again include language changes.
This suspension of features is designed to allow non-CPython implementations to "catch up" to the core implementation of the language, help ease adoption of Python 3.x, and provide a more stable base for the community.
-eric
Here's my "lightning" response to a "lightning talk" about a moratorium:
So if other implementations didn't catch up during the last moratorium, either the moratorium then was lifted too soon, or the other implementations don't really want to catch up, or the thought that they should catch up was deemed less important than making forward progress with the language. Have any of those opinions changed?
Speaking as the maintainer of IronPython during the last moratorium: while catching up was certainly desirable, there simply wasn't enough person-power to do it any reasonable amount of time (I'm not sure any implementation besides PyPy even has yield-from, let alone async). Between fixing issues in 2.x branches, trying to implement 3.x features, and dealing with underlying platform churn I don't think even two years was ever realistic. Plus, every feature has to be considered with how it works in Python and the other platform (like, what sort of fun .NET interop can we do with type annotations?). Another moratorium would probably have the same (lack of) effect. Better, IMO, to just raise the bar on expensive features and let them catch up naturally. - Jeff
On Sun, May 6, 2018 at 7:35 PM Nick Coghlan <ncoghlan@gmail.com> wrote:
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea. Between matrix multiplication, enhanced tuple unpacking, native coroutines, f-strings, and type hinting for variable assignments, we've had quite a bit of syntactic churn in the past few releases, and the rest of the ecosystem really hasn't caught up on it all yet (and that's not just other implementations - it's training material, online courses, etc, etc).
If we're going to take such a step, now's also the time to do it, since 3.8 feature development is only just getting under way, and if we did decide to repeat the language moratorium, we could co-announce it with the Python 3.7 release.
Would it be reasonable to request a 10 year moratorium on making changes to the core Python language, and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.? There are still many companies still stuck on Python 2, so giving 10 years of breathing room for these companies to catch up to Python 3 core language, even past 2020 would be very helpful. -- Craig
10 years feels like a simultaneously long and arbitrary limit. IMO a policy of "try to avoid major language features for a while" would work better. On Mon, May 7, 2018 at 2:11 PM Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Sun, May 6, 2018 at 7:35 PM Nick Coghlan <ncoghlan@gmail.com> wrote:
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea. Between matrix multiplication, enhanced tuple unpacking, native coroutines, f-strings, and type hinting for variable assignments, we've had quite a bit of syntactic churn in the past few releases, and the rest of the ecosystem really hasn't caught up on it all yet (and that's not just other implementations - it's training material, online courses, etc, etc).
If we're going to take such a step, now's also the time to do it, since 3.8 feature development is only just getting under way, and if we did decide to repeat the language moratorium, we could co-announce it with the Python 3.7 release.
Would it be reasonable to request a 10 year moratorium on making changes to the core Python language, and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.?
There are still many companies still stuck on Python 2, so giving 10 years of breathing room for these companies to catch up to Python 3 core language, even past 2020 would be very helpful.
-- Craig _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
-- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/
On Mon, 07 May 2018 19:19:28 +0000 Ryan Gonzalez <rymg19@gmail.com> wrote:
10 years feels like a simultaneously long and arbitrary limit. IMO a policy of "try to avoid major language features for a while" would work better.
I would remove "for a while". "Try to avoid major language features" sounds good. Regards Antoine.
On Mon, May 07, 2018 at 10:23:32PM +0200, Antoine Pitrou wrote:
On Mon, 07 May 2018 19:19:28 +0000 Ryan Gonzalez <rymg19@gmail.com> wrote:
10 years feels like a simultaneously long and arbitrary limit. IMO a policy of "try to avoid major language features for a while" would work better.
I would remove "for a while". "Try to avoid major language features" sounds good.
It sounds good, until you ask about "What if we had that policy from the beginning?" Let's see what sort of language features we would miss out on if we avoided language features because there was an existing alternative: - async/await ("use the asyncio library") - comprehensions ("just write a loop") - True/False builtins ("just define your own constants at the top of the module") - f-strings ("just use str.format") - yield from ("most of the time you can just use ``for x in thing: yield x``, the rest of the cases are too obscure and unimportant to justify new syntax") - with statements and context managers ("just use a try... finally") - ternary if ("just re-write it as a if...else block, or use the ``x or y and z`` trick") - closures ("just write a class") - yield as an expression for sending values into a generator (a pre-async kind of coroutine) ("just write a class") - function annotations ("just use one of three or four competing standards for docstring annotations") The only language feature I can think of that had no way of doing it before being added to the library was Unicode support. So we'd effectively have Python 1.5 plus Unicode. If we could look forward to 2028, when we're running Python 3.14 or so (4.7 if you prefer), how many fantastic language features that we cannot bear to give up would we be missing out on? -- Steve
[Steven D'Aprano <steve@pearwood.info>]
... If we could look forward to 2028, when we're running Python 3.14 or so (4.7 if you prefer), how many fantastic language features that we cannot bear to give up would we be missing out on?
This, for just one: k = 6 if >!{myobj.meth(arg)[2]} elsenone 7 elsenan 8 else 5 Which is really annoying to write today, but would be much clearer with binding expressions: if myobj is None: k = 7 elif (t := myobj.meth) is None: k = 7 elif (t := t(arg)) is None: k = 7 elif (t := t[2]) is None: k = 7 eiif math.isnan(t): k = 8 elif t: k = 6 else: k = 5 The future is blindingly bright :-)
Serhiy Storchaka <storchaka@gmail.com> writes:
09.05.18 07:25, Steven D'Aprano пише:
If we could look forward to 2028, when we're running Python 3.14 or so (4.7 if you prefer), how many fantastic language features that we cannot bear to give up would we be missing out on?
Like tab-delimited tables.
Cheeky :-) (For those who are not closely following comp.lang.python, I am pretty sure Serhiy is wryly referring to an ongoing thread in that forum. Someone is arguing that Python should grow a U+0009-delimited syntax for tabular data, and quickly demonstrated a lack of interest in the familir reasons why this is a bad idea. The thread is already past the point of calm discussion, so I am not linking to it because it's not worth wading into.) -- \ “I wish I had a dollar for every time I spent a dollar, because | `\ then, yahoo!, I'd have all my money back.” —Jack Handey | _o__) | Ben Finney
Serhiy Storchaka wrote:
Like tab-delimited tables.
No, the obvious way to do tables is to allow HTML-marked-up source code. There would be other benefits to that as well. For example we could decree that all keywords must be formatted in <b>bold</b>, and then there would be no trouble adding new keywords. -- Greg
On Wed, 9 May 2018 14:25:06 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, May 07, 2018 at 10:23:32PM +0200, Antoine Pitrou wrote:
On Mon, 07 May 2018 19:19:28 +0000 Ryan Gonzalez <rymg19@gmail.com> wrote:
10 years feels like a simultaneously long and arbitrary limit. IMO a policy of "try to avoid major language features for a while" would work better.
I would remove "for a while". "Try to avoid major language features" sounds good.
It sounds good, until you ask about "What if we had that policy from the beginning?"
Let's see what sort of language features we would miss out on if we avoided language features because there was an existing alternative: [...]
"Try to avoid" would make it more of a general guideline than a hard rule, IMHO. I proposed the idea in another thread that Python had reached "peak syntax" and maybe it was time to consider the core language essentially mature. Of course, we don't know what the future will bring and perhaps some fundamentally new programming idiom will appear in the next years that deserve implementing in Python. Regards Antoine.
On Wed, May 09, 2018 at 01:35:53PM +0200, Antoine Pitrou wrote:
I would remove "for a while". "Try to avoid major language features" sounds good.
It sounds good, until you ask about "What if we had that policy from the beginning?" [...] "Try to avoid" would make it more of a general guideline than a hard rule, IMHO.
Fair enough. But it really depends on how hard we try: too hard, or not hard enough? *wink* -- Steve
09.05.18 14:35, Antoine Pitrou пише:
I proposed the idea in another thread that Python had reached "peak syntax" and maybe it was time to consider the core language essentially mature. Of course, we don't know what the future will bring and perhaps some fundamentally new programming idiom will appear in the next years that deserve implementing in Python.
"If you want to add a new syntax feature, first remove two old syntax features."
On May 7, 2018, at 11:49, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
Would it be reasonable to request a 10 year moratorium on making changes to the core Python language, and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.?
IMHO, no. I don’t believe that the way for Python to remain relevant and useful for the next 10 years is to cease all language evolution. Who knows what the computing landscape will look like in 5 years, let alone 10? Something as arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the language. But I do think it makes sense to think about how Python-the-language and CPython-the-reference implementation can better balance the desire to evolve vs the need to concentrate on improving what we’ve got. With that in mind, it does make sense to occasionally use a moratorium release to focus on tech debt, cleaning up the stdlib, improve performance, etc. CPython’s 18 month release cycle has served us well for a long time, but I do think it’s time to discuss whether it will still be appropriate moving forward. I’m not saying it is or isn’t, but with the release of 3.7, I think it’s a great time to explore our options. Cheers, -Barry
A moratorium on new features to focus on cleaning up and planning for transition away from the 2.7 compatibility features that still exist? The most obvious being the libraries that we promised not to remove until 2.7 EOL. Top-posted from my Windows phone From: Barry Warsaw Sent: Monday, May 7, 2018 14:26 To: Python Dev Subject: Re: [Python-Dev] Slow down... On May 7, 2018, at 11:49, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
Would it be reasonable to request a 10 year moratorium on making changes to the core Python language, and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.?
IMHO, no. I don’t believe that the way for Python to remain relevant and useful for the next 10 years is to cease all language evolution. Who knows what the computing landscape will look like in 5 years, let alone 10? Something as arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the language. But I do think it makes sense to think about how Python-the-language and CPython-the-reference implementation can better balance the desire to evolve vs the need to concentrate on improving what we’ve got. With that in mind, it does make sense to occasionally use a moratorium release to focus on tech debt, cleaning up the stdlib, improve performance, etc. CPython’s 18 month release cycle has served us well for a long time, but I do think it’s time to discuss whether it will still be appropriate moving forward. I’m not saying it is or isn’t, but with the release of 3.7, I think it’s a great time to explore our options. Cheers, -Barry
On Mon, May 7, 2018 at 2:24 PM Barry Warsaw <barry@python.org> wrote:
On May 7, 2018, at 11:49, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
Would it be reasonable to request a 10 year moratorium on making changes
to the core Python language,
and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.?
IMHO, no.
I don’t believe that the way for Python to remain relevant and useful for the next 10 years is to cease all language evolution. Who knows what the computing landscape will look like in 5 years, let alone 10? Something as arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the language.
But I do think it makes sense to think about how Python-the-language and CPython-the-reference implementation can better balance the desire to evolve vs the need to concentrate on improving what we’ve got. With that in mind, it does make sense to occasionally use a moratorium release to focus on tech debt, cleaning up the stdlib, improve performance, etc.
CPython’s 18 month release cycle has served us well for a long time, but I do think it’s time to discuss whether it will still be appropriate moving forward. I’m not saying it is or isn’t, but with the release of 3.7, I think it’s a great time to explore our options.
10 years is a long time for many types of applications, such as web server and desktop applications where regular and somewhat frequent upgrades can happen. However, I have worked on embedding Python in networking and storage devices. It is true that many of these types of devices can also have their software upgraded, but often the frequency of such upgrades is much slower than for conventional web server and desktop applications. Upgrades of these devices usually spans user-space and kernel/device drivers, so upgrades are usually done more cautiously and less frequently. For Python 2.x, the ship has sailed. However, 10 years from now, if the Python language is pretty much the same as Python 3.7 today, that would be nice. I'm not stuck on the number "10 years", but I am just throwing it out there as a draft proposal. So even 5-8 year moratorium would be nice to strive for. Outside of the embedded space, I will give another example where folks in industry are behind. I don't want to pick on a particular vendor, but from April 24-26, I attended training sessions at RedisConf18 in San Francisco. During the training sessions, multiple sample Python code examples were given for accessing the Redis database. The instructor thought that the code examples worked in Python 3, but in fact, they only worked in Python 2 mostly due to bytes/unicode issues. During the class, I fixed the examples for Python 3 and submitted the patches to the instructor, who gratefully accepted my patches. However, there are going to be many, many users of Redis out there who maybe will not upgrade their Python code for newer versions of Python for many years. Besides Redis users, I am seeing all sorts of communities and companies which are behind in terms of having working code and documentation that works on latest Python 3. It is going to take YEARS for all these communities and companies to catch up (if ever). I understand that Python as a language must evolve over time to succeed and thrive. But I would request that at least for the next 5-10 years, a moratorium on language changes be considered, to allow the world to catch up in terms of code, documentation, and mind/understanding. Looking back at how the Python 2.7 EOL was extended by 5 years, I would remind the core Python developers that it is very easy to underestimate how slow the world is to change their code, documentation, training, and understanding to adapt to new Python versions. Going slow or imposing a moratorium wouldn't be such a bad thing. -- Craig
On Tue, 8 May 2018 at 08:26 Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Mon, May 7, 2018 at 2:24 PM Barry Warsaw <barry@python.org> wrote:
On May 7, 2018, at 11:49, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
Would it be reasonable to request a 10 year moratorium on making
changes to the core Python language,
and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.?
IMHO, no.
I don’t believe that the way for Python to remain relevant and useful for the next 10 years is to cease all language evolution. Who knows what the computing landscape will look like in 5 years, let alone 10? Something as arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the language.
But I do think it makes sense to think about how Python-the-language and CPython-the-reference implementation can better balance the desire to evolve vs the need to concentrate on improving what we’ve got. With that in mind, it does make sense to occasionally use a moratorium release to focus on tech debt, cleaning up the stdlib, improve performance, etc.
CPython’s 18 month release cycle has served us well for a long time, but I do think it’s time to discuss whether it will still be appropriate moving forward. I’m not saying it is or isn’t, but with the release of 3.7, I think it’s a great time to explore our options.
10 years is a long time for many types of applications, such as web server and desktop applications where regular and somewhat frequent upgrades can happen. However, I have worked on embedding Python in networking and storage devices. It is true that many of these types of devices can also have their software upgraded, but often the frequency of such upgrades is much slower than for conventional web server and desktop applications. Upgrades of these devices usually spans user-space and kernel/device drivers, so upgrades are usually done more cautiously and less frequently.
For Python 2.x, the ship has sailed. However, 10 years from now, if the Python language is pretty much the same as Python 3.7 today, that would be nice.
Then feel free to stay on Python 3.7. We have versioned releases so people can choose to do that. :)
I'm not stuck on the number "10 years", but I am just throwing it out there as a draft proposal. So even 5-8 year moratorium would be nice to strive for.
Timespans of that length are still too long to freeze the language. Look at it this way: node.js 0.10.0 was released 5 years ago and now it's a thing. If we had not moved forward and added async/await in Python 3.5 -- which was only 3 years ago -- but instead froze ourselves for 5 years would we be considered relevant in the networking world like we are, or viewed as somewhat as a dinosaur? I realize the embedded world moves at a different pace (as well as other groups of developers), but that doesn't mean we have to move at the speed of our slowest adopters to punish those willing and wanting newer features.
Outside of the embedded space, I will give another example where folks in industry are behind. I don't want to pick on a particular vendor, but from April 24-26, I attended training sessions at RedisConf18 in San Francisco. During the training sessions, multiple sample Python code examples were given for accessing the Redis database. The instructor thought that the code examples worked in Python 3, but in fact, they only worked in Python 2 mostly due to bytes/unicode issues. During the class, I fixed the examples for Python 3 and submitted the patches to the instructor, who gratefully accepted my patches. However, there are going to be many, many users of Redis out there who maybe will not upgrade their Python code for newer versions of Python for many years.
Why is Redis specifically going to be behind specifically? Are they embedding the interpreter?
Besides Redis users, I am seeing all sorts of communities and companies which are behind in terms of having working code and documentation that works on latest Python 3. It is going to take YEARS for all these communities and companies to catch up (if ever).
And that's fine. If they want to continue to maintain Python 2 and stay on it, or simply stick with our final release and never worry about potential security issues, that's their prerogative. But once again, we shouldn't have to hold up the entire language for the slowest adopters.
I understand that Python as a language must evolve over time to succeed and thrive. But I would request that at least for the next 5-10 years, a moratorium on language changes be considered, to allow the world to catch up in terms of code, documentation, and mind/understanding.
5 years is 3-4 releases, 10 years is 6-7. That's basically saying we should still be like 3.3/3.2 or 2.7, both of which I don't think the majority of people want (I know I am a happier programmer in 3.6 than I am in any of those versions).
Looking back at how the Python 2.7 EOL was extended by 5 years, I would remind the core Python developers that it is very easy to underestimate how slow the world is to change their code, documentation, training, and understanding to adapt to new Python versions. Going slow or imposing a moratorium wouldn't be such a bad thing.
I think a better way to phrase this is, "should we not change the language because there are still people on Python 3.3? We've already stated many times that there won't be a major language upheaval like 2/3 ever again, so we are only talking about changes on the order of e.g. 3.5/3.6. And for me, I like what we have added. I am certainly not about to ask anyone to give up f-strings and deal with those pitchforks. ;) And if people don't upgrade then people don't upgrade. We have all the old versions of libraries on PyPI, so people can continue to use the libraries that they were depending on when they choose to not move forward with Python releases and continue to function.
On May 8, 2018, at 11:48 AM, Brett Cannon <brett@python.org> wrote:
On Tue, 8 May 2018 at 08:26 Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Mon, May 7, 2018 at 2:24 PM Barry Warsaw <barry@python.org> wrote: On May 7, 2018, at 11:49, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
Would it be reasonable to request a 10 year moratorium on making changes to the core Python language, and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.?
IMHO, no.
I don’t believe that the way for Python to remain relevant and useful for the next 10 years is to cease all language evolution. Who knows what the computing landscape will look like in 5 years, let alone 10? Something as arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the language.
But I do think it makes sense to think about how Python-the-language and CPython-the-reference implementation can better balance the desire to evolve vs the need to concentrate on improving what we’ve got. With that in mind, it does make sense to occasionally use a moratorium release to focus on tech debt, cleaning up the stdlib, improve performance, etc.
CPython’s 18 month release cycle has served us well for a long time, but I do think it’s time to discuss whether it will still be appropriate moving forward. I’m not saying it is or isn’t, but with the release of 3.7, I think it’s a great time to explore our options.
10 years is a long time for many types of applications, such as web server and desktop applications where regular and somewhat frequent upgrades can happen. However, I have worked on embedding Python in networking and storage devices. It is true that many of these types of devices can also have their software upgraded, but often the frequency of such upgrades is much slower than for conventional web server and desktop applications. Upgrades of these devices usually spans user-space and kernel/device drivers, so upgrades are usually done more cautiously and less frequently.
For Python 2.x, the ship has sailed. However, 10 years from now, if the Python language is pretty much the same as Python 3.7 today, that would be nice.
Then feel free to stay on Python 3.7. We have versioned releases so people can choose to do that. :)
Also, you can pay people to support old versions, and sometimes even backport features you need. So I think this use case is already covered. You just can’t expect to hold up language development because you want to have a stable supported version. Eric
I'm not stuck on the number "10 years", but I am just throwing it out there as a draft proposal. So even 5-8 year moratorium would be nice to strive for.
Timespans of that length are still too long to freeze the language. Look at it this way: node.js 0.10.0 was released 5 years ago and now it's a thing. If we had not moved forward and added async/await in Python 3.5 -- which was only 3 years ago -- but instead froze ourselves for 5 years would we be considered relevant in the networking world like we are, or viewed as somewhat as a dinosaur?
I realize the embedded world moves at a different pace (as well as other groups of developers), but that doesn't mean we have to move at the speed of our slowest adopters to punish those willing and wanting newer features.
Outside of the embedded space, I will give another example where folks in industry are behind. I don't want to pick on a particular vendor, but from April 24-26, I attended training sessions at RedisConf18 in San Francisco. During the training sessions, multiple sample Python code examples were given for accessing the Redis database. The instructor thought that the code examples worked in Python 3, but in fact, they only worked in Python 2 mostly due to bytes/unicode issues. During the class, I fixed the examples for Python 3 and submitted the patches to the instructor, who gratefully accepted my patches. However, there are going to be many, many users of Redis out there who maybe will not upgrade their Python code for newer versions of Python for many years.
Why is Redis specifically going to be behind specifically? Are they embedding the interpreter?
Besides Redis users, I am seeing all sorts of communities and companies which are behind in terms of having working code and documentation that works on latest Python 3. It is going to take YEARS for all these communities and companies to catch up (if ever).
And that's fine. If they want to continue to maintain Python 2 and stay on it, or simply stick with our final release and never worry about potential security issues, that's their prerogative. But once again, we shouldn't have to hold up the entire language for the slowest adopters.
I understand that Python as a language must evolve over time to succeed and thrive. But I would request that at least for the next 5-10 years, a moratorium on language changes be considered, to allow the world to catch up in terms of code, documentation, and mind/understanding.
5 years is 3-4 releases, 10 years is 6-7. That's basically saying we should still be like 3.3/3.2 or 2.7, both of which I don't think the majority of people want (I know I am a happier programmer in 3.6 than I am in any of those versions).
Looking back at how the Python 2.7 EOL was extended by 5 years, I would remind the core Python developers that it is very easy to underestimate how slow the world is to change their code, documentation, training, and understanding to adapt to new Python versions. Going slow or imposing a moratorium wouldn't be such a bad thing.
I think a better way to phrase this is, "should we not change the language because there are still people on Python 3.3? We've already stated many times that there won't be a major language upheaval like 2/3 ever again, so we are only talking about changes on the order of e.g. 3.5/3.6. And for me, I like what we have added. I am certainly not about to ask anyone to give up f-strings and deal with those pitchforks. ;)
And if people don't upgrade then people don't upgrade. We have all the old versions of libraries on PyPI, so people can continue to use the libraries that they were depending on when they choose to not move forward with Python releases and continue to function. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40tru...
On 2018-05-07 19:49, Craig Rodrigues wrote:
[snip]
Would it be reasonable to request a 10 year moratorium on making changes to the core Python language, and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.?
There are still many companies still stuck on Python 2, so giving 10 years of breathing room for these companies to catch up to Python 3 core language, even past 2020 would be very helpful.
[snip] I don't see how a 10 year moratorium will help those still on Python 2, given that Python 2.7 has been around for almost 8 years already, by 2020 it will have been 10 years, and it was made clear that it would be the last in the Python 2 line.
This seems like a rather bad idea. None of the core changes in the last few versions were on the radar 10 years in advance. And likewise, no one really knows what new issues will become critical over the next 10. The asyncio module and the async/await keywords only developed as important concerns for a year or two before they became part of the language. Likewise for type annotations. Neither is used by most Python programmers, but for a subset, they are very important. I supposed f-strings are incidental. We could have lived without them (I myself doughty opposed "another way to do it"). But they do make code nicer at the cost of incompatible syntax. Likewise underscores in numbers like 17_527_103. Not everyone needs the __mmul__() operator. But for linear algebra, 'a @ b.T' is better than 'np.dot(a, b.T)'. On Mon, May 7, 2018, 3:10 PM Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Sun, May 6, 2018 at 7:35 PM Nick Coghlan <ncoghlan@gmail.com> wrote:
I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 language moratorium could be a very good idea. Between matrix multiplication, enhanced tuple unpacking, native coroutines, f-strings, and type hinting for variable assignments, we've had quite a bit of syntactic churn in the past few releases, and the rest of the ecosystem really hasn't caught up on it all yet (and that's not just other implementations - it's training material, online courses, etc, etc).
If we're going to take such a step, now's also the time to do it, since 3.8 feature development is only just getting under way, and if we did decide to repeat the language moratorium, we could co-announce it with the Python 3.7 release.
Would it be reasonable to request a 10 year moratorium on making changes to the core Python language, and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.?
There are still many companies still stuck on Python 2, so giving 10 years of breathing room for these companies to catch up to Python 3 core language, even past 2020 would be very helpful.
-- Craig _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
participants (23)
-
Antoine Pitrou -
Barry Warsaw -
Ben Finney -
Brett Cannon -
Craig Rodrigues -
Dan Stromberg -
David Mertz -
Eric Snow -
Eric V. Smith -
Glenn Linderman -
Greg Ewing -
Ivan Levkivskyi -
Jeff Hardy -
Joao S. O. Bueno -
João Santos -
Lukasz Langa -
MRAB -
Nick Coghlan -
Ryan Gonzalez -
Serhiy Storchaka -
Steve Dower -
Steven D'Aprano -
Tim Peters