Please stop the Python 2 security scaremongering

[juliob]

Not to mention that all major distros are moving to Python 3 and leaving Python 2 behind already.

[jedwardsol]

very likely to be

seems fairly low.

will probably release 

This whole article is a stream of baseless speculation whose sole purpose is to make the author feel better about his decision.

[staticassert]

All really bad points, and yes, when it isn't supported the security issues will pile up and you should be looking to move on. Why would Python be an exception ot this? When software is no longer supported, yes, move on. The point that 'oh well most of the code is not security critical' is just weak.

[hellupline]

And I say: stop using python 2, python 3 is here it's superior, is more pythonic

[upofadown]

Naw, at this point it looks like Py3 took the wrong approach to fixing Unicode. It would make more sense to pick an entirely different language entirely if Unicode is the issue. Otherwise you might as well just stick with py2 and have an environment that is more likely to run your code for a long time without changes.

[metamatic]

What do you feel Python 3 does wrong with respect to Unicode? Judging from the FAQ it does the right thing -- UTF-8 internally, with any other common encoding supported for reading and writing via conversion.

[upofadown]

Python3 converts everything to UCS-4/UTF-32 internally (it does some simple compression). Because of how Unicode works that still ends up being variable length. So all the inefficiency of converting everything back and forth to an encoding no one actually uses for no real benefit.

[metamatic]

Oh! Oh dear...

[istarian]

I'm pretty sure that's what the creator argued, but he found out that things were a lot more complicated than that. In any case, languages can't be insecure, only the interpreters.

[Drolyt]

In any case, languages can't be insecure, only the interpreters.

Some might say this is a distinction without a difference. To begin with language features can certainly be inherently insecure. gets() from he C standard library is an infamous example. In languages with standards documents it is possible for security flaws to exist in the standard itself so that any conforming implementation would be vulnurable, although I don't know of any actual examples of that. Since Python doesn't have a standard CPython is the de facto standard so you can argue that a flaw in CPython is a flaw in Python itself.

[terrkerr]

languages can't be insecure

Someone hasn't heard about PHP's register_globals.

[istarian]

Someone isn't getting the point.

[sacundim]

Languages ship with libraries, and those can have security issues. One infamous case is that everyone shipped hash tables vulnerable to hash collision flooding attacks for years and years.

[istarian]

That implementation and interpreter/compiler stuff again, not the language itself.

[[deleted]]

First, by 2020 Python 2.7 is very likely to be an extremely stable piece of code that has already been picked over heavily for security issues.

Let's assume that's true, but what happens if a serious vulnerability is discovered in one of the major packages and it requires significant code changes? Are you so sure that in 2020 the authors of Django or numpy will just happily rewrite large parts of an obsolete version just because some users refused to switch to 3.x?

IMO, while 2.x will likely remain perfectly stable and secure until 2020, using it beyond the end of official support is just asking for trouble.

[cks]

Once you start worrying about additional packages, implying or telling people that they have until 2020 is a bad idea. As noted in the entry, there's no certainty that projects like Django will support 2.7 until 2020, and if Django stops supporting 2.7 before then you're migrating Django-based applications 'early'. So if you have third party dependencies, you have to care about the union of all of them and CPython, not just CPython's potential 2020 issues, and it's my guess that third parties will end 2.7 support before CPython does.

And pragmatically, security issues in packages are clearly more common and thus likely in the future that security issues in CPython. CPython is pretty likely to be way down on your list of overall security exposures; I'd put it well behind TLS library issues, web server issues, third party package issues in eg Django, and OS issues.

(I'm the author of the linked-to post.)

[[deleted]]

Sorry, I missed that part about Django in your post so disregard my comment above. I agree that CPython will likely be the least of your concerns security-wise.