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…
Removing Python 2.x support from Django for version 2.0
351–360 of 413 posts
Re: Removing Python 2.x support from Django for version 2.0
#352Earlier 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?
Re: Removing Python 2.x support from Django for version 2.0
#353Earlier 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.
Re: Removing Python 2.x support from Django for version 2.0
#354Earlier 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?
Re: Removing Python 2.x support from Django for version 2.0
#355Earlier 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.
Re: Removing Python 2.x support from Django for version 2.0
#356Earlier 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.
Re: Removing Python 2.x support from Django for version 2.0
#357Earlier 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.
Re: Removing Python 2.x support from Django for version 2.0
#358Earlier 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…
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
#359The 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?
Start your migration now.
Re: Removing Python 2.x support from Django for version 2.0
#360Earlier 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.
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.