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

321–330 of 413 posts

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

#321

Post by myf01d »

anentropic wrote: post #319
myf01d wrote: post #222

I hope they just find a way to support SQLAlchemy natively like they did with Jinja2 because Django ORM is really very restrictive and has numerous serious annoying bugs that have been open since I was in high school.

> Django ORM ... has numerous serious annoying bugs Such as? I've worked primarily with Django for years and I think if the ORM really had "numerous serious annoying bugs" I'd have a mental library of these things to watch out for. But I can't think of any ORM bugs off the top of my head, I don't really remember encountering any. We all know SQL Alchemy is 'better' and there are things Django ORM can't do, but 99% of…

such as

1. multi-column primary key.

2. annotate several counts for some query correctly.

that what I remember for now.

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

#322

Post by scrollaway »

Daishiman wrote: post #278
scrollaway wrote: post #205

Earlier quoted context omitted.

If you want to use the Django staticfiles system (which you do - it's good and useful for non-js stuff as well), it kinda does. We use Django Webpack Loader for our sites: https://github.com/owais/django-webpack-loader - This allows us to do `{% render_bundle ... %} which pulls in the appropriate script tag. But even then you can really feel how painful it is to work with, especially if you're adding typescript/scss…

If you're building a form in React why do you even bother with django forms when there's Django Rest Framework?

I do use DRF; but it's quite painful to have to set up all the intermingling between the API urls and the actual form definitions. I don't use Django forms; you will generally want a single source of truth for the forms and it kind of has to live in the JS, but then that makes it inaccessible to Django...

For large apps it makes sense to do it this way. For smaller apps it really sucks.

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

#323

Post by stefantalpalaru »

ageofwant wrote: post #113
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.

No core Python dev will support Python 2 after EOL. Some corps may continue to do so sure, just like there are Java 1.4 codebases still in production. I will work on a Java 1.4 codebase if you are prepared to pay for my accrued personal obsolesce as well. If your Java 1.4 job is the last job I'll do it has to pay for the next 15 years lost income as well. The same will go for Python 2.

> No core Python dev will support Python 2 after EOL.

You say it like it's a bad thing. Core Python devs are terrible programmers.

I'm personally rooting for this fork now: https://github.com/naftaliharris/placeholder - it's what Python3 should have been.

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

#324

Post by billoday »

stefantalpalaru wrote: post #234
singularity2001 wrote: post #132

Earlier quoted context omitted.

Don't know why you were downvoted: still waiting for a seamless Python X upgrade as well, without code duplication.

It already exists, as a Python2 fork: https://github.com/naftaliharris/placeholder

This is the greatest thing ever - for systems work, python3 is a nightmare. Thanks for sharing this.

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

#325

Post by true_religion »

rbanffy wrote: post #151
true_religion wrote: post #129

Earlier quoted context omitted.

Or they could give permission.

And have a confusing set of different and incompatible languages with the same name? People are complaining about Python 3 being named Python because some code breaks under it. That would be hell.

You already have Python 2. This is a continuation of it that is simply closer in semantic to Python 3. How could it be bad if apart from the Unicode semantics the two versions became equivalent?

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

#326

Post by paulddraper »

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.

How long do you expect?

Java 7 had less than four years of support.

Ubuntu Desktop LTS was three years, and starting with 12.04 it increased to five years.

That's a language runtime and an operation system known for their stability, forming the bottom of very wide and deep ecosystems.

Show me a web framework with a 3 year LTS, and I'm overjoyed.

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

#327

Post by billoday »

rbanffy wrote: post #149
coldtea wrote: post #57

Earlier quoted context omitted.

No, he means language level progressive deprecation and evolution, as opposed to an abrupt jump to a changed 3 from 2.

You talk as if Python 3 were a dialect of Lisp. It's still Python, looks like Python and feels like Python. In fact, I think most of my Python 3 code runs on Python 2.

You talk as if the switch doesn't look like a bunch of arbitrary decisions made on the appearance of purity. If more of an attempt had been made a maintaining compatibility, there wouldn't be nearly as much fight. Python 3 becomes a bit uncanny valley for me when I try to code in it and I tend to use a different language as there less of an internal code switch, especially as I still have to maintain large numbers of python2 code.

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

#328

Post by Groxx »

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.

That doesn't seem too surprising. E.g. for Tornado, you have tornaduv, a C replacement for the core ioloop running everything.

Replacing hot spots with C is a tried and true tactic. I don't see how django would substantially change that equation.

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

#329

Post by fatbird »

viraptor wrote: post #36
vegabook wrote: post #27

Earlier quoted context omitted.

the benefit is that all the wasted energy that went into all the useless 3.x stuff, could have been spent on advancing Python's speed, multicore, or GPU programming capabilities. Instead, for the single use case where Python is clearly the dominant language (for pure network-effect reasons), namely scientific programming, we have been at a standstill for years. In other words, under current stewardship, Python is goi…

Interesting that you're looking for those improvements in CPython. From your list (IMO): speed and multicore are going to stay where they are in CPython - GIL is unlikely to be removed, because it's basically part of the behaviour right now. There were a few attempts, but it seems nobody even tries anymore. (and I'm fine with that) Maybe pypy, grumpy, or others will do this instead. I'm not sure why you expect GPU fr…

Actually, between PyPi and "The Gilectomy", there two serious projects to get rid of it, the latter with core developer support: https://us.pycon.org/2016/schedule/presentation/2101/

I attended this talk, and it was really great. PyPi is pursuing software transactional memory, which is massively difficult to implement. The Gilectomy approach is much more community oriented, and focuses on the transition.

Put a bit differently: it's easy to remove the GIL safely, it just incurs a non-trivial performance penalty and breaks C extensions, so the Gilectomy effort is around a combination of removing or avoiding that penalty if you're not multi-threading, and smoothly transitioning C extensions. After that talk, removing the GIL looks inevitable.

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

#330

Post by astrodust »

strange_quark wrote: post #304
dplgk wrote: post #282

Earlier quoted context omitted.

> They break backwards compatibility For the most part, they think they things through a lot and most importantly they document breaking changes. Their approach is an absolute dream compared to, say, updating xcode/iOS apps. It's a total shit show at Apple.

Ha, if you think that updating iOS apps is bad, try updating all your node modules to the latest version without anything breaking.

It's like Russian Roulette with your code. Maybe something will break, maybe you'll get off easy!
Post reply on HN