9 ms·

> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. What a load of b

by lloeki 10y ago

> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you. > Unlike 2.7 code, Python 2.8 wouldn't be able to guarantee exact 3.x compatibility, since there are some python scripts that will run under both Python 2.7 and Python 3.x but produce different output, and Python 2.8 chooses the 2.7 behavior in these cases. What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x. As for the latter, please explain how that will alleviate anything on the following point, since behaviour at runtime will be subtly different: > adding these remaining Python 3 features would greatly simplify running code targeting Python 3, and allow people to use Python 2.8 to run a mix of Python 2 and 3 code. I don't know what recourse the PSF has but maybe they should even go all in and defend the "Python" name so as to prevent confusion and stop a potential community fracture. Just call it anything else but "Python 2.8" is not Python.

staticassertion 10y ago
> What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. Except when they aren't. And then what? I've run into this multiple times. Sometimes there's a branch of the project for 3 that's underway, and I sit and wait. Other times it means dropping the project or committing to reimplementing a library.
epberry 10y ago
Yes totally agree. In the end this won't matter because the momentum of the ecosystem is so great at this point but it just baffles the mind that someone would think this is a good idea, especially with the "can't run on 2.7 or 3.x" situation.
ceronman 10y ago
> I don't know what recourse the PSF has but maybe they should even go all in and defend the "Python" name so as to prevent confusion and stop a potential community fracture. Just call it anything else but "Python 2.8" is not Python. This! A thousand times! I love open source and free software. I absolutely love the fact that you can fork the code and adapt it to your needs. If you find others who like it great! But please, don't use the Python name! It will create more confusion than help. This fork with a different name is 100% fair in my opinion.
- kibwen 10y ago
  Not only should the PSF intervene to prevent someone else from using the Python name, they legally must intervene if they wish to keep their trademark ( see http://privacyandip.blogspot.com/2011/10/common-questions-when-should-i-enforce.html http://privacyandip.blogspot.com/2011/10/common-questions-wh... ).
- marmaduke 10y ago
  contribute, then, instead of complaining: https://github.com/naftaliharris/python2.8/issues/47 https://github.com/naftaliharris/python2.8/issues/47
lima 10y ago
> I don't know what recourse the PSF has They own the Python trademark, so they can make him stop using it. In fact, I really hope that they do. This project does no good.
coldtea 10y ago
>What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you. I call BS (to counter your "bollocks"). Whether the "writing was on the wall" or not, doesn't change the fact that people had to actively port their old code if they wanted it to run on 3. Sometimes that code could run into the tens of thousands (or even millions for large companies) of lines. And why would they do it (and at a great cost and time effort)? For the marginal improvements Python 3 brings? The "writing has been on the wall" is not an excuse, it's mostly blackmail ("port or else you wont run on 3, and we'll stop the 2.x line"). And most people didn't (and shouldn't) fall for that.
- metaobject 10y ago
  We have several large projects that are written in Python. Most of these aee production applications that are critical to what we do, and the others are libraries and tools for internal work. We haven't even started thinking about porting these to python3. We have so many other things to worry about (but fixes, new features, etc) that it's hard to justify the time investment to port these now. I can't imagine we're the only ones in this situation.
  - int_19h 10y ago
    You're not, of course. And there are similarly many people running production critical code written in Perl 5 on RedHat 9 or something like that. "If it's not broken, don't touch it" is a wise rule to follow for that kind of stuff. But to keep it running, you don't really need Python 2.8 with new features, right? You need extended support for Python 2.7 - basically, making sure that it keeps working with updated versions of other software (like OSes), and that bugs are fixed.
    - coldtea 10y ago
