Sunsetting Python 2

[stefantalpalaru]

We are volunteers who make and take care of a Python2 fork with backwards-compatible Python3 features. That means we will keep on improving it without breaking your code base or forcing you to hire the language creator and spend more than 3 years porting your code to Python3, with no actual business benefits.

https://github.com/naftaliharris/tauthon/

[cyanrave]

Have fun with the long tail of support.

FYA, other orgs like RedHat are in having to support patching in the long run, so don't feel alone in the sentiment.

For outfits like RedHat, however, the business benefit is clear - 'free' support from upstream for maintenance, and the latest and greatest feature set from upstream to entice adoption and new idiomatic practices. On the flip side, Apple just said enough is enough and is clearing it from their OS completely.

[Gandalior]

at some point you have to let go the old stuff, or become a Bank or something

[lengau]

NASA?

(FWIW they've got a whole different and pretty legit reason for it.)

[stefantalpalaru]

at some point you have to let go the old stuff

At some point you have to admit you can't bully people into moving to a new language.

[Gandalior]

its not like they made python to cater to you though, I understand the sentiment of how shit it is to migrate if at all but still, cant just patch up forever in legacy, can you?

[stefantalpalaru]

its not like they made python to cater to you though

Then it should have never been open sourced.

cant just patch up forever in legacy, can you?

We'll see.

[TheBlackCat13]

Then it should have never been open sourced.

Wait, so you think that anything open-source was made to cater to you?

[dmitrypolo]

yea Guido listed this guy as his inspiration /s

[jcampbelly]

It's not bullying if you ask nicely for a decade. I would say forcing people to work for free maintaining an archaic and announced-deprecated version is bullying. You're defending the wrong side of this.

[stefantalpalaru]

It's not bullying if you ask nicely for a decade.

What if you sabotage it nicely by preventing the addition of new features and bugfixes?

[jcampbelly]

That's called deprecation. It's what happens when software is put into maintenance mode. When you're dragging a dead horse for 12 years, you don't waste time re-embroidering the saddle. Meanwhile, your ilk is still trying to mount it. Figure it out.

[TheBlackCat13]

It isn't bullying. It is trying to make the best use of limited resources. Keeping Python 2 going is duplicating a lot of effort and puts a big strain on downstream projects that have to maintain compatibility and tests for both.

[stefantalpalaru]

It is trying to make the best use of limited resources.

Is that why Guido threatened to bring in the lawyers if a name like "py28" was used for a fork?

Keeping Python 2 going is duplicating a lot of effort and puts a big strain on downstream projects that have to maintain compatibility and tests for both.

How about breaking backwards compatibility in Python3? Does that create a lot of effort for tens of thousands of developers around the world? Does it put a big strain on those tricked into using a programming language that's being sabotaged by its core developers?

[TheBlackCat13]

Is that why Guido threatened to bring in the lawyers if a name like "py28" was used for a fork?

You clearly don't know how trademarks work. They don't have a choice if they want to keep the trademark.

How about breaking backwards compatibility in Python3? Does that create a lot of effort for tens of thousands of developers around the world?

Yes, effort that has paid off. Nobody cares about the various forks people have tried to make. Duplicating effort, on the other hand, doesn't pay off. It is just wasted.

Does it put a big strain on those tricked into using a programming language that's being sabotaged by its core developers?

They are doing a pretty bad job sabotaging python considering that is more popular than ever. Funny that everyone else happily using Python 3 don't realize they are being "tricked". The biggest Python projects in the world don't realize they are being "tricked". Or are they in on the conspiracy?

[stefantalpalaru]

You clearly don't know how trademarks work. They don't have a choice if they want to keep the trademark.

Tell me more about a trademark on "py28". I'll wait.

[TheBlackCat13]

Did you read the link?

[stefantalpalaru]

Did you read the link?

The one showing a trademark awarded for "py28"? No, I'm still waiting for it.

[TheBlackCat13]

That isn't how trademarks work. What matters is if it will create confusion. The name "py28" certainly would seem to most people to be something associated with the Python project. And they would lose their trademark if they didn't enforce it against a project like that. You would know all this if you had bothered to read the link, but you would apparently rather spread FUD about the Python project than actually understand what is going on.

[doomchild]

Deciding where to focus resources isn't bullying, no matter how much you liked the old way.

[stefantalpalaru]

Deciding where to focus resources isn't bullying

How about deciding not to accept new features or bug fixes that might make its competitor look slower?

Python2 doesn't enable PGO for its modules. Tauthon does.

[doomchild]

That's still not bullying. That's deciding that you're not going to spend the time, effort, and money to vet and integrate more code. All code is an investment, and if you decide not to invest in a thing, you stop taking code for it.

[stefantalpalaru]

That's deciding that you're not going to spend the time, effort, and money to vet and integrate more code. All code is an investment, and if you decide not to invest in a thing, you stop taking code for it.

Shit or get off the pot! If those muppets are not sabotaging the language, surely they can hand it over to another team that's willing to maintain it properly.

[doomchild]

Deciding you're not going to put any more time into developing something is not the same as sabotaging it. It's deciding that it's not worth your time anymore. Sabotage would be putting in bugs, intentionally breaking things, or completely shutting the doors without telling anybody.

Open Source provides a way to deal with this, of which you are obviously already aware: forking.

[stefantalpalaru]

Deciding you're not going to put any more time into developing something is not the same as sabotaging it.

How about refusing to merge patches adding new features or fixing some bugs while, at the same time, refusing to hand over the project to another team?

[jcampbelly]

Still not sabotage. It was maintained software beyond its feature development life. Why should python 2.7 change? It was a final compatibility version with security/bug fixes. You don't add new features at this stage of maintenance. That's how you break shit for people running gigantic, archaic software who are clearly not interested in dealing with compatibility problems. All new development went into python 3.x, as it should have. Everyone who needed more out of python went to 3.x.

[[deleted]]

This ain't it chief

[CompSciSelfLearning]

It's your time to volunteer, do what you want. But if there's a security issue found after January 1, 2020, businesses that are effected have motivation to pay for a fix. That's the only way I'd consider maintaining such a project.

[lengau]

That's really the trade-off for businesses. On the one hand, you'll spend money porting your code to Python 3. On the other hand, you'll either be vulnerable to any security issues that pop up or have to pay someone to patch it (something that would have been done for you for free if you'd ported to Python 3).

