Re: [Python-Dev] Slow down...
On Mon, May 7, 2018 at 2:24 PM Barry Warsaw wrote: > On May 7, 2018, at 11:49, Craig Rodrigues 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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Process to remove a Python feature
Le 02/05/2018 à 11:11, Victor Stinner a écrit :
> * Communicate on python-dev, Twitter, Python Insider blog, etc.
> * Collaborate with major Python projects to help them to migrate the
> alternative
I wonder if it would be interesting to have a package available by
pypi.org which would provide the removed features. In your example, the
developers would have to update their source code:
# giving 'obsolete' as name for this package
platform.linux_distribution() -> obsolete.platform.linux_distribution()
The code in 'obsolete' package could come from the removed code from
cpython or a wrapper around a third-party package ('distro' package in
the example).
Plus:
- quick temporary fix for users -> the removal is less painful
- the name of the import is a hint that something has to be fixed ->
useful for new comers on the user source code
Cons:
- it pushes the question to how many times the previous behavior should
be maintained from python language to 'obsolete' package. So it's not
completely solved.
- it adds a step to removal procedure.
- I guess there are some features not movable into a package.
--
Stéphane
signature.asc
Description: OpenPGP digital signature
___
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/archive%40mail-archive.com
Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
On 2018-05-06 09:35, Nick Coghlan wrote: Thanks for this update Jeroen! If it doesn't come up otherwise, I'll try to claim one of the lightning talk slots at the Language Summit to discuss this with folks in person :) Sounds great! I'd love to hear what people think. As an example of how the new functionality of PEP 575 can be used, I changed functools.lru_cache to implement the _lru_cache_wrapper class as subclass of base_function. I added this to the reference implementation https://github.com/jdemeyer/cpython/tree/pep575 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Slow down...
On Tue, 8 May 2018 at 08:26 Craig Rodrigues wrote: > On Mon, May 7, 2018 at 2:24 PM Barry Warsaw wrote: > >> On May 7, 2018, at 11:49, Craig Rodrigues 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, 1
Re: [Python-Dev] Process to remove a Python feature
On Tue, May 8, 2018 at 3:20 PM, Stéphane Blondon wrote: > Le 02/05/2018 à 11:11, Victor Stinner a écrit : > > * Communicate on python-dev, Twitter, Python Insider blog, etc. > > * Collaborate with major Python projects to help them to migrate the > alternative > > I wonder if it would be interesting to have a package available by > pypi.org which would provide the removed features. In your example, the > developers would have to update their source code: > > # giving 'obsolete' as name for this package > platform.linux_distribution() -> obsolete.platform.linux_distribution() If one can import from the future can one can also import from the past? -- Joni Orponen ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Process to remove a Python feature
On 05/04/2018 11:48 AM, Serhiy Storchaka wrote: 04.05.18 20:57, Matthias Bussonnier пише: But when I hit a DeprecationWarning message there is one crucial piece of information missing most of the time: Since which version number it's deprecated (and sometime since when the replacement is available could be good if overlap between functionality there was). I think the information about since which version number it will be removed is more useful. Different cases need different deprecation periods. The more common the case, the longer deprecation period should be. Some recently added warnings contain this information. If we are going to provide extra metadata, we may as well supply it all. Some folks will need the start date, some the end date, and probably some both dates. X.Y+1: added a deprecation warning. Many users need to support only two recent versions and can move to using the replacement now. I'm curious how you arrived at this conclusion? I know I've only worked at two different Python-using companies, but neither aggressively tracks the latest Python minor version, and as a library author I support more than the two most recent versions. -- ~Ethan~ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Process to remove a Python feature
08.05.18 18:51, Joni Orponen пише: If one can import from the future can one can also import from the past? One can move removed feature to a third-party module and import them from it. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Process to remove a Python feature
On Tue, May 08, 2018 at 03:20:50PM +0200, Stéphane Blondon wrote: > I wonder if it would be interesting to have a package available by > pypi.org which would provide the removed features. [...] > Cons: > - it pushes the question to how many times the previous behavior should > be maintained from python language to 'obsolete' package. So it's not > completely solved. Its not solved at all. Who is responsible for moving code to this third-party package? Who is responsible for maintaining that third-party package? If it is the core developers, then it isn't really removed at all. If nobody is maintaining it, then its going to suffer bitrot and become unusable. Python is open source, so anyone can fork a module or library from the std lib and move it to PyPI, they don't need the core dev's blessing, they just need to follow the licence requirements. -- Steve ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Process to remove a Python feature
04.05.18 22:08, Matthias Bussonnier пише: Maybe to push people forward, but from experience it is hard to predict future, so saying when it _will_ be remove is hard. Right. But the data of removing is usually specified when the code for removing already is written, or even merged in the next branch. This is true for most warnings introduced in 3.7 that warns about the removal in 3.8. This is true for Py3k warnings backported to 2.7. In short-term deprecations you have the only one release in which the warning is emitted. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Process to remove a Python feature
08.05.18 19:10, Ethan Furman пише: X.Y+1: added a deprecation warning. Many users need to support only two recent versions and can move to using the replacement now. I'm curious how you arrived at this conclusion? I know I've only worked at two different Python-using companies, but neither aggressively tracks the latest Python minor version, and as a library author I support more than the two most recent versions. Maybe I was too optimistic. ;-) Libraries need to support more Python versions of course. But two versions is a minimum, and I thing that for many applications (if they are targeted to the specific OS version or shipped with an own Python) this is enough. Even if their number is not large, they will get a benefit from introducing a replacement before adding a warning. If you support versions X.Y-1 and X.Y, you just use the old feature. If you support versions X.Y and X.Y+1, you replace it with the new feature. If you support versions X.Y-1, X.Y and X.Y+1 you need either to ignore varnings, or to add a runtime check for switching between using the old and the new feature. This complicates the code. But at least the code is clear in the first two cases. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Process to remove a Python feature
On Wed, May 9, 2018 at 2:53 AM, Serhiy Storchaka wrote: > 08.05.18 19:10, Ethan Furman пише: >>> >>> X.Y+1: added a deprecation warning. Many users need to support only two >>> recent versions and can move to using the >>> replacement now. >> >> >> I'm curious how you arrived at this conclusion? I know I've only worked >> at two different Python-using companies, but neither aggressively tracks the >> latest Python minor version, and as a library author I support more than the >> two most recent versions. > > > Maybe I was too optimistic. ;-) Libraries need to support more Python > versions of course. But two versions is a minimum, and I thing that for many > applications (if they are targeted to the specific OS version or shipped > with an own Python) this is enough. Even if their number is not large, they > will get a benefit from introducing a replacement before adding a warning. > > If you support versions X.Y-1 and X.Y, you just use the old feature. If you > support versions X.Y and X.Y+1, you replace it with the new feature. If you > support versions X.Y-1, X.Y and X.Y+1 you need either to ignore varnings, or > to add a runtime check for switching between using the old and the new > feature. This complicates the code. But at least the code is clear in the > first two cases. Here in this house, we have: * 3.8, with or without various patches as are being proposed upstream * 3.7, a slightly old alpha build, as a secondary on the laptop * 3.6 on the latest Ubuntu * 3.5 on the Raspberry Pi * 3.4 as shipped by Debian, as the laptop's primary Python 3 * And I'm not even counting the various different 2.7s. My brother and I built a TCP-managed doorbell involving the rPi. At an absolute minimum, it has to support 3.4, 3.5, and 3.6; and supporting 3.7 is important, given how close it is to release. Supporting 3.8 is no harder than supporting 3.7, but anything that did actual version number checks would need to be aware of it. So that's potentially five different versions. (Fortunately, I have all five installed on one computer, so testing isn't hard.) Supporting just two versions seems a bit too hopeful. Supporting three would be a minimum for an in-house app; and if your users run different Linux distros with different release cadences, four wouldn't be unlikely, even among current releases. As a general rule, I prefer to avoid writing "before" and "after" code. For a lot of deprecations, that's easy - when "await" started becoming a keyword, I renamed a function to "wait" [1], and it was 100% compatible with all versions. If there absolutely has to be code doing two different things, I'd rather catch ImportError than do actual version checks. But if it has to check versions, it'll need to be aware of quite a few. ChrisA [1] https://github.com/Rosuav/LetMeKnow/commit/2ecbbdcc3588139932525140ceb8c2cb66930284 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Slow down...
> On May 8, 2018, at 11:48 AM, Brett Cannon wrote: > > > >> On Tue, 8 May 2018 at 08:26 Craig Rodrigues wrote: >>> On Mon, May 7, 2018 at 2:24 PM Barry Warsaw wrote: >>> On May 7, 2018, at 11:49, Craig Rodrigues 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
Re: [Python-Dev] Slow down...
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 wrote: > > > On Sun, May 6, 2018 at 7:35 PM Nick Coghlan 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 > ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Slow down...
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Slow down...
On Mon, May 07, 2018 at 10:23:32PM +0200, Antoine Pitrou wrote:
> On Mon, 07 May 2018 19:19:28 +
> Ryan Gonzalez 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
___
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/archive%40mail-archive.com
Re: [Python-Dev] Slow down...
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Slow down...
[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?
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 :-)
___
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/archive%40mail-archive.com
Re: [Python-Dev] Slow down...
Serhiy Storchaka 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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Slow down...
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 bold, and then there would be no trouble adding new keywords. -- Greg ___ 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/archive%40mail-archive.com
