Removing Python 2.x support from Django for version 2.0 • Hacker News Board

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

#291

Post by cookiecaper » Thu, Jan 19, 2017, 5:06 PM UTC

mangeletti wrote: post #288

cookiecaper wrote: post #280

Earlier quoted context omitted.

I used Pyramid for a couple of large projects back when it was Pylons, and around the time of the merger that resulted in Pyramid. Django has grown up a lot in the last several years. It used to be really hard to use a different templating language, and I personally really dislike Django's templating language. That was the biggest turn off for me every time I looked into Django. If it had been pluggable earlier, this…

Thanks for the reply. What makes Pyramid better for you than e.g., Falcon? From your comment, it sounds like a lot of the value you've gleaned from Pyramid is based on the framework staying out of your way, so why not use something 5x faster that does the same thing? Does Pyramid provide some unmatched abstractions? (I'm coming from a position of no true experience in Pyramid)

As far as I know Falcon didn't exist last time I seriously looked into Python frameworks, so I don't know what would make it better or worse. From a quick glance, it looks promising and I'll definitely want to evaluate it next time I seriously engage in a custom Python web application, though I don't expect to do so for a long time (current project depends on the also-superb Mezzanine, a Django-based CMS).

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

#292

Post by thecardcheat » Thu, Jan 19, 2017, 5:16 PM UTC

Buttons840 wrote: post #287

bmh100 wrote: post #182

Earlier quoted context omitted.

You gain access to continued language support in 2020. New features involving strings will have less risk of bugs. The "range" function is more memory efficient. Integer division automatically floors, reducing bug risk. Dictionaries with guaranteed ordering. Thousands separator in string formatting. Bit length on integers. Combinations with replacement on itertools. New, faster I/O library and faster json. Concurrent…

> Dictionaries with guaranteed ordering. I don't think you're suppose to depend on the ordering of dictionaries. It's an implementation detail which might get changed, although it wont actually ever be changed because people will come to depend on it.

> I don't think you're suppose to depend on the ordering of dictionaries. It's an implementation detail which might get changed, although it wont actually ever be changed because people will come to depend on it.

I came here to make the same distinction - though I will say I hope you are wrong about people coming to depend on it when OrdereredDict is still there for a reason. The docs still plainly state that Dict should be considered un-ordered and do not make mention of this implementation detail (nor should they).

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

#293

Post by hedora » Thu, Jan 19, 2017, 5:24 PM UTC

TAForObvReasons wrote: post #283

cookiecaper wrote: post #276

Earlier quoted context omitted.

Whilst your menacing tone is not really in tune with HN's guidelines (and you'd be wise to edit it and soften it up I think), I think this is an important point to discuss. I don't have many Django projects, but even I have experienced weird, sometimes intermittent API breakages on minor version bumps that I've had to spend hours debugging, only to find that Django upstream changed the way some function behaved. I th…

In my experience, many reasonably large projects suffer the same issue. The "deficiency" is always in the test suite, but that's because a particular code pattern or property wasn't envisioned and isn't properly tested. The test suite is limited by the patterns of the developers, and if you do something that's technically possible but outside of what they are thinking, they could make seemingly innocuous changes that…

I usually work lower down the stack, and, frankly, that level of code quality would not be acceptable. (But what you describe matches my experince writing application level code)

Here is a strawman low level test: Randomly generate a sequence of nonsensical (but legal) API calls by randomly generating some data layout, then feed it into a state machine of legal API calls (eg. CRUD), and check the return values. Once that runs for 10 minutes without crashing, extend the test to be multithreaded and run with 1000 thread for a few hours. Dial back the runtime to 60 seconds, and stick it in the regression suite.

As long as there is a well defined API, this finds most bugs (and I also write targeted tests to exercise tricky / error prone paths).

Any thoughts on why it is so much harder to implement reliable high level frameworks? Is it dynamically typed languages / lack of encapsulation, or something more fundamental?

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

#294

Post by dragonwriter » Thu, Jan 19, 2017, 5:25 PM UTC

tedmiston wrote: post #262

ergo14 wrote: post #128

Earlier quoted context omitted.

Python 2.7 will not be maintained by PSF soon anyways.

The Python 2.x EOL was extended to 2020.

Which, I believe, is also the support timeline for the Django 1.x LTS release before 2.0. So Django plans to support Python 2.x as long as the PSF does.

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

#295

Post by oliwarner » Thu, Jan 19, 2017, 5:31 PM UTC