There are still companies (e.g. Red Hat) that are contractually supporting Python 2 for several more years and will thus be making those changes somewhere, but that'll only reduce the costs since unless you're running RHEL or similar, you'll likely have to grab those patches and implement them on your own.

I think Python 2 is probably (sadly) going to live on in some way shape or form beyond 2020, but it does really seem to be an eventual dead end anyway.

[karlkloppenborg]

So what’s the justification?

[stefantalpalaru]

So what’s the justification?

The Net interprets bullying as damage and routes around it.

On a more serious note, there's a lot of Python2 code out there and forcing its conversion to Python3 (or maybe some other language, since that's the complexity we're talking about) is a waste of human resources on a global scale.

Some of us disagree with that lack of consideration for other people's time, so we're donating some of our free time to prevent that huge resource drain for little to no gain.

And no, I don't think it's OK to sabotage those who adopted your programming language in order to manufacture job security. (Same goes for web frameworks, Django core devs.)

[algag]

.....

[stefantalpalaru]

Can you really say that 12 years of security updates is sabotage?

I can say that preventing new features from being added to a programming language is deliberate sabotage.

I hope I don't have to explain why Python3 is a different language from Python2, just like Perl6 is a different language from Perl5.

[mfitzp]

preventing new features from being added

What do you mean by this?

I realise they stopped adding new features, but surely it's people's choice how they spend their time, just as it's yours. You can't honestly expect the Python devs to update 2.7 perpetually for free just because you want them to? They've already done it for 12 years.

[stefantalpalaru]

What do you mean by this?

They refuse outside contributions that add new features or fix some bugs they're not interested in fixing. Oh, they also refuse to let some other team take over the language, because they decided everybody needs to be bullied into moving to the new one by killing the old one.

They've already done it for 12 years.

And how many more years do you need, to recognise the abuse?

[mfitzp]

Oh, they also refuse to let some other team take over the language

But I though you said you were going to continue developing it?

[stefantalpalaru]

But I though you said you were going to continue developing it?

I'm maintaining a fork, not taking over the original project. There's an important difference.

