Live data from Hacker News

Removing Python 2.x support from Django for version 2.0

github.com

251–260 of 413 posts

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

#251

Good. I've been getting into python a bit because i have an interest in datascience. I'm mostly a Java dev. I have to say the python2/3 divide is a real turn off. Many of the science libs want to use seem to be in 2.7 with no signs of moving.

> Many of the science libs want to use seem to be in 2.7 with no signs of moving The most important scientific libraries have pledged to drop support before 2020, and are all python3-ready http://www.python3statement.org/

The most important scientific libraries

Not numpy, scipy, tensorflow...

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

#253

Earlier quoted context omitted.

Which comments are you interpreting as demands? >> A lack of being paid (money at least) doesn't imply no obligations, nor freedom from criticism. > Excellent, then you should be fine with me criticizing the attitude that's been displayed here. Great. Do you actually have a response to this point in context, then? > This is the same as the IE6 situation: Want support for it? Pay extra for it! You did not argue this.…

You're appropriating criticism that was not directed to you, but to coldtea. Here and elsewhere. Edit: Yes, appropriating . You're taking criticism I specifically directed at coldtea, applying them to your comments and then complaining it doesn't fit. I am done talking to you. Edit 2: This was not meant to sound as aggressive as it did, sorry.

> You're taking criticism I specifically directed at coldtea, applying them to your comments

Perhaps, can you give an example?

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

#254
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.

> instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them

> there are some rough corners

content_types, generic foreign keys, and basically any other uncommon use pattern for RDBMS are very rough in django. Tradeoff of their ORM being heavily streamlined for the 90% use cases (typical SQL selects and upserts).

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

#255
post #31
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?

You're complaining about not being able to use the latest major version of a library when you refuse to change to the corresponding latest version of the language? So you want to stay cutting edge here but not there?

That's illogical and inconsistent. they're providing an LTS release for you. Get over it

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

#256

Earlier quoted context omitted.

> instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them

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…

breaking changes get a 2 major version release timeline. that's like 18 months (on average) of warning to update your shit. how could you possibly do this better?

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

#257
post #126

Earlier quoted context omitted.

I'd prefer to hold judgement on the internals of Django, however as a developer using the API, I also think it's a pleasure to use. There is a very high level of consistency, similar patterns used throughout, and the architecture results in a project structure that I can explain to a new developer who has never used Django before in minutes. I find few frameworks really scale in terms of structure and consistency, an…

I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.

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 fixing security issues for ~5 years, isn't a good choice for business. Businesses don't want to tie their internal development and release cadence to an external development team with less than 3 year cycles, ideally 5+.

I've seen it time and again over dozens of companies. There is no time to qualify apps for new major/minor releases. Anything that doesn't have a LTS release story is just not something I can feel good about deploying in my business.

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

#258
post #37

Earlier quoted context omitted.

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.

I disagree with the parent post; Django's codebase is overall pretty high quality. It definitely used not to be that way, though. But there are components that fit that. The entire form subsystem is awful to work with. Working with Javascript, webpack apps etc is a huge pain. The template syntax is also a failed design experiment, based on the premise that backend coders and template authors are not the same people a…

I think the form abstraction is one of the better versions of it that I've seen in any of the web frameworks I've worked with. It's simple and elegant for most forms, and can even handle complicated ones (multipart forms, file attachments, complex validation scenarios, etc.) reasonably well.

on a really fundamental level working with complicated forms is just a complicated thing to do, no matter what kind of technology you're doing it with.

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

#259
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.

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

which critical packages?

https://python3wos.appspot.com/

almost everything on the list has gone green now

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

#260
post #160
post #154

Earlier quoted context omitted.

I've had similar issues with most GUI libraries. Seriously: if you can, try building your thing with tkinter. It's the standard lib, and will "work"

I'm not going to port to tkinter. I like KDE, I like Qt Designer, and I have a working GUI. If tkinter is the only thing that works in Python I'll abandon the language (I mostly work in Scala these days anyway) and find one with working Qt bindings.

Just use C++ and your Qt bindings will never go away!
Post reply on HN