Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing Python 2.x support from Django for version 2.0

github.com

Post reply on HN
Print view View original

381–390 of 413 posts

Re: Removing Python 2.x support from Django for version 2.0

#381

Post by int_19h »

Radim wrote: post #70
gtaylor wrote: post #28

Earlier quoted context omitted.

I'm not seeing signs of these kinds of widespread issues out in the wild. The popularity of the language has continued to increase, and numerous warts and flaws were wiped out in Python 3. That Unicode "cruft" is especially appreciated by the rest of the world that exists outside of the US. Python 2's approach to bytes and encoding is naive and horrible for 2017.

I'll bite. I'm outside of the US and Python 2 has worked wonderfully for ages. Its unicode support is good. You work with strings as unicode, then at I/O boundaries (and exceptions) you convert to bytes. What specifically do you find "naive and horrible" about its bytes and encodings? Python 3 can use less memory for unicode strings (a cool optimization introduced in py3.3, IIRC), and it did away with the "narrow/wid…

It's actually easier for people outside of US, who are forced to deal with languages that require Unicode to work properly. If you screw up somewhere, you notice right away.

But those for whom the majority of input is ASCII can often get away with broken code (that e.g. writes out Latin-1 JSON) for a while. And then they get input with a word like "naïve", and oh look, all hell breaks loose.

Python 3 solves this problem by making every transition problem explicit, requiring the developer to stop and think what they're doing when going from byte representation to strings, and vice versa.

"Explicit is better than implicit."

Re: Removing Python 2.x support from Django for version 2.0

#382

Post by lanstin »

Flip-per wrote: post #123
surouaue wrote: post #91

Earlier quoted context omitted.

When you say "Django is not RoR", are you saying Django doesn't break backwards compatibility but Ruby on Rails does? If so, I have to very strongly disagree. It's almost mind boggling to me how much they break backwards compatibility as a framework. They usually warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version, but the sheer amount of these…

How else would you introduce backwards incompatible changes? Especially with the LTS upgrade path that alasdairnicol mentioned I wonder what there is still to improve.

I worked in a C shop for like 8 or 10 years and we never introduced a back-wards incompatible API release. There were a few changes that required all servers to be restarted (not at once) to change network protocol (16-bit fields overflowing, that sort of thing). But it was inconceivable that you'd break something that is working. To be sure, we took a couple of weeks before designing an API, and for no one was the API they wrote and shared with others the first API they designed as an adult. Even when the implementation mutated out of all recognition, the API owner would just do whatever re-coding/re-implementation was needed behind the existing API.

Re: Removing Python 2.x support from Django for version 2.0

#383

Post by StavrosK »

nodamage wrote: post #375
StavrosK wrote: post #221

Earlier quoted context omitted.

"I have a Python 2.6 project that has been running smoothly, why upgrade to 2.7?" If you don't need any of the new features and fixes, don't, that's perfectly fine.

The difference between going from 2.6 -> 2.7 and 2.7 -> 3 is enormous though.

Not if you don't need it.

Re: Removing Python 2.x support from Django for version 2.0

#385

Post by collinmanderson »

Joeboy wrote: post #279
mcintyre1994 wrote: post #275

Earlier quoted context omitted.

I don't have any projects using Django but they have an LTS model - surely you don't need to update to avoid being vulnerable? Just security patches?

For three years, if you release your project the day the LTS comes out.

If you start your project on the day a LTS comes out, you'll theoretically be compatible with the _next_ LTS, 2 years later, so in some ways it's up to 5 years until you need to change your code.

Re: Removing Python 2.x support from Django for version 2.0

#386

Post by collinmanderson »

faitswulff wrote: post #199
IndianAstronaut wrote: post #192

Earlier quoted context omitted.

>Python 2 is slowly being EOL'd and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. Except that there are still some critical packages that aren't on Python 3 yet. Not to mention a lot of functionality breaks even if the libraries do exist, which means you have to code things up quite differently sometimes.

What critical packages still need to be ported to Python 3? Might be a fun project if they're open source.

There's a long list here. Feel free to dive in! :) http://fedora.portingdb.xyz/

Included in the list: nodejs, chromium, trac, bugzilla, bazaar

Re: Removing Python 2.x support from Django for version 2.0

#387

Post by collinmanderson »

TeMPOraL wrote: post #188
coldtea wrote: post #121

Earlier quoted context omitted.

Well, I'm for user driven EOL, as opposed to top-down, we-know-better EOLining. And the latter doesn't work so well thus far for Python 3.

If enough people like Python 2 that much, I guess someone else can take over maintaining and developing this language version past the official EOL date.

Like Guido's employer, for example. (see pyston)

Re: Removing Python 2.x support from Django for version 2.0

#388

Post by linsomniac »

ergo14 wrote: post #373
linsomniac wrote: post #257

Earlier quoted context omitted.

I've been talking to some of the developers on FreeNode about their support of old releases. In particular, related to statements about "Once 1.8 comes out, 1.6 will no longer receive patches". 1.7 came out 9 months ago and 1.8 is in beta. In other words, they don't really have a LTS process. And the developers seem to think this is totally ok. In my experience, anything that doesn't have a commitment to at least fix…

But you think about this in a wrong way - pyramid is a "glue" framework, unlike django. - request/response (webob) gets its own updates. - templates get their own updates. - sqlalchemy gets its own updates Etc. You WILL get security fixes for most of your application even without upgrading the framework itself (the attack surface for pylons/pyramid itself is smaller than monolith). By being on a lower version you don…

... then isn't it not a big deal to commit to security updates?

Re: Removing Python 2.x support from Django for version 2.0

#389

Post by Radim »

toyg wrote: post #358
Radim wrote: post #70

Earlier quoted context omitted.

I'll bite. I'm outside of the US and Python 2 has worked wonderfully for ages. Its unicode support is good. You work with strings as unicode, then at I/O boundaries (and exceptions) you convert to bytes. What specifically do you find "naive and horrible" about its bytes and encodings? Python 3 can use less memory for unicode strings (a cool optimization introduced in py3.3, IIRC), and it did away with the "narrow/wid…

This has been explained over and over. Those boundaries in python2 are very easy to get wrong and the runtime will not warn you, which means you won't know about them until some crap data comes down the wire and code chokes or (worse) silently corrupts data. In py3 you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible. It shouldn't take 8 years to understand this issue, and…

"With dynamic typing, the runtime will not warn you, which means you won't know until some crap data comes and your code chokes. With static typing, you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible."

See what I did there?

toyg, I found your comment unbearably rude, condescending and arrogant, and downvoted it for that reason.

Post reply on HN