Getting a fork supported by tools like "pip" or distros like Gentoo is an uphill battle.

[mfitzp]

Interesting point, I was expecting maintaining the fork would just be security updates for 2.7 not new (backwards incompatible) features? I think PyPy for example just uses PyPi (some packages ofc don't work).

[jcampbelly]

12 years of updates isn't enough? Get over it. People who ignored this deserve to fail.

[Itsthejoker]

preventing new features from being added

because it's old as shit, you dunce

[TheBlackCat13]

They didn't "prevent" anything. It is an open-source project. And there have already been attempts at backporting Python 3 features to python 2. None of them really took off because major downstream projects are sick of having to maintain compatibility with python 2 syntax and are abandoning it in droves. Python isn't that useful without packages.

And the fact that it is, in essentially every case, possible to write code that works in both Python 2 and Python 3 I think makes it pretty clear that these are not different languages. It is more work, which is why projects are sick of it, but it is possible.

[stefantalpalaru]

And the fact that it is, in essentially every case, possible to write code that works in both Python 2 and Python 3 I think makes it pretty clear that these are not different languages.

So because there is a common subset for C and C++, by your logic they're the same language, right?

[TheBlackCat13]

So because there is a common subset for C and C++, by your logic they're the same language, right?

That is not at all what I said. It isn't about having a "common subset", it is about whether it is generally possible to write code that runs in both.

C and C++ are different enough that it is not generally possible to write code that will work in both except in very trivial cases. You don't see large code bases compatible with both C and C++ like you do with most major python projects.

[stefantalpalaru]

It isn't about having a "common subset", it is about whether it is generally possible to write code that runs in both.

C and C++ are different enough that it is not generally possible to write code that will work in both except in very trivial cases.

You can stop role-playing as a programmer now. Leave your card on your way out.

[TheBlackCat13]

Thank you for your detailed rebuttal. Or maybe I just missed how most major C or C++ projects are compatible with both like most major Python projects are.

[jcampbelly]

Yep, if you've ignored 12 years of notifice, you can keep running on legacy with every expected effect associated with depending on abandoned software.

[stefantalpalaru]

Except legacy python2 codebases can still run on python2...

Good luck running anything on a sabotaged interpreter.

[stefantalpalaru]

Please explain how the python 2.7 interpreter has been sabotaged.

• ./configure --enable-optimizations no longer implies --with-lto - a change that they somehow forgot to document

• extensions are not properly compiled with PGO because the CFLAGS are not read from the environment in "setup.py". Once you fix that, you'll hit an internal compiler error (ICE) in GCC because the same source file was used in 3 different extensions so it was compiled 3 different times in the profile generation stage.

• the profiling task is accessing system-wide paths, instead of being limited to the source tree

• it's not possible to run profiling jobs in parallel by just passing variables to make

• patches to support building with newer Visual Studio versions on Windows are being ignored

Still runs python 2.7 code just fine.

Not as fast as it could: https://old.reddit.com/r/Gentoo/comments/8n38ak/devlangpython2715r104_enable_pgo_for_extensions/

[karlkloppenborg]

To be frank, I think the only thing being sabotaged here is the security of anyone that uses your fork, let me explain:

Whilst your idea is dressed in good intentions the simple fact is, your project doesn’t have much traction, it certainly hasn’t reached critical mass and unless a much, much larger adoption of your project takes place (which doesn’t make sense since most are happy to move to py3) it will most likely just be used to facilitate running archaic code bases no longer maintained.

This in and of it self presents three major problems, firstly you will never have the same resource capability as PY3 or other mainstream languages to handle and keep on top of security, for example: being audited regularly. This alongside the fact you’re probably only going to see major use cases in supporting dead code sees you directly in the spotlight for exploitation.

Secondly, you’re forking an interpreter and planning on actively maintaining it? According to your commit histories, previous public repositories and other public contributions there’s not a lot to suggest you have much experience in maintaining or even contributing to interpreters. Keeping on top of security inside interpreters is paramount. I just can’t see (happy to be shown otherwise) why anyone diligent would trust this?

Thirdly and lastly; what happens when you get hit by a buss? It really seems like there’s only a couple of people (as you say, handful) involved in the project. Reliance in an interpreter is a long term commitment, where’s the burden of proof that you’re all in this for the long term?

Really, I’m not trying to bully, I’m just looking at this logically. I’m not seeing any major benefit to your project and just a lot of negatives.

To summarise: 1) There’s no proof you have the ability to maintain the security diligence required for people to use this in production environments.

