Live data from Hacker News

Removing Python 2.x support from Django for version 2.0

github.com

351–360 of 413 posts

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

#351
post #182

I have a Python 2.7 project that has been running smoothly for many years now and I'm having trouble finding a reason to upgrade to Python 3. The project uses the unicode type to represent all strings, and encodes/decodes as necessary (usually to UTF-8) when doing I/O. I haven't really had any of the Unicode handling problems that people seem to complain about in Python 2. Can someone explain what benefit I would act…

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…

Like many database-backed apps performance is currently limited by I/O, and memory is limited based on the size of the data sets I load (machine learning). A faster, lower memory Python does sound nice but I'm not sure how much effect it would actually have in real life.

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

#352

Earlier quoted context omitted.

I'm fairly sure I'm handling strings correctly under Python 2. What I'm not sure of is the risk of something breaking if I upgrade to Python 3, especially when it comes to upgrading external dependencies. Even if it's just non-backwards compatible API changes, it's more risk to deal with.

Isn't that what test bases are for?

Tests will tell you something broke, you still have to go through the work of figuring out why and how to fix it.

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

#353
post #279

Earlier quoted context omitted.

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.

Symfony has 3 year LTS plus a year security support after. http://symfony.com/doc/current/contributing/community/releas...

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

#354

Earlier quoted context omitted.

I'm fairly sure I'm handling strings correctly under Python 2. What I'm not sure of is the risk of something breaking if I upgrade to Python 3, especially when it comes to upgrading external dependencies. Even if it's just non-backwards compatible API changes, it's more risk to deal with.

Do you think you will ever have to move to Python 3?

I don't know. I will probably try to by 2020 once it gets officially EOLed. Until then I have plenty of other work to do.

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

#355
post #350

Earlier quoted context omitted.

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.

It's still the case that a bad call was made when the codebase was started, picking a language version that was already on its way out. It's like starting a new project now with Java 7 o .Net 2.0.

Of all the bad calls you can make when starting a business, picking a bad language or platform is a relatively minor one. Google was originally on Python 1.6 (or technically Java 1.02, if you go back to when it was Larry's dissertation project), Facebook chose PHP (!!), basically every Android app is forced to use Java 7, and a good number of iOS apps are still in Objective-C.

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

#356
post #216

Earlier quoted context omitted.

> core base of users Lol. Before Numpy and friends even existed, Python was used mostly by "the web people" and sysadmins. Scientists are one of a number of Python constituencies, and not even the best-paying nor most visible one.

rofl! Numeric was started in 1995.

The xml sig started in 1994 and is still active, together with the web sig. The numeric sig started in 2000 and is now dead.

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

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

This is why continuous integration is good. If the latest version of a dependency breaks something, you'll know sooner rather than later.

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

#358
post #70
post #28

Earlier quoted context omitted.

I'm not seeing signs of these kinds of widespread issues out in the wild. The popularity of the language has continued to increase, and numerous warts and flaws were wiped out in Python 3. That Unicode "cruft" is especially appreciated by the rest of the world that exists outside of the US. Python 2's approach to bytes and encoding is naive and horrible for 2017.

I'll bite. I'm outside of the US and Python 2 has worked wonderfully for ages. Its unicode support is good. You work with strings as unicode, then at I/O boundaries (and exceptions) you convert to bytes. What specifically do you find "naive and horrible" about its bytes and encodings? Python 3 can use less memory for unicode strings (a cool optimization introduced in py3.3, IIRC), and it did away with the "narrow/wid…

This has been explained over and over. Those boundaries in python2 are very easy to get wrong and the runtime will not warn you, which means you won't know about them until some crap data comes down the wire and code chokes or (worse) silently corrupts data. In py3 you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible.

It shouldn't take 8 years to understand this issue, and I'm positive you do understand it because you're an intelligent person, so please don't troll about it.

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

#359
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?

Protip: Python 2 is EOL'd in 2020.

Start your migration now.

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

#360
post #321

Earlier quoted context omitted.

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

1. Would be a new feature, not really a bug. There have been multiple attempts to resolve which have all failed. DEPs exist to address this shortcoming.

2. Yep. Still a crappy situation to be in, but one that's also tricky to solve due to not being able to control the joins across multi-valued relationships.

Post reply on HN