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

301–310 of 413 posts

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

#301

Post by nostrademons »

tedmiston wrote: post #264
osullivj wrote: post #241

Earlier quoted context omitted.

2.7.8 was the latest 2.x when I built the current codebase. Currently I'm testing before a cloud launch. Fixing bugs in my product's functionality is a higher priority than porting to the latest 2.7

Python 2.7.9 Release Date: 2014-12-10 https://www.python.org/downloads/release/python-279/

2 years is not an unusual time between starting product development and seeing any sort of major customer uptake, and if you're in that time period, your priority really should be getting the customers rather than futzing with code migrations.

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

#302

Post by linsomniac »

mmerickel wrote: post #281
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…

> And the developers seem to think this is totally ok. To be clear the core maintainer-ship of pyramid is about 2-3 people. We would love more contributors to the core codebase, but with that level of commitment we're obviously not able to provide a comparable level of support to a project with more contributors. This is the nature of open source and it is the rare exception to the rule to find packages / projects th…

Sure, but this is in a thread that starts with "Django has a new release", so I do think it is relevant considering that Django DOES have LTS releases.

(Aside: mmerickel is the developer I was talking to in Freenode)

Honestly, I didn't know that Pyramid had such a small amount of manpower behind it. It presents itself and has a reputation in the Python community, at least in my experience, of a bigger project.

But, as far as not being able to commit to security releases for old versions: it's obviously a choice in where to spend the available resources, not one of the size of those resources. Choosing new development over providing critical fixes of older releases is a choice, it's just one I need to understand before I commit to using a component. I understand why one would make either of those choices, I just need to know which one has been selected. It is great for people who want to choose forward development focus, I'm just not one of them.

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

#303

Post by sametmax »

coldtea wrote: post #62
gtaylor wrote: post #45

Earlier quoted context omitted.

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.

> 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. That's the version of Python that most of their users actually use -- with no major plans of mass updating.

The ruby community moved on after their last breaking change in less than 2 years.

The JS community deals with breaking changes every 3 months or so.

From Python 3.0 the end of support, you have __15 freaking years__, warnings, tutorials and excellent tooling at your disposal. Oh, on a free software. Half made by some charity workers.

Now you made a choice, and there are very good reasons to have made it. We won't criticize it.

But you lost the right to complain.

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

#304

Post by strange_quark »

dplgk wrote: post #282
stefantalpalaru wrote: post #133

Earlier quoted context omitted.

> its healthy consideration for backwards compatibility Is this a joke? They break backwards compatibility with every minor version, wasting tens of thousands of man-hours all over the world - time that, if we're honest, is not exactly billable. Most people don't upgrade because of this and keep on using vulnerable versions. It's good that they are trying to kill the project. It saves newbies from stepping into the t…

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

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

#305

Post by orf »

problems wrote: post #214
faitswulff wrote: post #199

Earlier quoted context omitted.

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

IDAPython (the python scripting plugin included with IDA Pro) still only supports Python 2.7.

Then contact IDA and ask when they are releasing a python3 version of their package. Your a paying customer after all...

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

#306

Post by takeda »

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.

Is really not that hard to make C extension support Python 3, you're either using an extension that is no longer maintained, or its author(s) are stubborn, which is a different kind of problem.

Making code compatible with python2.7 onward means that you can't use any new features from 3+ and the code is plain ugly, I don't know if you wrote 2/3 compatible code, it is not as enjoyable to do.

I think Django's approach where the LTS will still work on 2.7 (and LTS is for 3 years, which is until python2 itself stop being maintained) is fair.

You still have 3 years to fix things and if you want to use latest Django and be cutting edge, you probably should use latest Python as well.

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

#307

Post by bmh100 »

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'm specifically referring to OrderedDict in this case, which does have guaranteed, insertion-based ordering. It was introduced in 3.1, circa 2009, via PEP 372.

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

#308

Post by brianwawok »

hedora wrote: post #293
TAForObvReasons wrote: post #283

Earlier quoted context omitted.

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…

You are finding crash bugs with your test. Most Django regressions are logic bugs. Like some library overwrote a method and that method got a new param in Django, breaking the library. Good libraries with good tox suites catch this. Not all libraries are good.

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

#309

Post by [deleted] »

hedora wrote: post #293
TAForObvReasons wrote: post #283

Earlier quoted context omitted.

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…

[deleted]

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

#310

Post by rectangletangle »

olau wrote: post #265
scrollaway wrote: post #86

Earlier quoted context omitted.

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…

The template system is sometimes a pain, but sometimes the fact that it pushes you to move complexity out of the HTML and into Python code can make for more maintainable code in the long run. That's at least been my experience over the years.

It's annoying at first, but if you maintain a code base long enough, you'll be glad it's done the way it is.

This also has the side-effect of making the transition to client-side templating easier.

Post reply on HN