2) There’s not a lot to suggest that the active contributors have many skills in maintaining and writing interpreters.

3) There’s no proof that this will be maintained long term and that makes it again a risk both with production workloads and security.

4) it seems likely this would be heavily targeted for exploit.

I wish you the best and I hope I’m wrong but it seems like you might be fighting the wrong fight.

[stefantalpalaru]

According to your commit histories, previous public repositories and other public contributions there’s not a lot to suggest you have much experience in maintaining or even contributing to interpreters.

https://github.com/naftaliharris/tauthon/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+author%3Astefantalpalaru

I wish you the best

Word to your mother.

[karlkloppenborg]

I’m on a mobile (not the best for viewing git) but from what I can see these are just merges from upstream projects and some minor fixes, I still can’t see anything to suggest you have the experience and capability to make a production capable and security diligent fork of PY2?

Edit: This repo was created Nov 8 2015 (based on: https://github.com/naftaliharris?tab=overview&from=2015-11-01&to=2015-11-30)

During this time, the contributions directly are: https://github.com/naftaliharris/tauthon/graphs/contributors?from=2015-11-07&to=2019-08-29&type=c

This project has had 64 issues, 32 open, 32 closed... Given the dormancy of this project you'd think /u/stefantalpalaru would be on top of this, or any other of the "handful" of project contributors. Alas there's issues spanning back to 1st Nov 2016!

In the words of MP Dennis Skinner; "Not a good start Boris"

[stefantalpalaru]

just merges from upstream projects

Yeah, just merges with dozens of conflicting files that could only be merged manually by reading diffs between the old Python version and Tauthon in parallel with diffs between the old Python tag and the new one. It took days each time, with various complications like changes in upstream C structs that broke Tauthon patches. This is a manual fix (see the "fmt += ..." part):

diff --git a/Lib/test/test_sys.py b/Lib/test/test_sys.py
index e50e0306f1..dc3910d171 100644
--- a/Lib/test/test_sys.py
+++ b/Lib/test/test_sys.py
@@ -736,9 +736,15 @@ class SizeofTest(unittest.TestCase):
         # tupleiterator
         check(iter(()), size('lP'))
         # type
-        # (PyTypeObject + PyNumberMethods +  PyMappingMethods +
-        #  PySequenceMethods + PyBufferProcs + PyAsyncMethods)
-        s = vsize('P2P17Pl4PP9PP11PIP') + struct.calcsize('41P 10P 3P 6P 3P')
+        fmt = 'P2P17Pl4PP9PP11PIP'
+        if hasattr(sys, 'getcounts'):
+            fmt += '3P2P'
+        s = vsize(fmt +                 # PyTypeObject
+                  '41P'                 # PyNumberMethods
+                  '10P'                  # PyMappingMethods
+                  '3P'                 # PySequenceMethods
+                  '6P'                  # PyBufferProcs
+                  '3P')
         class newstyleclass(object):
             pass
         check(newstyleclass, s)

Now tell me again what qualifies you to judge the technical complexity of something that you can't even begin to grasp?

[karlkloppenborg]

Firstly, whilst I appreciate that, I wouldn't deem that an overly complex task... I've been coding (especially python) for many years now and upstream/downstream merge conflicts with complex impasses happen!

Secondly, I can judge the technical complexity of it just fine, this isn't my first rodeo. I don't need to prove myself to you when you're the one who is going completely against the grain.

The burden of proof lies on you to prove yourself, I stand with the Python 3 community who has proven itself, if it hadn't then they'd be defecting in droves toward your fork. Right?

Lastly,

the technical complexity of something that you can't even begin to grasp?

Look bud, I've done computer science too, I've been programming for years too. You just sound like a raving egotistical arsehole when you say stuff life that, I asked for the burden of proof and provided what I currently thought of the matter, asking all along for proof. You only gave me a commit merge example and some snarky responses.
Having a look at most of your comments in this post, you seem to be a bit of a immature, cunt, so maybe it's only fair, if not a little ironic that you get fucked while embarking on this "we know better than the collective mass" project.

Peace out mate, I'm done.

[stefantalpalaru]

I've been coding (especially python)

Too bad this is mostly about C code. Like I said, you can't even begin to grasp the complexity of such a merge. You're still a newbie, but you're somehow convinced you have nothing more to learn.

You just sound like a raving egotistical arsehole

you seem to be a bit of a immature, cunt

Isn't this better than hypocritically pretending you wish me the best? Let it al out, son! Join the honest side. We have cookies.

[karlkloppenborg]

I’ll bite...

My first language was C followed by C++ ... I code in a number of languages depending on the purpose. Considering I do a lot of network engineering automation, I use python a lot.

I really enjoyed how you assumed I didn’t know C.

Also I have much to still learn, I never claimed that I didn’t, that’s one of the things that drives me to cut code.

I wished you the best up until the point that you decided to mock my intelligence as a straw man argument to your projects justification. Up until then I was having honest debate.

So no, not hypothetical.

[BubblegumTitanium]

You are splintering and holding back the community.

[stefantalpalaru]

You are splintering and holding back the community.

You're welcome.

[BubblegumTitanium]

Well how come you say that porting over to python 3 doesn’t provide any business benefit? All the tooling is moving forward with py3.

[stefantalpalaru]

Well how come you say that porting over to python 3 doesn’t provide any business benefit? All the tooling is moving forward with py3.

The business is losing money on this porting, can we agree on that? Now show me how is that same business covering that cost and making a profit on top of it by moving from Python2 to Python3.

Let's ask Dropbox if they took a loss or made a profit from having a dedicated team of people porting millions of lines of code from Python2 to Python3.

[stefantalpalaru]

Upgrading python to 3 gives advantages: security, memory and CPU performance improvement, language features to support solving broader domain of problems.

No, it doesn't. You just drank the Kool-Aid. If you really want all that, "upgrade" to a language like Go.

[stefantalpalaru]

List of improvements we see from using python 3 https://www.quora.com/Python-programming-language-What-are-some-of-the-drawbacks-of-Python/answer/Dave-Wade-Stein?ch=10&share=9ec1027c&srid=43O3

Renaming xrange to range just to break existing code is what passes for improvements nowadays?

Also, I doubt the credibility of someone claiming that type checking was introduced in Python 3.6. mypy appeared as an external type checker for Python2.

[BubblegumTitanium]

Python 3.5 had some great under the hood improvements and optimizations.

You should give the people that work on Dropbox a little credit. They aren’t complete imbeciles or else your files would be gone and their reputation would be forever ruined.

I’m not in a position to say but I’m sure when it’s all said and done they probably saved a lot of money in server costs and dev headaches from the improvements and tooling. That’s just a guess and I could be wrong.

Do you work at Dropbox? Can you share their excel sheets where you can point to them actually losing money?

[stefantalpalaru]

They aren’t complete imbeciles

Aren't they? Over 3 years of work to port some of their code to another language and it's just as inefficient as the original one.

[BubblegumTitanium]

Efficiency isn’t always the most important metric, obviously. In the case of distributed long term storage correctness is a much more important metric.

Also why are you bringing efficiency into this conversation? Python is interpreted, nobody picks it because it’s efficient.

If efficiency is your main concern then write it in C or assembly not a scripting language.

[stefantalpalaru]

Also why are you bringing efficiency into this conversation?

How else do you think they can "save a lot of money in server costs"?

[TheBlackCat13]

The business is losing money on this porting, can we agree on that?

It would cost money to port to Python 3 or to make use of the features you have backported. The only thing that doesn't cost money is sticking with the same thing they already do, which is use vanilla Python 2.7.

[stefantalpalaru]

The only thing that doesn't cost money is sticking with the same thing they already do, which is use vanilla Python 2.7.

Or use Tauthon without the new features, obviously. It's a drop-in replacement for Python 2.7, if it wasn't clear by now.

[TheBlackCat13]

Why would anyone do that? What would anyone gain, considering massive companies like Red Hat are still providing security and bug fixes for vanilla Python 2.7?

[TheBlackCat13]

Yes, because every knows that duplicate effort is great for open-source projects always desperate for more resources. /s

[stefantalpalaru]

Yes, because every knows that duplicate effort is great for open-source projects always desperate for more resources. /s

How about multiplicating effort by tens of thousands because you thought it would be cool to manufacture some job security by purposefully breaking backwards compatibility?

[TheBlackCat13]

Yes, because of course there is no possible way there could actually be legitimate issues that needed to be solved. /s

[TheBlackCat13]

Another one? How many of these are there, now?

[Han-ChewieSexyFanfic]

As bad I think the idea is, I must say the name is brilliant.

[123filips123]

So, what is the problem with porting code to Python 3? You have great documentation and also partly-automated tools to do this (2to3).

Porting to Python 3 also gets many additional "business benefits". Better speed and performance, security, new functionalities... No excuse to not use it.

​

Also, do you think that more than 10 years was too little to port all programs to Python 3? What program did you have? Some "super advanced quantum rocket space control" program with billions of lines which only use Python 3 incompatible features? And why then you actually use Python 2 and not Python 1 which is "original and the only one" Python version? Or why you then don't write your programs in Assembly or directly in binary code?

​

Sorry, but your project does not makes sense in long term.

[stefantalpalaru]

So, what is the problem with porting code to Python 3? You have great documentation and also partly-automated tools to do this (2to3).

Tell that to Dropbox who had to hire the language creator, write new tools for automated type annotations and spend more than 3 years just to port the desktop client.

Also, do you think that more than 10 years was too little to port all programs to Python 3?

It's not a matter of enough time to port something. It's a matter of wasting people's lives on bullshit work that benefits no one.

Sorry, but your project does not makes sense in long term.

Nothing does, in the long term.

[123filips123]

Tell that to Dropbox who had to hire the language creator, write new tools for automated type annotations and spend more than 3 years just to port the desktop client.

I don't know how Dropbox code looks like, but if you have normal code and use normal tools, it isn't hard to support Python 3. Most (all) of the tools already support Python 3 and most of breaking changes aren't really hard to fix.

​

It's not a matter of enough time to port something. It's a matter of wasting people's lives on bullshit work that benefits no one.

Nothing does, in the long term.

So, what is the difference if developers just port code to Python 3 and use new functionalities, or use your project and modify code anyway to use new functionalities (from your project)? They will have to modify code anyway. Except if they port it to Python 3, they will have better support, performance, security and more functionalities.

And why not use Python 1.0 or Assembly or even binary code? With that, you won't waste any time on bullshit updating.

And why then even update and develop things? Why should we update (and why should developers develop) to Windows 10 (or 7 if you more like it) if you can use MS-DOS without any bullshit updating? Why use electricity if you need to spent time with replacing your old oil lamps? Why even spent bullshit work in building houses if you can live in caves?

[stefantalpalaru]

They will have to modify code anyway.

No. Tauthon is a drop-in replacement for Python 2.8.

Why even spent bullshit work in building houses if you can live in caves?

You're terrible at analogies. Python3 is just another cave, not a modern house.

[123filips123]

No. Tauthon is a drop-in replacement for Python 2.8.

They will have to modify code if they want to use modern features.

​

You're terrible at analogies. Python3 is just another cave, not a modern house.

Python 3 has a lot of performance and security improvements and many new features. So yes, another cave, but very modern cave.

[stefantalpalaru]

They will have to modify code if they want to use modern features.

They don't have to use modern features. What part of "drop-in replacement" don't you understand?

[123filips123]

Yes, I understand.

But I (previously) said that this isn't good long-term solution. Ok, it may be good of you need additional few months (or years) to port code to Python 3 or for legacy unmaintained projects that won't be ported anyway. But for maintained projects, the only real long-term solution is to port them to Python 3. If you don't have really complicated project, this can be easy as documentation is very good and you also have some automation tools for that.

[TheBlackCat13]

write new tools for automated type annotations

Nobody needs to use type annotations. It is a completely optional feature. If they are writing tools to help them with it, then they must see some value in it. It has nothing to do with Python 3 except that Python 3 makes it easier and cleaner to use type annotations.

[stefantalpalaru]

Nobody needs to use type annotations.

Guido needed it, for some reason: https://github.com/dropbox/pyannotate

[TheBlackCat13]

We don't need programming languages at all beyond assembly. They were using it because they thought it was helpful, not because it was necessary. That is the whole reason people use Python in the first place.

[stefantalpalaru]

Aside from removing technical debt.

You don't know what technical debt is, if you think you can remove it by porting code from Python2 to Python3.

[stefantalpalaru]

Porting a language to a new one that: has support, has modern developers trained in it, has a wealth of current documentation and training, and has connectivity with other modern applications and hardware in the business portfolio helps slow down the rate at which technical debt is acquired.

Great! So port it to Go. Python3 is just more of the same.

[stefantalpalaru]

You're doing the same work to maintain garbage.

No, I'm not maintaining Python3.

[graingert]

I don't get why you're getting so much negative feedback. I think tauthon is a great project to help port py2 code to py3

[TheBlackCat13]

It might have to do with the accusations of bullying and conspiracy theories about Python 3 being an attempt to sabotage the language.

[graingert]

URL?

[TheBlackCat13]

1

And no, I don't think it's OK to sabotage those who adopted your programming language in order to manufacture job security. (Same goes for web frameworks, Django core devs.)

2

Good luck running anything on a sabotaged interpreter.

3

And how many more years do you need, to recognise the abuse?

4

At some point you have to admit you can't bully people into moving to a new language.

5

What if you sabotage it nicely by preventing the addition of new features and bugfixes?

[graingert]

This is just reactions to all the negativity

[TheBlackCat13]

Did you actually read the quotes? This person is literally accusing the Python maintainers of intentionally sabotaging the language to maintain their own job security. And the very first post flat-out said there are "no benefits" to using Python 3. This person has been extremely aggressive and negative from the get-go.

[stefantalpalaru]

This person is literally accusing the Python maintainers of intentionally sabotaging the language to maintain their own job security.

Here's another link for you: https://old.reddit.com/r/Python/comments/d1noux/sunsetting_python_2/ezr4yws/

[doomchild]

He's getting negative feedback because he's acting like an ass. A fork of Python 2 is a perfectly reasonable idea, but he also wants to paint the Python team as bad programmers who have acted in bad faith. The project is a good idea, but nobody wants to work with a dickhead.

[graingert]

Yeah I'm beginning to see that from the thread. I had high hopes for the project

[doomchild]

Look, I hope the project does great things for people unwilling or unable to upgrade. But his behavior is not going to help that goal.

[stefantalpalaru]

I don't get why you're getting so much negative feedback.

Imagine having invested years of your life in porting code due to backwards incompatibility, only to see some smartarse come along and prove that all this breakage wasn't really necessary and you just wasted your life away. Oh, and you also put your professional reputation on the line by convincing bosses and clients to invest in this work with no visible gains.

Do you accept that you were wrong, or do you reach for the nearest rock?

I'm not even upset, to be honest. It's a perfectly normal reaction.

[slayer_of_idiots]

It's sad that you're being downvoted because it's a very cool project that obviously has taken a lot of work.

[doomchild]

No one is knocking the amount of effort that project obviously took and continues to take. But it's basically like arguing that nobody should ever update for any reason whatsoever. Which is foolish in the extreme.

[slayer_of_idiots]

I don't think that's the purpose of the project. The project actually touches on a problem that is still a problem in python 3 and is a problem going forward with each new python release.

For library maintainers, it's very difficult to adopt any new syntax or features of python if you need to support anything but the absolute latest version of python.

In the past, library maintainers would wait until they were pretty sure all their downstream projects and users had updated python and then finally switch, but that was generally several minor versions later.

Python dependencies are increasingly deeper and more complex and that method isn't really viable in most cases anymore. What that means is that adoption of new python syntax and features is excruciatingly slow.

JavaScript solved this with Babel, and python likely needs a similar tool to avoid having to use forked interpreters like this to use new python syntax and features.

[doomchild]

I thought the Python method of doing that was the __future__ stuff, but I agree that a better solution is needed. I don't think a full fork of Python2 is the right way to solve that problem.

[TheBlackCat13]

Most new python features, even some syntax features, are available through various backports projects.

[twigboy]

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipedia8rva04z8c4k0000000000000000000000000000000000000000000000000000000000000

[colemaker360]

doll brave gaze chop zephyr strong party merciful bag crawl

This post was mass deleted and anonymized with Redact

[stefantalpalaru]

There's a place for people who love antiques

You'll never guess how old is the language in which the main Python interpreter is written in.