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

41–50 of 413 posts

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

#41

Post by gkya »

hueving wrote: post #17
yuvadam wrote: post #6

This call has been made a while back, and it makes perfect sense. 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. Sure legacy projects still need support and for that they get the 1.11 LTS, but otherwise it's really time to move on.

Easy to say when you don't depend on C extensions only compatible with 2.7.

How hard it is to port a C extension? I don't really know the APIs, but is it impossible to transform by a script?

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

#42

Post by nsomaru »

hueving wrote: post #17
yuvadam wrote: post #6

This call has been made a while back, and it makes perfect sense. 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. Sure legacy projects still need support and for that they get the 1.11 LTS, but otherwise it's really time to move on.

Easy to say when you don't depend on C extensions only compatible with 2.7.

You're calling code that depends on C extensions from directly inside the request-response cycle?

One possible solution would be to offload this work into a celery worker which can call python2 as necessary.

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

#43

Post by stuaxo »

nsomaru wrote: post #37
Galanwe wrote: post #21

Earlier quoted context omitted.

Interestingly, I have the exact opposite view on Django. I hate their API and overall architecture, which I find to be the result of glueing features on top of features for many years. The internal code also is just like that: looks like every single method is riddled with out-of-band conditionals, which is the result of a community that prefers to hack things to work, instead of rethinking/refactoring.

Could you give a description of some subsystem that has been architectured in this way, and then provide a concrete example of some methods that implement this pattern and why it is bad? We are users of Django, and it helps us to deliver projects, quickly. Interested to know how you think things could be improved.

Not sure what it's like now, but the insides of the admin used to be fairly terrible (generating HTML with strings for instance).

There was a patch to change this to use templates, but it was rejected at the time as it slowed things down too much.

FormWizard (which I hear doesn't exist now), was a nightmare to use for any sort of complex form - I tried to do just this and had to call many private methods.

I understand metaclasses, but found the implementation of the ORM a little overcomplex.

Trying to use the ORM API to work out the structure of the DB was a bit of a pain last time I tried (had to call private APIs).

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

#44

Post by gtaylor »

stuaxo wrote: post #38
Galanwe wrote: post #21

Earlier quoted context omitted.

Interestingly, I have the exact opposite view on Django. I hate their API and overall architecture, which I find to be the result of glueing features on top of features for many years. The internal code also is just like that: looks like every single method is riddled with out-of-band conditionals, which is the result of a community that prefers to hack things to work, instead of rethinking/refactoring.

Last time I looked a lot of the insides were terrible. A project I was really impressed with the internals of is Celery (was expecting the worst having seen Django).

Things were a little bit hairy back in the 1.3 days, but they've done a ton of cleanup in modern times. I find the source much easier to follow these days. Many of the systems have been more clearly isolated to allow for replacement.

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

#45

Post by gtaylor »

coldtea wrote: post #31
Flimm wrote: post #5

The next release, Django 1.11, will be a long-term support release, and the one after that, Django 2.0, will no longer support Python 2. https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ I've grow to highly respect the Django project for its good documentation, its healthy consideration for backwards compatibility, security, steady improvements and all round goodness.

> its healthy consideration for backwards compatibility Like screwing the huge majority of users with Python 2.x Django projects and having them update or be left behind?

It's going to be more and more of a burden for the developers to maintain compatibility with a 7-year old version of Python.

I think this is smart and will help them focus on the road forward. Django 1.11 is an LTS release, so legacy stuff can stick with it and be just fine.

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

#46

Post by osullivj »

nsomaru wrote: post #42
hueving wrote: post #17

Earlier quoted context omitted.

Easy to say when you don't depend on C extensions only compatible with 2.7.

You're calling code that depends on C extensions from directly inside the request-response cycle? One possible solution would be to offload this work into a celery worker which can call python2 as necessary.

I code against both Django and Tornado. My Tornado based HTTP servers call C extension while they're handling GETs and POSTs. And that's why I'm staying on 2.7.8 until a customer pays me to port to 3.

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

#47

Post by coldtea »

yuvadam wrote: post #6

This call has been made a while back, and it makes perfect sense. 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. Sure legacy projects still need support and for that they get the 1.11 LTS, but otherwise it's really time to move on.

>and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore.

How about millions of lines of code in your company in Python 2, and several Python 2 based services and websites?

Why on earth will you go to Python 3 at huge rewriting costs? To get some fancy syntactic sugar and improved unicode?

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

#48

Post by danpalmer »

samwillis wrote: post #15
alanfranzoni wrote: post #3

So, after a poor evolution strategy that lead the Python world to be split in two and forces maintainers to offer two versions for the same library, and upstream maintainers to offer support for two different python versions, the same is happening for Django! I speculate that the latest Django 1.x will remain used - and possibly the most used - for a lot, lot of time.

I disagree, I think Django dropping support for 2 will actually push more open source projects to do the same. This will create the momentum and incentive necessary to nudge people over the edge and upgrade. There is an awful lot of hyperbole around the difficulty of upgrading from python 2 to 3, however with the latest changes in 2.7 and 3.6 the gap isn't as big as you expect. I converted our (admittedly not massive…

Agreed. We've got a ~100k line Django project and I'm fairly confident it won't be more than a day or so of work to migrate. The only thing keeping us on 2.x is our dependencies most of which already have Python 3 support so it's really just a matter of us upgrading dependencies.

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

#49

Post by MatthewWilkes »

vegabook wrote: post #14
alanfranzoni wrote: post #3

So, after a poor evolution strategy that lead the Python world to be split in two and forces maintainers to offer two versions for the same library, and upstream maintainers to offer support for two different python versions, the same is happening for Django! I speculate that the latest Django 1.x will remain used - and possibly the most used - for a lot, lot of time.

Python 3 is a seriously misguided project. It's got tons of newer-to-Python fans (your HN downvoter demographic), and tons of silent-majority "real-world" users especially in scientific programming who just don't like it. I moved to 3.4 a year ago and, as a data scientist, I have to say I find nothing in 3 to be better than 2, other than the extremely marginal default float arithmetic. I may be wrong for web developm…

For what it's worth, as someone who ha been working with Python for 11 years, Python 3 is a huge improvement over Python 2 and is certainly very popular with my peers.

The fact that you personally weren't particularly affected by the problems in 2 doesn't mean the problems weren't serious.

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

#50

Post by coldtea »

mrweasel wrote: post #35
vegabook wrote: post #14

Earlier quoted context omitted.

Python 3 is a seriously misguided project. It's got tons of newer-to-Python fans (your HN downvoter demographic), and tons of silent-majority "real-world" users especially in scientific programming who just don't like it. I moved to 3.4 a year ago and, as a data scientist, I have to say I find nothing in 3 to be better than 2, other than the extremely marginal default float arithmetic. I may be wrong for web developm…

To me, unicode alone was worth the switch. I will go to great length to avoid the hell that is unicode in Python 2. Besides speed, I never seen any good argument that would make me start a new project on 2.7, rather than the latest v3 release. I get that there was a series of data science libraries that wasn't supported initially, but seems to have been solved at this point. So I really do see why people continue to…

>Besides speed, I never seen any good argument that would make me start a new project on 2.7, rather than the latest v3 release.

That's because you start "new projects". Some of us have 10+ years of codebases to maintain, and we don't care for Python 3 features...

Post reply on HN