smoyer 10y ago
I came here to say exactly this ... you're better off upgrading your systems as you can. There's one point missing above - do you really want to use a version of Python that's maintained by one person and of unknown quality? You're better off staying on 2.7 if you can't afford to upgrade.
susan_hall 10y ago
I currently work for a client who has decided to shift away from PHP and towards Python. They had a monolithic PHP app with perhaps 250,000 lines of code. Now we are developing a series of Python apps in the microservices style. We've decided to develop everything as Python 2.7. We are not looking at Python 3.x. There are a few reasons. Some libraries that we want are in Python 2.7. And Amazon only supports 2.7. And we are not wild about Python 3.x's attempt to imitate a classical object oriented style. We would look very closely at a Python 2.8, if it existed.
- vosper 10y ago
  If I was your client I'd be pissed that you decided to rewrite my code into a legacy version of Python. Make no mistake: Python 3 is the future of Python. There will be no version 2.8 and there is no going back to 2.7. Also, I don't know what you mean by "Amazon only supports 2.7" because boto (the main client for Python) has supported Python 3 for 2 years now. Perhaps you mean Lambda?
  - hayd 10y ago
    +1. Also it's easy to write code that supports both, so if you really need python 2 support right now (surely AWS Lambda python 3 is coming soon, you can already use it unofficially) that's a much better option than being entrenched in python 2 (mainly the string handling is the issue for buggy code that'll run in 2 but not 3).
  - paulddraper 10y ago
    He means Lambda.
- jayflux 10y ago
  Could you tell us which libraries you want don't support 3.x? Genuinely curious as i thought nearly all of the main ones were ported now
  - drewrv 10y ago
    At this point, if a library I wanted to use didn't support 3.X, I would take that as a giant red flag not to use said library.
hartator 10y ago
I think after 5 years we should came to the realization that Python 3.x is not the future of Python. You can't blame people to try to find solution.
- jimnotgym 10y ago
  Except it kinda is the current version to lots of us. I moved to Python as a hobbyist from .net languages and loved the freedom of not having an IDE and working with Linux. The first decent book I read was on Python 3 so I learned Python 3. Lots of us 'newcomers' (not so new in my case) learnt on Python 3, find perfectly good library support in Python 3. In fact the 'old guard', sound a bit like my Dad talking about how old cars or pre decimal currency to me. I just don't find myself hitting problems I can't solve on Python 3, that I could have solved under Python 2. To be fair I have a pretty minimal amount of code in production, but in each case it is not so monolithic that I couldn't have some of it using Python 2 and some using Python 3 or even some other language for that matter. Python 3 is not only the future but the current version of Python. It is the version kids learn in School (in the UK kids do some CS from the age of 6 or 7, starting on scratch and then normally Python), it is the version colleges teach. However there are lots of reasons enterprise users may want to use a legacy codebase. It is not like Python 2.7 is about to stop working! When a section needs a major re-write, then consider porting it. I don't see how this is different to any obsolescence problem. I know an enterprise software company that wrote a lot of stuff in VB6. Some of it is still in VB6 and they have to manage everything that means (especially around 64 bit architecture problems), when they do major updates they use .net. How can we be in the technology game and not just except that life moves on!
  - int_19h 10y ago
    It's worth noting that Microsoft is still keeping VB6 on life support, in a sense. The tooling is not guaranteed to work on modern OSes (and there is a bunch of actual breakage, although community has found workarounds so far). But the runtime is still supported - in fact, it ships with the OS! If you have any non-ARM version of Windows, up to and including Win10, around, check the file named msvbvm60.dll in C:\Windows\SysWOW64 - that's it ("MS VB VM"). And because it ships as an OS component, the official support policy is the same as the rest of the OS, which is at least 5 years of mainstream support (longer if there's no successor release), and then at least 5 years of extended support. This is even clarified specifically for VB6: https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx Since VB6 was first released in 1998, this marks 18 years of continued support to date; and if it's not dropped from the OS within the next 2 years, it has a chance of hitting 30 years... For what it's worth, PSF also has a fairly generous (especially for a non-commercial OSS project) support policy for Python 2.7 - it had already extended the end-of-life date for it once to 2020: https://www.python.org/dev/peps/pep-0373/#id2 https://www.python.org/dev/peps/pep-0373/#id2
ianamartin 10y ago
The Python Software Foundation has an obligation to defend the trade name. If it fails to exercise it, then it can be denied in the future. I don't expect litigation because that's not how the community rolls. I expect a polite message from gvr to the author asking to change the name. If that fails, the PSF has no choice. It's use it or lose it.
- cygx 10y ago
  If that fails, the PSF has no choice. It's use it or lose it. Or license it.
- rajathagasthya 10y ago
  > I expect a polite message from gvr to the author asking to change the name. And he has - https://github.com/naftaliharris/python2.8/issues/47#issuecomment-266218423 https://github.com/naftaliharris/python2.8/issues/47#issueco...
dismantlethesun 10y ago
> What a load of bollocks. [Snip] For old projects, either you're in a situation where you can spend time porting your code to Python 3 The majority of Python code is old projects, just like every other established language. This might change in the future as I now see people starting new projects in Python 3, but if your company is older than 5 years old, then there is a good chance that you started with Python 2 simply because at the time of creating your codebase a whole lot of libraries weren't ported to Python 3.
ChuckMcM 10y ago
And this captures the good and the bad of open source all so succinctly. Here we have a person (the author) who has rejected the path that an open source project has taken, and invested the time and energy to move the source along a path they prefer. In this particular case, there is a natural constituency of people who share that desire but are unable or unwilling to put in the effort to push the source down the path. When there is critical mass, that group forks off and begins to bring other people along to the alternate path. At that point the people who endorsed the change in direction come out in force to yell at these people who aren't doing what they are supposed to and threaten them and implore a higher power to emasculate their effort. Sometimes that works, sometimes it doesn't. But it always results in massive amounts of confusion when someone new comes to the community and sees these two different paths for the same thing and can't really figure out why they are different. Further because there is no mechanism for "righting" the ship as it were, the diverging paths lead to a lot of wasted time and effort on everyone's part. This happens to be a Python fork but its happened to window systems, video codecs, graphics libraries, data bases, hell even C compilers. The nice thing about a Cathedral is that the Pope keeps the Cardinals toeing the one and only line. Reminds me a lot of the Perl 5 / Perl 6 debates.
e98cuenc 10y ago
That has been official since 2011, but even today you may need some lib only available in Python 2.x and thus may need to start a new project in 2.7. I started several python projects since 2011 knowing that it was a dead end, but my hands were tied. At the time there was not even a working wsgi spec, and no web frameworks for 3.x, and the first ones has an awful performance (2.7 is bad enough). Only recently 3.x has become a viable alternative. I for one welcome this 2.8 fork.
upofadown 10y ago
well Python 3 itself was a version hijack so it might be a little late to complain about others doing the same thing.
greyman 10y ago
> What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x. I don't say you are wrong, but I am afraid this situation looks "terrible" only to people who do care about 3. If someone doesn't care about it and thinks that he can survive with never porting to 3 or start using it, for those people the situation isn't that terrible...from that perspective, his 2.7 language evolved to next step, and he know that new features can be used if he upgrades from 2.7 to 2.8.
dagss 10y ago
Software typically evolves and grows and changes over decades. There very often isn't any point where you can go "for our next project we choose X". Each new project is a feature using 90% of some existing huge codebase. "Starting fresh" is something many (most?) companies simply never does, over decades. (And if they attempt it is often an all out disaster..) 2011 is fairly recent in this context, and many popular libraries were not available on Py3 until much more recent than that, even if you have the rare luxury of starting fresh.
jl6 10y ago
Name suggestion: Pythoff.
- isotropy 10y ago
  Pythed-off.
VanL 10y ago
(Replying to the top-ranked comment so that as many people as possible see it) While I wish Naftali well in his efforts - I have a private Python-derived language myself! - this is not "Python 2.8." For trademark purposes, "Python" is only what is released or endorsed by the PSF. We have already reached out to Naftali and asked him to change the name of his project and update this blog post accordingly. Obviously, though, this is someone who cares a lot about Python, so let's be sure not to rain down on him with a lot of scorn; I admire that he was willing to sit down and 'scratch his own itch.' Source: I am the General Counsel of the PSF.
- Redoubts 10y ago
  "I don't mind renaming this project. Any other suggestions for good names? I personally like "Pythonesque (/usr/bin/pesque)" the best so far, thanks @dbohdan! :-)" - The Author (who isn't me) https://github.com/naftaliharris/python2.8/issues/47#issuecomment-266240525
- BuckRogers 10y ago
  Scorn? He's doing the CPython maintainer's job for them. He should be universally praised.
naftaliharris 10y ago
> the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you. When Python 3 was released, it offered Python users a trade: In exchange for a productivity loss (porting your Python 2 code), you'd get a productivity gain (new features in Python 3 and removed cruft). Some projects and companies thought this was a good trade, and have upgraded over the years, and many have not, and haven't. The interpreter I've been working on tries to improve on the terms of that deal for people who have not switched to Python 3. > What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x. That's the point, yes. Obviously any interpreter that's backwards compatible with 2.7 but includes new features from 3.x is going to let people write code that doesn't run under 2.7 or 3.x. But what does it matter if your code doesn't run under interpreters that you aren't using and don't intend to use? > Just call it anything else I'll change the name.
- BuckRogers 10y ago
  There's a lot of good names based on Monty Python properties, but I like "Cobra", starting at version 2.8. Ignoring the MP stuff and going for something on the snake theme.

by lloeki 10y ago

staticassertion 10y ago

> What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. Except when they aren't. And then what? I've run into this multiple times. Sometimes there's a branch of the project for 3 that's underway, and I sit and wait. Other times it means dropping the project or committing to reimplementing a library.

epberry 10y ago

Yes totally agree. In the end this won't matter because the momentum of the ecosystem is so great at this point but it just baffles the mind that someone would think this is a good idea, especially with the "can't run on 2.7 or 3.x" situation.

ceronman 10y ago

> I don't know what recourse the PSF has but maybe they should even go all in and defend the "Python" name so as to prevent confusion and stop a potential community fracture. Just call it anything else but "Python 2.8" is not Python. This! A thousand times! I love open source and free software. I absolutely love the fact that you can fork the code and adapt it to your needs. If you find others who like it great! But please, don't use the Python name! It will create more confusion than help. This fork with a different name is 100% fair in my opinion.

kibwen 10y ago
Not only should the PSF intervene to prevent someone else from using the Python name, they legally must intervene if they wish to keep their trademark ( see http://privacyandip.blogspot.com/2011/10/common-questions-when-should-i-enforce.html http://privacyandip.blogspot.com/2011/10/common-questions-wh... ).
marmaduke 10y ago
contribute, then, instead of complaining: https://github.com/naftaliharris/python2.8/issues/47 https://github.com/naftaliharris/python2.8/issues/47

lima 10y ago

> I don't know what recourse the PSF has They own the Python trademark, so they can make him stop using it. In fact, I really hope that they do. This project does no good.

coldtea 10y ago

>What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you. I call BS (to counter your "bollocks"). Whether the "writing was on the wall" or not, doesn't change the fact that people had to actively port their old code if they wanted it to run on 3. Sometimes that code could run into the tens of thousands (or even millions for large companies) of lines. And why would they do it (and at a great cost and time effort)? For the marginal improvements Python 3 brings? The "writing has been on the wall" is not an excuse, it's mostly blackmail ("port or else you wont run on 3, and we'll stop the 2.x line"). And most people didn't (and shouldn't) fall for that.

metaobject 10y ago
We have several large projects that are written in Python. Most of these aee production applications that are critical to what we do, and the others are libraries and tools for internal work. We haven't even started thinking about porting these to python3. We have so many other things to worry about (but fixes, new features, etc) that it's hard to justify the time investment to port these now. I can't imagine we're the only ones in this situation.
- int_19h 10y ago
  You're not, of course. And there are similarly many people running production critical code written in Perl 5 on RedHat 9 or something like that. "If it's not broken, don't touch it" is a wise rule to follow for that kind of stuff. But to keep it running, you don't really need Python 2.8 with new features, right? You need extended support for Python 2.7 - basically, making sure that it keeps working with updated versions of other software (like OSes), and that bugs are fixed.
  - coldtea 10y ago

smoyer 10y ago

I came here to say exactly this ... you're better off upgrading your systems as you can. There's one point missing above - do you really want to use a version of Python that's maintained by one person and of unknown quality? You're better off staying on 2.7 if you can't afford to upgrade.

susan_hall 10y ago

I currently work for a client who has decided to shift away from PHP and towards Python. They had a monolithic PHP app with perhaps 250,000 lines of code. Now we are developing a series of Python apps in the microservices style. We've decided to develop everything as Python 2.7. We are not looking at Python 3.x. There are a few reasons. Some libraries that we want are in Python 2.7. And Amazon only supports 2.7. And we are not wild about Python 3.x's attempt to imitate a classical object oriented style. We would look very closely at a Python 2.8, if it existed.

vosper 10y ago
If I was your client I'd be pissed that you decided to rewrite my code into a legacy version of Python. Make no mistake: Python 3 is the future of Python. There will be no version 2.8 and there is no going back to 2.7. Also, I don't know what you mean by "Amazon only supports 2.7" because boto (the main client for Python) has supported Python 3 for 2 years now. Perhaps you mean Lambda?
- hayd 10y ago
  +1. Also it's easy to write code that supports both, so if you really need python 2 support right now (surely AWS Lambda python 3 is coming soon, you can already use it unofficially) that's a much better option than being entrenched in python 2 (mainly the string handling is the issue for buggy code that'll run in 2 but not 3).
- paulddraper 10y ago
  He means Lambda.
jayflux 10y ago
Could you tell us which libraries you want don't support 3.x? Genuinely curious as i thought nearly all of the main ones were ported now
- drewrv 10y ago
  At this point, if a library I wanted to use didn't support 3.X, I would take that as a giant red flag not to use said library.

hartator 10y ago

I think after 5 years we should came to the realization that Python 3.x is not the future of Python. You can't blame people to try to find solution.

jimnotgym 10y ago
Except it kinda is the current version to lots of us. I moved to Python as a hobbyist from .net languages and loved the freedom of not having an IDE and working with Linux. The first decent book I read was on Python 3 so I learned Python 3. Lots of us 'newcomers' (not so new in my case) learnt on Python 3, find perfectly good library support in Python 3. In fact the 'old guard', sound a bit like my Dad talking about how old cars or pre decimal currency to me. I just don't find myself hitting problems I can't solve on Python 3, that I could have solved under Python 2. To be fair I have a pretty minimal amount of code in production, but in each case it is not so monolithic that I couldn't have some of it using Python 2 and some using Python 3 or even some other language for that matter. Python 3 is not only the future but the current version of Python. It is the version kids learn in School (in the UK kids do some CS from the age of 6 or 7, starting on scratch and then normally Python), it is the version colleges teach. However there are lots of reasons enterprise users may want to use a legacy codebase. It is not like Python 2.7 is about to stop working! When a section needs a major re-write, then consider porting it. I don't see how this is different to any obsolescence problem. I know an enterprise software company that wrote a lot of stuff in VB6. Some of it is still in VB6 and they have to manage everything that means (especially around 64 bit architecture problems), when they do major updates they use .net. How can we be in the technology game and not just except that life moves on!
- int_19h 10y ago
  It's worth noting that Microsoft is still keeping VB6 on life support, in a sense. The tooling is not guaranteed to work on modern OSes (and there is a bunch of actual breakage, although community has found workarounds so far). But the runtime is still supported - in fact, it ships with the OS! If you have any non-ARM version of Windows, up to and including Win10, around, check the file named msvbvm60.dll in C:\Windows\SysWOW64 - that's it ("MS VB VM"). And because it ships as an OS component, the official support policy is the same as the rest of the OS, which is at least 5 years of mainstream support (longer if there's no successor release), and then at least 5 years of extended support. This is even clarified specifically for VB6: https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx Since VB6 was first released in 1998, this marks 18 years of continued support to date; and if it's not dropped from the OS within the next 2 years, it has a chance of hitting 30 years... For what it's worth, PSF also has a fairly generous (especially for a non-commercial OSS project) support policy for Python 2.7 - it had already extended the end-of-life date for it once to 2020: https://www.python.org/dev/peps/pep-0373/#id2 https://www.python.org/dev/peps/pep-0373/#id2

ianamartin 10y ago

The Python Software Foundation has an obligation to defend the trade name. If it fails to exercise it, then it can be denied in the future. I don't expect litigation because that's not how the community rolls. I expect a polite message from gvr to the author asking to change the name. If that fails, the PSF has no choice. It's use it or lose it.

cygx 10y ago
If that fails, the PSF has no choice. It's use it or lose it. Or license it.
rajathagasthya 10y ago
> I expect a polite message from gvr to the author asking to change the name. And he has - https://github.com/naftaliharris/python2.8/issues/47#issuecomment-266218423 https://github.com/naftaliharris/python2.8/issues/47#issueco...

dismantlethesun 10y ago

> What a load of bollocks. [Snip] For old projects, either you're in a situation where you can spend time porting your code to Python 3 The majority of Python code is old projects, just like every other established language. This might change in the future as I now see people starting new projects in Python 3, but if your company is older than 5 years old, then there is a good chance that you started with Python 2 simply because at the time of creating your codebase a whole lot of libraries weren't ported to Python 3.

ChuckMcM 10y ago

And this captures the good and the bad of open source all so succinctly. Here we have a person (the author) who has rejected the path that an open source project has taken, and invested the time and energy to move the source along a path they prefer. In this particular case, there is a natural constituency of people who share that desire but are unable or unwilling to put in the effort to push the source down the path. When there is critical mass, that group forks off and begins to bring other people along to the alternate path. At that point the people who endorsed the change in direction come out in force to yell at these people who aren't doing what they are supposed to and threaten them and implore a higher power to emasculate their effort. Sometimes that works, sometimes it doesn't. But it always results in massive amounts of confusion when someone new comes to the community and sees these two different paths for the same thing and can't really figure out why they are different. Further because there is no mechanism for "righting" the ship as it were, the diverging paths lead to a lot of wasted time and effort on everyone's part. This happens to be a Python fork but its happened to window systems, video codecs, graphics libraries, data bases, hell even C compilers. The nice thing about a Cathedral is that the Pope keeps the Cardinals toeing the one and only line. Reminds me a lot of the Perl 5 / Perl 6 debates.

e98cuenc 10y ago

That has been official since 2011, but even today you may need some lib only available in Python 2.x and thus may need to start a new project in 2.7. I started several python projects since 2011 knowing that it was a dead end, but my hands were tied. At the time there was not even a working wsgi spec, and no web frameworks for 3.x, and the first ones has an awful performance (2.7 is bad enough). Only recently 3.x has become a viable alternative. I for one welcome this 2.8 fork.

upofadown 10y ago

well Python 3 itself was a version hijack so it might be a little late to complain about others doing the same thing.

greyman 10y ago

> What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x. I don't say you are wrong, but I am afraid this situation looks "terrible" only to people who do care about 3. If someone doesn't care about it and thinks that he can survive with never porting to 3 or start using it, for those people the situation isn't that terrible...from that perspective, his 2.7 language evolved to next step, and he know that new features can be used if he upgrades from 2.7 to 2.8.

dagss 10y ago

Software typically evolves and grows and changes over decades. There very often isn't any point where you can go "for our next project we choose X". Each new project is a feature using 90% of some existing huge codebase. "Starting fresh" is something many (most?) companies simply never does, over decades. (And if they attempt it is often an all out disaster..) 2011 is fairly recent in this context, and many popular libraries were not available on Py3 until much more recent than that, even if you have the rare luxury of starting fresh.

jl6 10y ago

Name suggestion: Pythoff.

isotropy 10y ago
Pythed-off.

VanL 10y ago

(Replying to the top-ranked comment so that as many people as possible see it) While I wish Naftali well in his efforts - I have a private Python-derived language myself! - this is not "Python 2.8." For trademark purposes, "Python" is only what is released or endorsed by the PSF. We have already reached out to Naftali and asked him to change the name of his project and update this blog post accordingly. Obviously, though, this is someone who cares a lot about Python, so let's be sure not to rain down on him with a lot of scorn; I admire that he was willing to sit down and 'scratch his own itch.' Source: I am the General Counsel of the PSF.

Redoubts 10y ago
"I don't mind renaming this project. Any other suggestions for good names? I personally like "Pythonesque (/usr/bin/pesque)" the best so far, thanks @dbohdan! :-)" - The Author (who isn't me) https://github.com/naftaliharris/python2.8/issues/47#issuecomment-266240525
BuckRogers 10y ago
Scorn? He's doing the CPython maintainer's job for them. He should be universally praised.

naftaliharris 10y ago

> the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you. When Python 3 was released, it offered Python users a trade: In exchange for a productivity loss (porting your Python 2 code), you'd get a productivity gain (new features in Python 3 and removed cruft). Some projects and companies thought this was a good trade, and have upgraded over the years, and many have not, and haven't. The interpreter I've been working on tries to improve on the terms of that deal for people who have not switched to Python 3. > What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x. That's the point, yes. Obviously any interpreter that's backwards compatible with 2.7 but includes new features from 3.x is going to let people write code that doesn't run under 2.7 or 3.x. But what does it matter if your code doesn't run under interpreters that you aren't using and don't intend to use? > Just call it anything else I'll change the name.

BuckRogers 10y ago
There's a lot of good names based on Monty Python properties, but I like "Cobra", starting at version 2.8. Ignoring the MP stuff and going for something on the snake theme.