A whole pile of people complaining about upgrading Django highlights two things to me:

Not enough people are using tests. A decent set of tests make upgrade super easy. The upgrade documentation is decent so you just spend 20 minutes upgrading broken things until it all works again.

People pick the wrong version. I've seen people develop and even deploy on -dev and it makes me cry inside because they'll need to track Django changes in realtime or near enough. Pick an LTS release and you get up to three years on that version with security and data-loss upgrades and no API changes.

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

#296

Post by sly010 » Thu, Jan 19, 2017, 5:38 PM UTC

Galanwe wrote: post #21

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.

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.

I honestly think Django was a victim of it's own success. It started as a python (explicit is better than implicit) framework, but with a ruby-on-rails (convention over configuration) mentality. It became too successful too fast and it was too late to change things without breaking things. I remember it had all sorts of double import issues, a very limited (compared to jinja2) template engine and a very limited (compared to SQL Alchemy) ORM. It also coupled everything with everything, so it made it very hard to fix those issues. So as people grew into their projects, django got in the way. Most things were hidden in the framework lazily loaded so when you had some weird issues you didn't know where to look. I found it hard to digest that I couln't write a simple script that accesses the database without having to go through the entire autodiscovery process, hence incurring a 2-3 second delay on every execution. We also stopped upgrading at some point, because by the time django started supporting our special needs (especially around user handling), we already hacked around it, and upgrading would have been near impossible. The core developers probably knew all of these and they did more and more "de-magic-ification" with every version, and things are much better now, but we are stuck on an old version.

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

#297

Post by stevehiehn » Thu, Jan 19, 2017, 5:39 PM UTC

rbanffy wrote: post #147

stevehiehn wrote: post #23

Earlier quoted context omitted.

It believe it was a digital signal processing library. I don't recall the name.

You used the word "many"...

Ya, 'a few' is more accurate. I looked into pybrain which was 2.x. I understand that many people now use tensorflow. The point is it will be nice when more people normalize on 3. It did make me appreciate the backwards compatibility of Java.

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

#298

Post by gtaylor » Thu, Jan 19, 2017, 5:43 PM UTC

coldtea wrote: post #55

gtaylor wrote: post #34

Earlier quoted context omitted.

> I am also almost 100% certain that if scientific programmers leave Python, the language will stall, and the current 3.x pushers are dangerously looking a gift horse in the mouth. This sounds like such similar sour grapes to the systemd escapades. Huge initial outroar as certain things happened, followed by a gradual diminishing, then [mostly] acceptance. This is what is happening with Python 3 and a smaller, doom-a…

> This sounds like such similar sour grapes to the systemd escapades. Huge initial outroar as certain things happened, followed by a gradual diminishing, then [mostly] acceptance. Only here we don't have mere service scripts, but millions of lines of code people have written in perfectly fine 2.x Python. And also here we don't have any significant uptake -- Python 2.x is still over 60% of what's used (according to Py…

With numerous libraries phasing out support for 2.x in current or upcoming versions, I think we actually do have significant uptake.

As pointed out by others, those PyPi stats are super off. Better to look at what's going on out in the community and with the most popular packages (like Django).

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

#299

Post by xrange » Thu, Jan 19, 2017, 5:44 PM UTC

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.

>Some corps may continue to do so

https://www.naftaliharris.com/blog/why-making-python-2.8/

https://news.ycombinator.com/item?id=13144713

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

#300

Post by aaronbasssett » Thu, Jan 19, 2017, 5:44 PM UTC

StRoy wrote: post #240

aaronbasssett wrote: post #141

Earlier quoted context omitted.

Says the Python maintainers? And it is completely up to them to say - http://legacy.python.org/dev/peps/pep-0373/#update Of course you can continue using Python 2.x after 2020 but you will receive no security/bug fixes.

> Of course you can continue using Python 2.x after 2020 but you will receive no security/bug fixes. I keep seeing this irrelevant line all the time from Python 3 Ayatollah and High Priests. Python 2 isn't only CPython. So what if the Python foundation stops maintaining CPython? Dropbox is writing a new, efficient Python 2 implementation to make their legacy Python programs run faster while they slowly port to Go. Th…

Pyston, Jython, IronPython; they're all esoteric when compared to CPython. And while Pyston or similar may continue their own Python 2 implementation many library/package authors will simply not support it. So your interpreter may not be EOL'd but you'll very quickly find the package versions you rely upon will be.