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

281–290 of 413 posts

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

#281

Post by mmerickel »

linsomniac wrote: post #257
ergo14 wrote: post #126

Earlier quoted context omitted.

I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.

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 that have grown to be able to offer such a level of support.

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

#282

Post by dplgk »

stefantalpalaru wrote: post #133
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.

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

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

#283

Post by TAForObvReasons »

cookiecaper wrote: post #276
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…

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 break your code. If you start from the docs every time, following the recommendations, Django is pretty good.

I manage a modest project and there are plenty of issues with corner cases that I knew were possible but never could reproduce. As people stumble upon them and report issues I can update the test suite to avoid stepping on the landmine again, but that doesn't change the fact that we've barely scratched the surface.

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

#284

Post by Daishiman »

karthikp wrote: post #196
Ensorceled wrote: post #184

Earlier quoted context omitted.

I'm in the midst of upgraded a 1.6 project to 1.10 and Python 3. Wish me continued success :-)

I've been trying that for the past 1 year with no luck. Product always takes higher priority. Make sure you have dedicated time for the migration

This is not a sustainable position to be in. Migrations are product issues.

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

#285

Post by danpalmer »

mrfusion wrote: post #204
danpalmer wrote: post #48

Earlier quoted context omitted.

Agreed. We've got a ~100k line Django project and I'm fairly confident it won't be more than a day or so of work to migrate. The only thing keeping us on 2.x is our dependencies most of which already have Python 3 support so it's really just a matter of us upgrading dependencies.

One day sounds impressive. What's your strategy?

- Most of it can be automated with 2to3.

- We already have linting in place that encourages Python 3 compatibility (and have no linter warnings on master).

- We already use six for moved modules.

- And we have a test suite that is not exhaustive, but 'good enough' to find the common patterns of bug for this kind of thing.

- We also have a style-guide that favours the ability to find-replace project wide with relative safety.

- We don't have much 'math heavy' code that will fail with the changes in operations in Python 3.

- We already use unicode for the majority of strings.

- We don't use my Python networking code directly, it's mostly just Requests (so a lot of the moved modules don't apply).

This excludes the upgrading of dependencies, I think that's where we will spend more time, but the actual Python 3 transition for the main codebase should be ok, mostly because of the effort we've put into style and review since it started ~5 years ago.

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

#286

Post by [deleted] »

cookiecaper wrote: post #280
mangeletti wrote: post #198

Earlier quoted context omitted.

I always expected Pyramid to offer some performance benefits over Django, given the origins (taking the best of framework X and Y), esp given that you can choose your own ORM (e.g., SQLAlchemy), etc. However, once you're out of the unrealistic scenarios (single query benchmarks, etc.), it doesn't do that well[1]. It's not prohibitively slow, but to make the jump from something as well documented and with as large a c…

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…

[deleted]

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

#287

Post by Buttons840 »

bmh100 wrote: post #182
nodamage wrote: post #75

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…

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

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

#288

Post by mangeletti »

cookiecaper wrote: post #280
mangeletti wrote: post #198

Earlier quoted context omitted.

I always expected Pyramid to offer some performance benefits over Django, given the origins (taking the best of framework X and Y), esp given that you can choose your own ORM (e.g., SQLAlchemy), etc. However, once you're out of the unrealistic scenarios (single query benchmarks, etc.), it doesn't do that well[1]. It's not prohibitively slow, but to make the jump from something as well documented and with as large a c…

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)

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

#289

Post by sirn »

cookiecaper wrote: post #280
mangeletti wrote: post #198

Earlier quoted context omitted.

I always expected Pyramid to offer some performance benefits over Django, given the origins (taking the best of framework X and Y), esp given that you can choose your own ORM (e.g., SQLAlchemy), etc. However, once you're out of the unrealistic scenarios (single query benchmarks, etc.), it doesn't do that well[1]. It's not prohibitively slow, but to make the jump from something as well documented and with as large a c…

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…

Pyramid is actually more of repoze.bfg[1] which inherited a little bit from Zope. The overall experience is still very Pylons-like, and Zope stuff are very transparent, though.

[1]: http://docs.repoze.org/

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

#290

Post by danpalmer »

ergo14 wrote: post #126
danpalmer wrote: post #40

Earlier quoted context omitted.

I'd prefer to hold judgement on the internals of Django, however as a developer using the API, I also think it's a pleasure to use. There is a very high level of consistency, similar patterns used throughout, and the architecture results in a project structure that I can explain to a new developer who has never used Django before in minutes. I find few frameworks really scale in terms of structure and consistency, an…

I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.

My problem with Pyramid (although having never used it in production) is the same as my problem with Flask.

They say "Start small, finish big", and push the fact that Pyramid scales from a single file codebase, up to many files. This is something that I just haven't seen in practice.

A Django project requires quite a few files, so it's never a great answer when the total amount of business logic is The biggest red flag from Pyramid for me is their point: "Use Pyramid as a "framework framework" to craft your own special-purpose, domain-specific web system".

In my experience, this means that every project is a special snowflake of a project that works in a very different way to other projects. With Django you have a tried and tested architecture, with Flask and Pyramid, it often seems that you have to create your own architecture in some ways, and that results in each project being really quite different.

Post reply on HN