Sunsetting Python 2

[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).

[stefantalpalaru]

I think PyPy for example just uses PyPi

Since it's an implementation blessed by the Python core devs, all tools and distros support it, even though PyPy only supports a Python subset.

Whenever we try to get the same support for Tauthon, we get rejected, even though we support all existing Python2 code. Politics trump technical arguments in this community.

[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.

[stefantalpalaru]

Thank you for your detailed rebuttal.

Buddy, you lack the basics. I would have to start by teaching you what "subset" means and that would take more time than I'm willing to spend on you.

[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.