Removing Python 2.x support from Django for version 2.0 | Hacker News Reader

Removing Python 2.x support from Django for version 2.0

github.com

720 pointsReticentMonkey392 comments

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.

Could you give a description of some subsystem that has been architectured in this way, and then provide a concrete example of some methods that implement this pattern and why it is bad?

We are users of Django, and it helps us to deliver projects, quickly. Interested to know how you think things could be improved.

Not sure what it's like now, but the insides of the admin used to be fairly terrible (generating HTML with strings for instance).

There was a patch to change this to use templates, but it was rejected at the time as it slowed things down too much.

FormWizard (which I hear doesn't exist now), was a nightmare to use for any sort of complex form - I tried to do just this and had to call many private methods.

I understand metaclasses, but found the implementation of the ORM a little overcomplex.

Trying to use the ORM API to work out the structure of the DB was a bit of a pain last time I tried (had to call private APIs).

The core Django developers will (and have) freely admit that the admin interface implementation is a bit of a mess. There is an enormous amount of technical debt in it. It is however not a "core" part of Django and there are many alternatives. I think most people would agree that the correct long term solution to the admin interface is a complete rewrite, however the cost of doing so is too high.

The html forms (used in the admin and everywhere else) have until now been generated from strings, however the next realise 1.11 (went to alpha yesterday) this has been changed to using the template tools.

While the admin code is kinda messy it's still easy to extend and customize. I'd be somewhat surprised if you could make something that dynamic and not be at least a bit messy.

I myself and also other people I know have written quite some domain-specific applications almost entirely within the Django admin, which are as a result: secure, fast and easy to use, which in some cases are not just a bit better than the existing commercial tooling in these domains.

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 and should not have the same level of power -- some of this is based on a good idea at its core, but Django ended up backtracking on that half-way and we're now with a very inconsistent template system and having to implement kludgy template tags and filters or new object methods that do not take parameters whenever we want to do anything remotely complex.. At this point I wish it'd just move towards supporting Jinja syntax (that is, alongside the regular syntax, not as a separate engine like it's currently possible).

> Working with Javascript, webpack apps etc is a huge pain.

Could you explain what you mean? Django doesn't need to have any connection at all to your JavaScript stack.

If you want to use the Django staticfiles system (which you do - it's good and useful for non-js stuff as well), it kinda does.

We use Django Webpack Loader for our sites: https://github.com/owais/django-webpack-loader - This allows us to do `{% render_bundle ... %} which pulls in the appropriate script tag.

But even then you can really feel how painful it is to work with, especially if you're adding typescript/scss to the mix. Solutions like Django Compressor are not really the right model anymore.

And there's other issues as well. If you want to share settings between Django and the JS stack for example, you'll need to build your own pipeline for that. Building a form in react? Say goodbye to DRY on the form fields. Just, in general, Django predates JS apps being anything more than in-place enhancements and it shows.

If you're building a form in React why do you even bother with django forms when there's Django Rest Framework?

I do use DRF; but it's quite painful to have to set up all the intermingling between the API urls and the actual form definitions. I don't use Django forms; you will generally want a single source of truth for the forms and it kind of has to live in the JS, but then that makes it inaccessible to Django...

For large apps it makes sense to do it this way. For smaller apps it really sucks.

Django added Jinja2 as a built-in template backend some versions ago. The Django ecosystem hasn't really caught up to supporting it with reusable templates yet though.

Yeah I mentioned that. I don't think it can ever really work the way it's implemented right now. I think the only way it can work is slowly transitioning the Django template language to be syntactically similar to Jinja, that will give a progressive transition path. But it's a ton of work.

I think the form abstraction is one of the better versions of it that I've seen in any of the web frameworks I've worked with. It's simple and elegant for most forms, and can even handle complicated ones (multipart forms, file attachments, complex validation scenarios, etc.) reasonably well.

on a really fundamental level working with complicated forms is just a complicated thing to do, no matter what kind of technology you're doing it with.

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.

Last time I looked a lot of the insides were terrible.

A project I was really impressed with the internals of is Celery (was expecting the worst having seen Django).

Things were a little bit hairy back in the 1.3 days, but they've done a ton of cleanup in modern times. I find the source much easier to follow these days. Many of the systems have been more clearly isolated to allow for replacement.

When was the last time you looked?

> Last time I looked a lot of the insides were terrible.

But is it really? Speaking from personal experience it is easy to compare project with large featureset (and one with heritage) to one with scope on doing single thing and come with conclusion that smaller, focused codebase is more consistent and better implemented. At the end of day what matters is if those terriblenesses actually bite back:

- is this code changed frequently? Does it need to be changed frequently? - is it written in a way that that makes fixes and improvement unbearably costful? - is it written in way that allows it to be put apart? How costful are those individual parts to improve?

Django is large codebase that is worked on by different people and when time permits this, which means different parts differ in their age, practices, and ultimately, quiality. This eventually results in codebase that may give appearance of being messy.

Joel Spolsky explains this nicely in his article about old and large codebases appearing as hairy and messy to developers:

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Especially the part that follows below quote is valuable wisdom to keep in mind:

> When programmers say that their code is a holy mess (as they always do), there are three kinds of things that are wrong with it.

Celery is an interesting one. The code looks well written, but I found contributing to be a real pain and documentation a mess, especially compared to Django's docs.

Also, up until recently it was a one man job by Ask Solem. He's done incredible work making this project live and I am grateful for that. However I fear others have found it hard to maintain as well, slowing down progress on a very popular backend python project.

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, and working on a large web application, Django has proven to be very valuable for us.

I'm curious, what's an example of a framework that you think has a better architecture, and in what context are you evaluating this?

Minutes is a bit of an understatement, but given the amount of complexity involved, the API is acceptably consistent.

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.

Pyramid is great, but for years they had a ridiculous Iron Maiden- heavy metal like branding [0] which make it hard to sell it in the corporate world. I'm glad they evolved on this point.

[0] http://keitheis.github.io/use-pyramid-like-a-pro/?full#Cover

Not gonna lie, that cover(?)/artwork(?) looks pretty sweet. But I'm probably biased because I really like Iron Maiden.

I don't mind the artwork (and actually like it), but I think the real issue is the text:

    Use Pyrapid Like a Pro

"Like a pro(fessional)" implies that you, the target audience, are not "professionals". However, if you use it in the corporate world, you do use it as a professional.

This makes it sound like an advanced toy rather than a bullet-proof work of engineering you can rely on. Which is really a pity, because Pyramid _is_ a framework you can rely on.

I agree, but you know what; I think the new branding is worse :(

It's a shame, because I've wanted to try Pyramid since I watched their talk at PyCon 2011, but the branding (including the new 99 Designs looking logo / theme) has always made me think, "This will never really take off."

Not to mention, a few parts / typical components of pyramid are kind of nuts, like auth. Colander is also a struggle to use.

Still my go-to framework though. The websauna framework linked above might be something I have to try.

As I build more and more side projects I find myself wishing pyramid were just a bit more opinionated so I could get the basics up and running a tad faster. At this point I mostly cut up old projects and port them to each next one, heh

One of the off-putting remarks I get is, "what is this, a pyramid scheme?". I don't like the name, they should have stuck with Pylons.

If like me you really liked the slides, this is the framework/engine https://github.com/shower/shower

The theme is one of the included ones, Ribbon.

WebSauna looks promising: https://websauna.org/docs/narrative/background/intro.html

Offers Django feature parity with best of breed components.

You'll get Django parity with Pyramid modern design patterns.

If you have any questions please pop into the chat http://gitter.im/websauna/websauna

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 community as Django, most developers would need to see major gains in one or more areas; performance, docs, community, coding efficiency, etc.

Pyramid doesn't offer these gains. It only makes promises about maintainability, which are hard to verify, unless you personally know somebody that you trust as a skilled developer, and who has worked on a sufficiently large enough project in Pyramid to make such claims... it's easy to see how this creates a hole that Pyramid has to dig itself out of.

Also, Pyramid still talks about "supporting your decisions", like Jinja2, etc., as if that's a problem people are still dealing with. Django supports Jinja2 even in the admin now, let alone being able to use whatever you want elsewhere. As a side note, I don't see many Python developers wanting to use anything other than Django templates (for simplicity and separation of concerns) or Jinja2 (for speed and flexibility) these days.

If the argument, in response to the aforementioned difficulty in verifying claims about maintainability, is "well, it's up to you; Pyramid stays out of the way", then the immediate response is that you're better off using Flask or Falcon; the former if you need third-party tools, and the latter if you need maximum raw speed, but still want Python. Both of those frameworks will drastically outperform Pyramid and stay out of your way.

IOW, I don't think Pyramid fills any reasonably sized and easily understood market gap.

1. https://www.techempower.com/benchmarks/#section=data-r13&hw=...

Flask was an April fools joke from Armin that became a serious thing. The thread locals hacks and use of globals is pretty horrible. I do quite like Falcon however if I want something != Django.

http://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/

http://mitsuhiko.pocoo.org/flask-pycon-2011.pdf

What is your opinion of bottle.py?

> However, once you're out of the unrealistic scenarios (single query benchmarks, etc.), it doesn't do that well[1].

I'm curious about the result since it didn't matched my experience. So I proceed to take a look at the source code for both Pyramid's[1] and Django's[2] benchmarks. From the look of it, I feel like there are too much difference in implementation to call this a realistic comparison.

From a quick glance, Django's benchmark seems to contain a little bit of micro-optimization and is rendering JSON response directly with uJSON[3] (which looks to be a lot faster than native JSON module)[4], while Pyramid's benchmark did not seems to go through any optimizations and is returning a list of SQLAlchemy objects that get passed into a custom renderer[5]¹ and render using native JSON module.

So I don't think it's entirely fair to say Pyramid is slow in a real world scenario based on this benchmark alone.

[1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/c8a5...

[2]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/c8a5...

[3]: https://pypi.python.org/pypi/ujson

[4]: http://artem.krylysov.com/blog/2015/09/29/benchmark-python-j...

[5]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/c8a5...

¹ Using pyramid.renderers.JSON here probably make more sense, but to match Django's implementation, one can wrap a serialized JSON into `Response` object.

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 probably would've changed the calculation for me.

I've always thought of Pyramid as the ideal framework, conceptually. It feels like you're writing Python, not Pyramid, which is GREAT. Pyramid only shows up when you say "OK, I have my Python stuff; I need to make this show up in the web browser now." It is entirely unobtrusive. All frameworks should strive for that.

Unfortunately, the vast majority of frameworks take the opposite approach. Django at least used to be an example of that by forcing DTL (is this the abbreviation for "Django Templating Language"?) down everyone's throat, among other things.

I've also been very impressed by Chris McDonough and the rest of the Pyramid team. They're extremely helpful in IRC, they keep up the great work even after spending years as a small/niche framework, and their code is very clean and well-tested, not obnoxious or overcomplicated. It's a tight, consistent framework that stays out of the way and is just there to serve the developer, not to force him/her to comply. It is so everything a framework should be and so everything most frameworks aren't that I can't help but love it.

I haven't done a major Python-based web project for many years (have one in progress, porting a Rails-based site to a Mezzanine-based site, but work on it only rarely), so I'm sure some of this is outdated.

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

Yes, there isn't feature parity between pyramid and falcon.

You have event system, security abstraction, all kinds of overloading helpers for views and internal machinery that falcon doesn't seem to provide at least from my cursory look. Compare the size of documentation and configuration options between both projects.

Also looking at this http://klen.github.io/py-frameworks-bench/ the 5x better speed of falcon seems to be completly made up or occur in some very specific situation. More realisticly it looks like falcon can be 30% faster in some scenarios not involving storage - but for the price of giving you less options.

Which probably means that if you use any kind of storage the difference between those two can be ignored.

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/

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 fixing security issues for ~5 years, isn't a good choice for business. Businesses don't want to tie their internal development and release cadence to an external development team with less than 3 year cycles, ideally 5+.

I've seen it time and again over dozens of companies. There is no time to qualify apps for new major/minor releases. Anything that doesn't have a LTS release story is just not something I can feel good about deploying in my business.

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

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.

While I'd say that's true as a general rule, an aging system requires a disproportionate amount of time as it ages and the diversity of the platforms underlying stack changes and evolves. This is an issue that would grow exponentially worse over time and being as their team is that small they need to consider risk to their user base when choosing the longevity of their product support. It's quite possible they could support normal issues up to 5 years, but what about the '20 year flood scenario' or 'once in a lifetime flood' if you prefer? What if something that level of bad hits near the 5 year mark and the platform diversity is nearing its maximum diversity?

I believe it's better for them to focus on what they know they can do day in and day out regardless of the circumstances and let companies make the decisions that make sense to them.

In a world where the hardware is written off by the business in 3 years though and websites age out at 3 years and car manufacturers are increasingly trying to hit a 3 year model revision mark it seems to me it's not too much to ask that companies investing hundreds of thousands in an application using Django or Pyramid also invest in maintaining it and keeping it modern or perhaps their existing business model needs additional revision too.

Just a thought as the least informed member of HN.

But you think about this in a wrong way - pyramid is a "glue" framework, unlike django.

- request/response (webob) gets its own updates.

- templates get their own updates.

- sqlalchemy gets its own updates Etc.

You WILL get security fixes for most of your application even without upgrading the framework itself (the attack surface for pylons/pyramid itself is smaller than monolith).

By being on a lower version you don't really miss much - the API's are very stable. And 99% of time you can update pyramid version itself without risking application breakage (the chance of it is probably a lot lower than with monolithic framework).

I know about very heavy websites that are still using pylons(precursor to pyramid) in production without issues (8 years now).

... then isn't it not a big deal to commit to security updates?

Sure, as far as i can tell it was always being updated so far - even without written commitment.

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 <100, or maybe even <1000 lines of code. However, a 10k line Django site and a 100k line Django site basically look the same in my experience, and that is hugely valuable.

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.

Well, for what its worth 1.7 ships with new default scaffolds that that have better separation between models,views and templates - and now is a very decent starting point with everything preconfigured for you (certainly much better than starting with flask from scratch in my opinion if you are not really experienced). You do not start with a single file codebase anymore - if you have a moment try it again you might like it.

Not sure why you hate it? It is one thing to say Django is bad at x and then specify x and other thing is to say I hate Django because it its internals are shit and shoot your points like a machine gun. The second approach is not going to be helpful to anyone.

> instead of rethinking/refactoring.

And breaking backwards compatibility

Django is not RoR. Their users rely on being able to upgrade seamlessly.

The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them

When you say "Django is not RoR", are you saying Django doesn't break backwards compatibility but Ruby on Rails does?

If so, I have to very strongly disagree. It's almost mind boggling to me how much they break backwards compatibility as a framework. They usually warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version, but the sheer amount of these kind of changes makes upgrading an infuriating process. Especially when upgrading a large codebase.

If you keep up with releases it usually is quite alright. Switching LTS versions causes a lot of drama indeed. But that is to be expected.

Agreed 1.4 LTS to 1.8 LTS was tricky, but future LTS to LTS upgrades like 1.8 to 1.11 should be easier. From 1.8 onwards, if your code runs without depreciation warnings in one LTS, then it should work on the next.

> warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version

That's exactly how _not_ to break backwards compatibility.

> That's exactly how _not_ to break backwards compatibility.

No, no, no. Backwards compatibility means that there are no breaking changes at all - announced by deprecation warnings or not. Think Linux's public API.

That is, by definition, breaking backwards compatibility. I.e., the code that I wrote against version X will not run against version X + n. They just give a warning about it in version X + (n - 1). Backwards compatibility means that my code will run against X + n for all values of n >= 0 without modifications.

How should you break backwards compatibility then? This is about as good a solution I can come up with.

Oh they do break, but it's a much slower process than RoR (as you described)

IIRC the most impacting changes I remember were in Config, replacement of South with a native solution and some timezone issues

The upgrade process of south was pretty shitty.

The documentation was telling something like: Ensure you applied all previous migrations and then start from scratch. Thats not an upgrade path. It may work for standalone web applications, but I have a python project (packaged as deb/rpm package and using the packaged django version of different distributions) that should work with multiple django versions and the user may upgrade the django version at any point.

I had to write raw sql statements to get the mirgration status of south (after the upgrade, without a working version of south anymore) and "fake" apply the migrations of the new native solution.

If you were supporting applications which needed to work with or without South at the time of the transition, the best thing to do was probably ship two separate sets of migrations (one set written for South, one written for Django's built-in migration framework).

Yes, that's what I am doing. The problem is, how to preserve the state of the migrations when the user updates the django version.

How else would you introduce backwards incompatible changes? Especially with the LTS upgrade path that alasdairnicol mentioned I wonder what there is still to improve.

If you want to be backwards compatible, then you "simply" do not introduce such changes, there's no "how", you don't.

A platform that works hard to be backwards compatible does only additions and extensions, and keeps maintaining the old API as well so that old apps run without changes; possibly keeping around multiple depreciated ways to do the same thing (e.g. as win32 does).

It is debatable whether backwards compatibility is worth that cost (and it often isn't), but it's certainly a choice.

Mark it as deprecated, change the documentation to tell the user to use the new function Y instead and the most important part: keep the old api even if it's crufty. Wait for a few years until everyone upgraded and no longer uses any deprecated functions. Maybe make a final LTS release for those who don't want to upgrade. Then and only then should you ever break backwards compatibility.

Wait for a few years until everyone upgraded and no longer uses any deprecated functions.

Then view HN threads of people saying they have thirty-million-line codebases which utterly rely on deprecated functionality and they never ever plan to upgrade or do even basic maintenance ever for any reason ever, and will abandon your platform and completely rewrite in something that treats them "better".

> How else would you introduce backwards incompatible changes?

Not at all. That would have the added benefit of core developers thinking twice before introducing a new API - exactly like it happens with Linux syscalls.

I worked in a C shop for like 8 or 10 years and we never introduced a back-wards incompatible API release. There were a few changes that required all servers to be restarted (not at once) to change network protocol (16-bit fields overflowing, that sort of thing). But it was inconceivable that you'd break something that is working. To be sure, we took a couple of weeks before designing an API, and for no one was the API they wrote and shared with others the first API they designed as an adult. Even when the implementation mutated out of all recognition, the API owner would just do whatever re-coding/re-implementation was needed behind the existing API.

breaking changes get a 2 major version release timeline. that's like 18 months (on average) of warning to update your shit. how could you possibly do this better?

I've upgraded a large (~700K LOC) Django project across several versions (1.5-1.9). I think Django does a reasonably good job of maintaining a good upgrade path, though they frequently break backwards compatibility, and at a pretty fast rate (now 8 months release cycles, which barely gives the community to catch up). Some of the changes like module renames seem pointless from an end user perspective, so it feels like the django core team shovels busywork onto users. I also find their method naming policies annoying, since they don't annotate "unsupported" features in any way (eg with an _attribute, and also some _attributes ARE supported). This makes it difficult to figure out whether you're "staying within the lines" of their support policy. I keep a checkout of the django repo around so I can grep the docs for mentions of a method before I use it.

That said, having started on updating that same codebase to Python 3, the Django team tries hard to provide the KEY thing you need to seamlessly update a codebase: a version which can support both incompatible features. Without this, you need to have one giant branch with a bunch of renames and other changes. They actually introduce deprecation warnings, and have something non-deprecated you can use in the same version. I think if Python core had introduced a version of Python including both versions of all the module renames with deprecation warnings, the community would be much further along on the upgrade path.

> there are some rough corners

content_types, generic foreign keys, and basically any other uncommon use pattern for RDBMS are very rough in django. Tradeoff of their ORM being heavily streamlined for the 90% use cases (typical SQL selects and upserts).

But you can use other ORM if you want, or no ORM. However, the benefits of using Django come mostly from using their highly integrated components, I admit. In any case, we swapped the ORM with our own implementation of the data layer and we are doing fine. I like the API overall, specially class based views.

Yes

Might be easier to just write SQL in those cases

I'd say if you hate it, you should propose the changes and how to refactor. There's only so much people can do and they certainly will benefit from first-time contributors who may have fresh ideas. Otherwise this is just plain complain and nothing else.

In my opinion the user (where user is a web developer) facing layer of Django is among the best I've ever worked with. I will agree with you that the internals are very messy and hard to read and work with.

The overall architecture is sound though. Tight coupling of core components, loose coupling of non-core components. Keep in mind that it's an "opinionated" framework though, so they do safely assume that if you're using django you want to be using its core components as a bundle, and will work with them as designed.

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.

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

Well it has been on the roadmap for around 3 years, and they will have support for Python 2 in active maintenance for the next ~3 years, so I think this is actually fantastic support from the core team.

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.

But the Python developers will abandon v2 sooner or later, so IMHO it's wise to start following the bilingual development guidelines https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef and eventually upgrade to v3.

What are the alternatives? Forking the language or switching to another language look to have a higher cost.

Guide announced at PyCon last year that Python 2's end of life is extended to 2020.

https://www.python.org/dev/peps/pep-0373/

*Guido

(auto-correct)

Yeah no.

I know that there are domains that are mostly on Python 2, and of course you'll always have legacy / unmaintained things lying around. But "zeee majoritie is Python 2.7!!1111" does not become true by some people chanting it over and over again. The simple fact that frameworks and libraries are moving away from Python 2 already proves that the majority does, in fact, not use Python 2. Otherwise maintainers would also be in an approximate majority to block/veto such changes.

>But "zeee majoritie is Python 2.7!!1111" does not become true by some people chanting it over and over again.

Maybe check your language a little? "zee majoritie", "chanting it over and over" etc, gets tired and offensive soon.

That aside, there are actual numbers for Pypi supporting that. What do you have to counter these?

>The simple fact that frameworks and libraries are moving away from Python 2 already proves that the majority does, in fact, not use Python 2.

It just proves that after 7+ years, some frameworks and libs managed to justify porting over to 3 too. It doesn't say much about which is used more.

> there are actual numbers for Pypi supporting that. What do you have to counter these?

99% of Pypi traffic is composed of mirrors and bots. Python 3 toolchains are more likely to use tools like devpi, wheel, and Docker to cache their packages, while Python 2 toolchains are often going to hit Pypi directly.

We're concerned about which version has the majority of users, not about which has more downloads on Pypi.

Exactly. PyPi numbers are totally meaningless. It's commonly used for installing applications (that's how packages like supervisor end up in the top 20) and used in all sorts of CI scenarios.

Every OpenStack build, for example, pulls in hundreds of packages from PyPi.

In terms of real-world use, all of the Python devs I personally know moved to Python 3.

There are some major products like Ansible, that are still only compatible with Python 2.7.

Yea, that really annoyed be about Ansible. You have to bootstrap systems like Ubuntu Xenial which only ship Python3 using the raw tasks.

As seen with Django, they were able to support both. I've been able to support both with the code base to some of my projects as well.

Currently I have one project I'd like to be Python3, but it will involve forking two dependencies (owfs and phidgets) and having them support Py3 (phidgets actually builds and entire python3 tree and installs it and yet you can't import anything from it because it's all python2 syntax -_-)

Python 3 has been out for quite some time. I don't see why everyone is still holding out.

https://docs.ansible.com/ansible/python_3_support.html

> Ansible 2.2 features a tech preview of Python 3 support.

So they are working on it.

We'll just have to see. That's the beauty of this. Don't want to upgrade? Stick with Django 1.11, since you don't want or need new things. It's LTS, so you won't miss out on critical fixes.

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.

Ruby also BROKE A LOT LESS, and offered immediate, tangible reasons to upgrade.

The reasons to upgrade are often dependent upon your usage case. To me, the Unicode improvements are reason enough on their own before you even get into the other great stuff (async work, type hinting, stdlib cleanup, pyc rework, etc).

asyncio is going to be a slow build, as the ecosystem starts unifying around it. But as that happens, we'll be much better off for it.

Ruby offered an immediate 25% performance increase. That's a lot less niche than Unicode.

Unicode is niche?

LOL, "niche", says the english native.

Plus, 25% of performance, while nice, is not really something that would matter for most Ruby projects. They are web projects, and their bottleneck is not Ruby. Same for Python. While I'm telling you, good unicode support in most european countries is a HUGE deal.

But that's not all. Often People thinking about Python 3 think unicode, but for me there are 2 other things that made my life much nicer:

- better debugging. Error handling is a hell lot better, with better and messages, greater granularity, more safety nets... E.g: you can't compare some objects anymore, you have several exceptions to handle file opening, imports are absolute by default, division is what you expects, a lot more operations are lazy, the stdlib has been cleaned manu redundancies, encoding parameters everywhere, etc. - less verbosity. Writting is consistently reduced. You get finner file boilerplate, shortcuts for OO, unpacking generalization, yield from, f-strings, etc.

Now those are things that are not easy to sell. You don't see them as a reason to migrate when you hear about it. But once you used to them, going back to Python 2.7 feels so bad.

It was pretty clear for multiple years that Django would eventually migrate to python3 only. Even regarding library support, I've started going python3-only with my Django projects at the beginning of 2015 and had practically zero problems, as only some esoteric packages were not supporting python3 (and then I wouldn't have used them for client projects anyway, because esoteric).

I still have one customer with a Django/python2 code base. When migrating to Django 1.11 in 2017, that project gets security updates until at least 2020. Plenty of time to gradually transition to py3. I honestly don't see the problem.

Django and most libraries were already working seamlessly 2 years ago

Python 2.7 will EOL in 2020. But I guess even then some luddites will complain how they will have been left hanging

When I started with Python - around 2011ish - Python 2.7 on Windows (with Qt 4) was a reasonable choice. Not much later almost everything I did was on Python 3. No regrets, no looking back, and no missed opportunities.

Python 2.7 will not be maintained by PSF soon anyways.

The Python 2.x EOL was extended to 2020.

I suspect Python 2.x will be extended like copyright.

I doubt it and that argument makes no sense. Copyright is extended thanks to the lobbying effort of huge business like Disney in order to make a ton more money.

Unless you see some big corporate support contracts coming over the horizon for PSF, not to mention they'd have to be worth the money vs the technical debt, I don't think Py2 support will get extended.

Backlash from the tons of big companies still using it will become lobbying to keep it supported. I don't expect them to stop in the next couple years, or the next few, etc.

There's less muscle behind keeping Python 2, but there's a lot less muscle needed to keep it going than to extend copyright.

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.

Yeah thats 3 years for now... thats very little time - especially if you have to migrate old projects.

The same argument could be made for any arbitrary amount of time though.

1 week is not enough

1 month is not enough

1 year is not enough

5 years is not enough

10 years is not enough

20 years is not enough...

Do you really have Python projects that can't be migrated in 3 years?

At some point the line has to be drawn to move everyone forward. Extending the EOL for the last long-term of 2.7.x by 5 additional years is pretty generous.

https://pythonclock.org/

I think you completly misunderstood my comment ;-) And yes 3 years for some projects with small teams is barely enough :)

they aren't screwing anyone, if you want to stay on an outdated version of a language that won't be receiving updates you can do the same with Django.

You're complaining about not being able to use the latest major version of a library when you refuse to change to the corresponding latest version of the language? So you want to stay cutting edge here but not there?

That's illogical and inconsistent. they're providing an LTS release for you. Get over it

Protip: Python 2 is EOL'd in 2020.

Start your migration now.

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

I don't have any projects using Django but they have an LTS model - surely you don't need to update to avoid being vulnerable? Just security patches?

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

Well the new model will have a new LTS every 2 years, with guaranteed compatibility as long as you didn't have any deprecation warnings. So you get 2 years to fix warnings, then a guaranteed working new version. I find it hard to believe anybody is doing anything better in this space.

Django releases tend to add useful features/optimizations, and have very light upgrade effort. Most devs will WANT to upgrade to the latest stable.

If you start your project on the day a LTS comes out, you'll theoretically be compatible with the _next_ LTS, 2 years later, so in some ways it's up to 5 years until you need to change your code.

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 think the project is venerable and I have respect for it in general. It's one of the most accessible major open-source projects for newcomers; like I said, I'm not a heavy user and I've already submitted a couple of patches and had them merged. But issues like this one are worth pointing out.

Is there a deficiency in the test suite? Is the open and accepting nature of the community that I just praised the cause of this issue, because it leads to a bias against thorough vetting? I really don't know enough about the project to know, but it'd be nice if they figured it out.

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.

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?

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.

I put all sorts of asserts in the state machine logic (this is the 'check the return values' part). When sufficiently clever, such checks can confirm a surprising range of high and low level behavior.

The example you gave (wrong number of parameters in an override) would be caught by any sane statically typed language. (Though if you are distributing updates to .so's you need to explicitly check for ABI compatibility)

I had to search for Tox. It seems like analogous tools would be nice for statically typed "systems" languages too, though there is less need for them there (more bugs are caught at build time, instead of after deploy).

Debian sort of does the same thing when it builds packages, but only checks compatibility with current versions of dependencies. It would be nice if they also checked / tracked compatibility breakage (the "not all libraries are good" observation is language independent, and a "n days since we broke users of this library" label would be great).

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

It's like Russian Roulette with your code. Maybe something will break, maybe you'll get off easy!

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

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.

How hard it is to port a C extension? I don't really know the APIs, but is it impossible to transform by a script?

My experience is that it is drastically easier to port C extensions than to port python code itself - the C API hasn't really changed a lot and it's usually very easy to reason about C code due to it being more strongly typed than python.

The only reason why it might be hard is you are unfamiliar with the extension's code and/or C

Not hard. You can support 3 and 2 in the same file without much hassle.

Practical example: https://github.com/zopefoundation/BTrees/blob/master/BTrees/... https://github.com/zopefoundation/BTrees/blob/master/BTrees/...

There are a couple #if PY3K, but not much, really.

I ported a bunch of extension modules, total a couple thousand LOC, and it was pretty much a matter of reading the docs (see guide at https://docs.python.org/3/howto/cporting.html ) and adding a few #ifs. Total time maybe an hour or two.

You're calling code that depends on C extensions from directly inside the request-response cycle?

One possible solution would be to offload this work into a celery worker which can call python2 as necessary.

I code against both Django and Tornado. My Tornado based HTTP servers call C extension while they're handling GETs and POSTs. And that's why I'm staying on 2.7.8 until a customer pays me to port to 3.

I'm curious why 2.7.8? What is preventing you from using 2.7.9+?

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.

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.

That doesn't seem too surprising. E.g. for Tornado, you have tornaduv, a C replacement for the core ioloop running everything.

Replacing hot spots with C is a tried and true tactic. I don't see how django would substantially change that equation.

How many are still at that stage?

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.

Wouldn't the problem be that you're already relying on unmaintained software?

>and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore.

How about millions of lines of code in your company in Python 2, and several Python 2 based services and websites?

Why on earth will you go to Python 3 at huge rewriting costs? To get some fancy syntactic sugar and improved unicode?

Why can't your Python 2 services talk to your Python 3 web app?

Why should I maintain code, servers and libs in 2 versions of a backend programming language?

Because one is essentially EOL?

Well, I'm for user driven EOL, as opposed to top-down, we-know-better EOLining.

And the latter doesn't work so well thus far for Python 3.

If enough people like Python 2 that much, I guess someone else can take over maintaining and developing this language version past the official EOL date.

Like Guido's employer, for example. (see pyston)

I think you see this argument used a lot when it comes to Python 3 about it not working so well. I don't see the maintainers changing their minds about EOL on python 2 so either switch to Python 3 or to another language. There is so much toxicity around the Python community because of people thinking they are entitled to have everyone still support Python 2.

Then don't. Stick with Python 2 and accept that means you're going to stop getting work done for you for free in 3 years time.

Because it is and always has been a sensible middle ground between rewriting everything for every release and never upgrading.

>> and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. > Why on earth will you go to Python 3 at huge rewriting costs?

If you're starting a brand new Django project you're not rewriting anything. If you're rewriting something, it's not really new.

My company is a Django shop and while we have no intention of upgrading Python 2.x codebases to 3, we do start all our new projects on Python 3. It just doesn't make sense not to do it.

Why do you have to rewrite all the code in your company if you are starting a brand new Django project? Seemingly the brand new means it is separate from currently existing projects.

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

Except that there are still some critical packages that aren't on Python 3 yet. Not to mention a lot of functionality breaks even if the libraries do exist, which means you have to code things up quite differently sometimes.

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

Almost everything critical that's still holding out has a good reason for it. For example Twisted is being ported... slowly.

Much of Twisted already works on Python 3 even though they're not done porting yet!

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

For me, the google api client libraries, and AWS Lambda. That last one isn't totally Django related, but we use it for certain service calls, and it'd be nicer to be able to maintain one version of the language across the django app and related services.

We ended writing a service in PHP to use Google's APIs, and are mostly using Scala or JS instead of Python for the Lambda services because this project is basically a ton of unicode mangling, and you can pry Python 3's sane unicode support from my cold dead hands! But the libraries still aren't totally perfect. It just takes on dependency being out of date to screw your plans.

The Google API Client is at least Python 3.4 compatible:

https://github.com/google/google-api-python-client/

I see only one Py3 bug is the open issues. And I think even their ancillary library Python Flags is now officially Py3 compatible, even though there has been a Py3 fork of it for years.

Nice! Looks that was just added in December, prior to that they had a statement saying it would probably work in 3.3+ but wasn't tested.

I didn't mean the one literally called google-api-python-client though (forgot they had that, ha). The googleads-python-lib is the critical one for me. PyPI says it supports 3+, but do one search in the repo for "print" and you'll see that's clearly not true.

Looking through the history, seems like they've claimed support for it for a while. We've tried it twice and had issues both times, though I never tried it in Py2, so maybe it just has problems in general.

I agree on Lambda.

There's a "hack" of running Python 3 on AWS Lambda via subprocess until it's officially supported.

http://stackoverflow.com/questions/36143563/using-python-3-w...

There's a long list here. Feel free to dive in! :) http://fedora.portingdb.xyz/

Included in the list: nodejs, chromium, trac, bugzilla, bazaar

> some critical packages that aren't on Python 3 yet

[citation needed]

Pretty much all critical packages now work on 3, as witnessed by the Wall of Superpowers.

Maybe some django-specific lib is still 2-only? In which case, rewrites/forks should be relatively trivial and I'm even happy to have a look myself.

That argument has grown stale. If the devs of your favorite package are still too lazy to port to Py3 there are bigger issues with the existing code you should be concerned about. 2to3 fixes most everything other than a few incompatible changes to the stdlib API.

http://py3readiness.org/

which critical packages?

https://python3wos.appspot.com/

almost everything on the list has gone green now

1) Super super SUPER old argument (that's completely wrong and out of date FWIW)

2) Let's see some proof of your argument, because many packages and platforms are happily supporting Python 3 now. Put your money where your mouth is.

Still having issues with AWS related packages not being fully ported. A lot of our workflows in Pandas broke. It operates quite differently in Python 3 for certain operations like typing data frames which messed up some of our ETL. Also, more explicit encoding was needed.

Agree. The argument was semi-relevant but on the way out when I learned to program 6 years ago.

If in half a decade things haven't been ported there are more serious issues.

I'm glad they are making a clean break from Python 2 and I hope this pushes other projects in the ecosystem to fix those remaining libraries without Python 3 support. It does get a bit frustrating when things break between Django releases, but they have a good system of deprecating things for a couple of releases beforehand. And at the end of the day, Django is for people who want to build websites, not life support machines... and I think they're doing a decent job of striking a balance between breakage and stagnation.

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 actually gain from upgrading to Python 3 if I'm already "handling Unicode properly" in Python 2? So far it still seems rather minimal at the moment, and the risk of breaking something during the upgrade process (either in my own code or in one of my dependencies) doesn't seem like it's worth the effort.

If everything fine with Python 2 on the current project, why bother to upgrade Django 2.0 which will break the compatibility?

Right, that's more or less my question. (I'm not actually using Django though.)

My feeling is that you want to be using dependencies that are actively being maintained. These probably already support py3 - or there's a newer / maintained alternative available.

What's annoying is discovering that it's a struggle to upgrade to a newer OS because you're using some old python dependency that has some C component linking to some library that you're going to spend a week getting working (and then have to continue to maintain).

It sounds like you might not have too much trouble upgrading anyway. The strings and missing libs are the places most people get caught out and it sounds like you're already handling the worst of those.

If I were you, I'd try switching to python3 and see what breaks. When I did it, it took about a day to get up and running again on a reasonably complex project (numpy, scipy etc). One of the main things I ran into was places where python3 had swapped lists to generators etc (eg, some_dict.keys()[0] no longer works).

That's pretty much true of any django release... you can stay on it if you so choose to. It will get security updates/bug fixes for a bit and then they will stop coming. You're free to stay where you are if you want.

It turns out that most developers have a desire to move to the next version if it's not too hard. There's still COBOL programmers out there too and that's perfectly fine.

Django has made the process as smooth as it can be. You can upgrade to python3 while maintaining your Django version. Then update to the next Django version as a separate step. It's fine to have waited until now. You can keep waiting if you want but it's getting to the point where you should really just do it. It's not so bad.

We switched and python2 --> python3 was bumpier and more work than most Django updates we've done (we've done pretty much every one since 1.0) but it was still entirely reasonable. We're much happier now.

It has always seemed to me that Python 3 was mainly a fix on the philosophy of handling strings, but that it didn't offered a clear practical advantage for programmers already handling strings with care. I don't think there is a practical reason to upgrade to Python 3 in terms of language design. The reason will be in term of survival as the community seems to be willing to follow the Python 3 movement and official support for Python 2 ends in 2020.

Yes, that is my impression as well. In hindsight, it is unfortunate how much it ended up fracturing the Python ecosystem.

There are a lot of reasons to upgrade! There is so much more useful stuff in python 3!

Even if you think you would not use those features, other libraries you may use might benefit a lot from it.

A few features: async/await, lists (and others) use iterators, no var leaking in list comprehensions, super().my_method() instead of super(MyClass, self).my_method(), class MyClass: instead of class MyClass(object):, improved exception handling, required arguments, ", ".join(["etc"]* 1000)

Besides that: a much improved standard library, although that technically not is language design.

Of which the improved exception handling is my favourite.

You could do ", ".join(["etc"]* 1000) in python2 - what am I missing?

ah well, it was just a geeky way to say etc etc etc.... no python3 stuff intended to be used there. Sorry :) This one then, althoug it sort of works in python 2 as well..

", ".join(['ètç']* 1000)

Ha! Sorry about that :-)

What py3 does is it enforces the things that py2 only suggests as far as unicode goes. That means on py2 you can go for the proper handling and if you did do everything right, then py3 migration should be almost boring.

The difference is when you didn't handle all the cases correctly. In that situation Py2 will silently do either the right, or the wrong thing and you'll never know. Py3 will likely throw an extension and tell you where the issue is.

So if you're handling lots of unicode text and think you've handled all the string correctly already - that's the reason to move. Now you'll be sure it's correct. The problem with py2 wasn't so much that it was handling anything badly - it was that the default, easy way was incorrect and just waiting to blow up in peoples' faces. (or maybe just silently corrupt something)

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.

You're fairly certain, but with Python 3 you can be completely certain. That's the magic of it.

Python 2 will allow this to sometimes work, Python 3 will make sure this never works, because there's a bytes/text mismatch. It's nice to rule out entire classes of bugs like this

    from sys import argv
    import json
    with open(argv[1], 'rb') as f:
        json.loads(f.read())

Porting is still difficult. But when we ported from Py2 to Py3, we found a couple issues like this (despite dealing with weird encodings all the time).

Exactly this. When I ported my stuff to Python 3, I fixed many encoding bugs in the process.

You can do this correctly in Python 2, it's just much harder.

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.

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 futures module. Ability to define stable ABI for extensions. New CLI option parsing module. Dictionary-based logging configuration. Index and count on ranges. Barrier synchronization for threads. Faster sorting via internal upgrade to Timsort. Async I/O. Support for spawn and forkserver in multiprocessing. Child context in multuprocessing. Has collision cost reduced. Significantly faster startup. Type hints. Faster directory traversal. Faster regular expression parsing. Faster I/O for bytes. Faster dumps. Reduced method memory usage through better caching. Dramatically less memory usage by random. Faster string manipulation. Faster propert calls. Formatted string literals (interpolated strings). Asynchronous generators. Asynchronous comprehensions.

How much faster might your code run just by upgrading to Python 3? How much memory might you save?

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

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.

https://docs.python.org/2/library/collections.html#ordereddi...

> New in version 2.7.

That's a good point. I didn't realize that it was also introduced into 2.7 at the same time.

You forgot functools.lru_cache. I've found in some Python 2.7 projects you can speed things up with a hacky dictionary-cache, but the proper functools.lru_cache gives better results and is far more flexible.

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.

"I have a Python 2.6 project that has been running smoothly, why upgrade to 2.7?"

If you don't need any of the new features and fixes, don't, that's perfectly fine.

The difference between going from 2.6 -> 2.7 and 2.7 -> 3 is enormous though.

Not if you don't need it.

I meant in terms of work needed to upgrade.

Well, there are some new nifty things, e.g. not having to write u in front of every string or a more pleasant subprocess API or the fact that dicts in 3.6 keep their insertion order which makes debugging a bit easier. It adds up.

But the big one is that Python 2.7 will go away at some point.

> Dictionary-based logging configuration

I believe this already exists: https://docs.python.org/2.7/library/logging.config.html#logg...

Here you go: https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-p...

Good. I've been getting into python a bit because i have an interest in datascience. I'm mostly a Java dev. I have to say the python2/3 divide is a real turn off. Many of the science libs want to use seem to be in 2.7 with no signs of moving.

At least the science libraries have a better reason for staying. They often require bigger fixes of the modules compiled from other languages. Still, it's good to see larger projects moving on.

Which libraries do you have in mind? Numpy, SciPy, Pandas and packages based off them all support Python 3.

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.

> Many of the science libs want to use seem to be in 2.7 with no signs of moving

The most important scientific libraries have pledged to drop support before 2020, and are all python3-ready

http://www.python3statement.org/

Is there any hope of other libraries and OSes doing the same thing?

I used to work on a GUI app in Python. I ported it to Python 3, then switched OSes for various reasons. 5 years on, on Ubuntu Xenial (so new I can't even use it in Travis, but that's a separate whine), I install pykdeuic4 and it's using Python 2. So I've basically abandoned that project for 5 years now, because every time I looked at it I thought "surely Python 3 will be here in a few months, I don't want to port backwards to Python 2".

(Serious question: is there a PPA or anything I can use to get these things for Python 3? I need PyQwt as well as PyKDE)

I've had similar issues with most GUI libraries.

Seriously: if you can, try building your thing with tkinter. It's the standard lib, and will "work"

I'm not going to port to tkinter. I like KDE, I like Qt Designer, and I have a working GUI. If tkinter is the only thing that works in Python I'll abandon the language (I mostly work in Scala these days anyway) and find one with working Qt bindings.

Just use C++ and your Qt bindings will never go away!

Qt is a point in C++'s favour, but not enough to outweigh the downsides of the language.

Could you write your UI in c++ with custom bindings and have the rest of the app in python?

Qt's binding support has been it's biggest issue since forever.

Maybe, but I like using Python for the GUI too. It was really nice back when it worked.

A project you might be interested in is libui (https://github.com/andlabs/libui). I can't comment on it because I haven't used it and it's still quite young but it looks promising, it's on my radar to learn soon. Native widgets and written in c so the bindings should be stable. I've never written bindings for c++ but I'm guessing it's not easy because all the c++ toolkit bindings are unstable.

It has quite a few bindings already, here are the python ones: https://github.com/joaoventura/pylibui .

What! There are no downsides to the language! I jest

I love catching errors at compile time, not runtime :-)

Plus, it runs faster

I like catching errors at compile time. But C++'s unchecked manual memory management introduces more errors than the rest of the language eliminates, undefined behaviour turns all bugs into security bugs, there aren't first-class sum types (std::variant is finally on the way in but seems quite restricted; std::visit, while much better than what came before, is pretty cumbersome), and templates are cumbersome in syntax (and error reporting) and not as safe as they look thanks to partial specialization (which will be fixed by concepts if they ever actually make it into the language, but, well...). Along with plenty of less immediate problems (e.g. the lack of a module system).

If there were an ML-family language with good Qt support I'd use that for my GUIs - I use ML-based languages for almost all my non-GUI work. There's plenty I dislike about Python but it's still the best desktop GUI experience I've found.

Have you tried python3-pykde4? It seems to contain a pykdeuic4.py file.

No - but you've set me on the right track, there looks to be a pykdeuic4-3.4 executable (I had assumed if there were anything like that it would be a case of update-alternatives, but apparently not?). Will try that when I get home.

In general, I've found that Ubuntu versions of the last 1-2 years support Python 3 fine, you just have to use the "python3-*" packages.

Fair enough. E.g. I was assuming the reason PyQwt didn't exist for python3 was because Ubunty hadn't packaged it, but having looked further it seems the library itself is unmaintained.

Is Numpy on that list?

Yep:

  % python --version
  Python 3.5.2

  % pip install numpy
  Collecting numpy
      Using cached numpy-1.12.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
  Installing collected packages: numpy
  Successfully installed numpy-1.12.0

That are dropping Py2 support, I mean.

The most important scientific libraries

Not numpy, scipy, tensorflow...

I am data scientist who uses both pythons and the only lib I had issues with was the first release of tensorflow (and that was fixed very soon). Otherwise I find it hard to believe that there exist any maintained libraries that do not support both versions.

I do a lot of data science/ML work and it is almost exclusively done with Python3 so I'm not sure what libraries you are referring to as I haven't had any issues.

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.

Is anyone going to talk about what this means for Python and Django? I read the first 30-40 comments and they are all about off topic stuff related to Django, but still the core premise is the committed move to Python 3.x going forward.

What do people think of that?! I'm a newer dev and I'd really really love to hear what people think of that and what it means for the future rather than side conversations about how bad their API is, how good it is, how good their Docs are and how bad they are.... Blah blah.

Please!! This community is filled with some of the most brilliant minds and I for one don't want to miss out on this chance to hear what people think of this change.

Please please don't reply that you disagree with my POV. That's irrelevant, but please do if you are interested in the initial topic. I'd be be very excited to hear your thoughts.

So Django moving to Python 3.X Go :)

First, this is a good thing for the community. The ecosystem has been pretty well prepared for 3.x adoption for a while, but we just haven't done it. Still, when Django switched its default docs to use 3.x instead of 2.x, it noticeably increased adoption of 3.x. (Source: Kenneth Reitz on "Talk Python to Me" episode #6.) By pushing on with 3.x, Django is doing its part to drag the rest of us forward with it.

Second, this is necessary. Support for Python 2.x is supposed to end in 2020, per Guido's keynote at PyCon 2016, so Django is going to have to get in line in ~3 years one way or the other. A major version increment is a great time to introduce such a breaking change.

So ... "what this means" is that Django is doing what it has to do, which happens to coincide with the interests of the community at large. shrug I'm glad it's happening, but there shouldn't be a whole lot of drama or hand-wringing here.

This is a nice patch [1] to review for Python coders. Seems to me that most incompatibilities are provoked by the unicode transition.

[1] https://patch-diff.githubusercontent.com/raw/django/django/p...

There are only two possible opinions here:

A) You mostly have Python3 projects: Then you like it because you know more ressources will be spent on your pipeline and having more Py3 packages is also helpful.

B) You still have Python2 projects: You hate it, because it pushes you out of your comfort zone.

But I have to say, we want our langauges to develop as well. We want our packages to get attention. And there was lots of time to switch and experiment with switching. Ergo, it should happen. Even if you don't like it as much, that's where things are heading. Deal with it, move on. Let the community help you, if necessary.

The related django issue is here: https://code.djangoproject.com/ticket/23919

there are lots of other cleanups happening right now. It's a real pleasure to look at the diffs :)

I hope they just find a way to support SQLAlchemy natively like they did with Jinja2 because Django ORM is really very restrictive and has numerous serious annoying bugs that have been open since I was in high school.

> 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 the time it's adequate.

Are you sure you didn't mean "features I wish it had"...?

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.

reddit discussion at /r/python : https://www.reddit.com/r/Python/comments/5otufg/django_20_no...

Time to introduce Python 4.

Running on the same VM as Perl 7?

I'm still waiting for Python 3.11 for Workgroups.

This is great news. It will help move people off their python 2 code bases even more. Kudos to the Django team.

Oh boy. And here I am still using Py2.7 with Django 1.6

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.

I still have a project on 1.2!

Yikes! I thought we were bad with 1.3 (for a major UK business micro site)

Because incrementing version numbers is free, Django might as well bump the Python-3-requiring version number to Django 3.0.

Lots of beginners and low-attention devs will find "Django 3 needs Python 3" easier to keep straight than "Django 2 needs Python 3".

I was surprised to see the elimination of the encoding comments, I thought that the default encoding would be platform dependent. After a little research I found PEP 3120 which mandates UTF-8 for everybody, implemented in Python 3.0. It also goes into the history of source encoding for 1.x and 2.x. I wonder why there aren't more problems with Windows users whose editors don't use UTF-8 by default?

Makes sense given Python 3 lets identifiers contain non-ascii characters, e.g. café=123, 变量="x"

I'm all-in on the usefulness of UTF-8, I wish there was a way to configure Windows to reliably use it as its default character encoding. If I create a file with Notepad containing the line café=123 and save it without specifying an encoding, I can't import it into Python. I spend a lot of time on StackOverflow and I don't remember seeing that problem come up.

Good, it's about time this nonsense ends.

This is the beginning of the Python 3 nonsense, not the end yet. It will end when the Python 3 joke is scrapped and replaced with Python 4 as a SEAMLESS continuation of Python 2.

Don't know why you were downvoted: still waiting for a seamless Python X upgrade as well, without code duplication.

It already exists, as a Python2 fork: https://github.com/naftaliharris/placeholder

This is the greatest thing ever - for systems work, python3 is a nightmare. Thanks for sharing this.

What's special about "systems work" that makes python3 worse in your experience? (also, was is "systems work" for you, since I might be misinterpreting that -> I am assuming "low-level unix scripting" or something like that)

In my last three companies, the bulk of the infrastructure was defined and managed via Python scripts (a lot of this predated Ansible being great), so what gets forgotten is the literal billions of lines of custom wrappers and classes that are broken, usually on the print statement v function debate or how string formatting works. I can't justify hiring someone to dig through all that code just to bring it up to snuff and everything needs tweaking. Usually we end up just writing new code in another language and call it from python or the other way around. I can't seem to get comfortable handling both versions in one project without getting REALLY frustrated. So, yeah, a fork with the niceties from python3 that allow my tech debt to still run (and hopefully better), allowing me to replace bits (likely into non python languages - Go is growing on me) at a time and not en masse is pretty frikken awesome.

This is a terrible idea, please don't use this.

Can we expect the async/await introduced from Python 3 for async request handling or maybe some heavy operations ? Something like sanic: https://github.com/channelcat/sanic

It seems like that'll come, but that it'll cause some issues with some WSGI implementations.

https://www.reddit.com/r/Python/comments/5otufg/django_20_no...

Say good bye to django.utils.six. yay

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.

Please, don't tell me how "Python3 is good" - I know everything. I just still don't approve the way the transition was made - if we got to Python 3 through progressive deprecation and evolution via python 2.8 and 2.9, we wouldn't be where we are now.

> if we got to Python 3 through progressive deprecation and evolution via python 2.8 and 2.9, we wouldn't be where we are now.

You mean exactly like Django's progressive deprecation and evolution that you're complaining about in your parent post?

No, he means language level progressive deprecation and evolution, as opposed to an abrupt jump to a changed 3 from 2.

The Django project has added Python 3 compatibility in Django 1.5 as experimental. It remained experimental in 1.6. It became supported in 1.7. They announced around that time that Django 2.0 would only support Python 3.

Then, they released a first 3.x compatible LTS with Django 1.8. Then they released 1.9, compatible with 3.4 and 3.5.

They then release 1.10. And they are releasing 1.11 soon as an LTS, which they previously announced would be the last in the 1.x branch and the last to support Python 2. It will be supported for AT LEAST THREE YEARS after its released.

Good lord. If the deprecation and evolution gets any more progressive, it'll compete with darwinism. And yet, alanfranzoni complains about it. And YOU COMPLAIN ABOUT IT elsewhere in the thread, saying they're "screwing their userbase" and "leaving their users in the dust".

Don't you think you're being a little fricking entitled? This is an open source project and they're doing quite literally everything right.

I couldn't agree more. This transition and their release management in general has been handled excellently for years. Anyone complaining here is quite literally whining.

You talk as if Python 3 were a dialect of Lisp. It's still Python, looks like Python and feels like Python. In fact, I think most of my Python 3 code runs on Python 2.

You talk as if the switch doesn't look like a bunch of arbitrary decisions made on the appearance of purity. If more of an attempt had been made a maintaining compatibility, there wouldn't be nearly as much fight. Python 3 becomes a bit uncanny valley for me when I try to code in it and I tend to use a different language as there less of an internal code switch, especially as I still have to maintain large numbers of python2 code.

They got rid of a lot of cruft that's with us since 1.5.x. Python 3 is a great language, much better than Python 2 when you explore the differences.

The truth is, it's Python. I'm not looking for a great language, I'm looking for language that'll help me get work done... quickly and not give me a migraine if I have to come back to it (Perl). The 3 changes are just big enough to catch me (and every other Python programmer I've worked with) so that I can't just program, which tends to push me towards keeping it in 2.7 or switching to another language, where the similarities don't exist to pull me into bad habits. The whole mess really sours me on the language that made me love programming again.

Or if they had called Python 3 a different name, and let both branches evolve freely and compete.

This sounds like a fork. Nothing need stop someone from forking and maintaining CPython 2.x. Open source is a do-ocracy.

But I doubt it'd be worth it. Python 3 is getting great traction and is a fundamentally better language.

>This sounds like a fork.

Python 3 is already a fork.

It's a major release.

Pretty much the only people that are working towards splitting the community are people like you, who spread FUD and sprinkle snide, bitter and wrong remarks across threads.

Notice how I made a pragmatic observation (that it's already a fork), which one might agree or disagree with, and you went for name-calling about FUD, snide, bitter, "people like you", etc.

That's, like I said, my general observation from reading like a dozen comments from you just on this item. You're literally bickering on about this in pretty much every Python-related item on HN. It is very hard not to notice your comments if one frequents this site. I stand by my comment above.

>You're literally bickering on about this in pretty much every Python-related item on HN.

And others are bickering for the opposite opinion, so?

Did someone die and gave you authority on what others should think about Python 2 vs 3 transition?

>It is very hard not to notice your comments if one frequents this site.

I guess tolerating the presence of a counter opinion is hard. That said, it's a open discussion, and the comments are not directed at you in any way. Maybe skip them if they upset you?

Python 3 is already a fork.

The problem is that Python 2 cannot evolve freely alongside Python 3, because even if someone wants to maintain it and keep releasing versions, the Python Software Foundation won't let them use the name Python (there was a post some weeks ago about someone who actually tried). So there is no free competition between 2 and 3. 2 has been basically killed by a decision from above.

Don't get me wrong, I'm no Python 3 hater. In fact, I have some projects in Python 3 and I would leave Python 2 if I could. But I, like many people, have to code stuff that has dependencies on Python 2, and the way they have handled the update bothers us for no good reason. In fact, the whole schism fiasco is making me use less Python and more Java, where my stone-age code still runs, lately.

Python 3 is not a fork. It is a major release. A continuation of the same language, by the same people, with very little change in the core concepts. A major release with some backward incompatibilities doesn't constitute a fork.

The previous version is being sunsetted, as is common for legacy software. By the time 2.7 is EOL'd, it will have enjoyed a decade of active development and maintenance. That's just one version of Python.

If there were a compelling enough argument for a fork, it would happen and a new name would be chosen. But alas, it makes very little sense for the wider world.

It's not difficult to write software that works with Python 2 and 3. It's just becoming less and less worth it, as evident by announcements like this Django 2.0 one. The scales have tipped towards Python 3.

> the Python Software Foundation won't let them use the name Python

That's how trademarks are supposed to work; they must go after anyone using without permission or they lose it.

Or they could give permission.

And have a confusing set of different and incompatible languages with the same name?

People are complaining about Python 3 being named Python because some code breaks under it. That would be hell.

You already have Python 2. This is a continuation of it that is simply closer in semantic to Python 3. How could it be bad if apart from the Unicode semantics the two versions became equivalent?

There is no guarantee the two branches would converge.

Some things that are very useful are backported to 2, but others are just too much work.

The reason you have a trademark is to enforce rights to the name and prevent confusion. If suddenly Python 2.8 would appear it would be easily confused for official release. If it had flaws they often would also land on the official release.

That's why if you want to make a fork you're free to do so, but you need to make a different name. If it's something people desire it will be used, you can't just ride on the popularity of the name. If your fork has different name and is not popular, it means that there was not much interest in it, period.

Some of successful forks:

openOffice -> LibreOffice

MySQL -> MariaDB

ZFS -> OpenZFS

The Python Software Foundation are the people who have earned the reputation that the name "Python" has - they're the ones who get to use it. And their judgement is that Python 3 is the future of Python. A fork under a different name can earn its own reputation based on the technical merits of its decisions.

Py2 or PyClassic. They don't own those, and they sure could link to python to py2/PyClassic for people who want to install it. They don't own the letters py.

Python 3 is the evolution of Python 2.

Making the transition more "progressive" would just decrease the incentive of developers and companies to move even more.

Ultimately, they are the ones who maintain, care for Python and have grown the community to its current size. I totally respect their decision. Even if py3 was complete useless, I would just stop using python, not complain about how they are not doing things the way I like it.

What would you do in 2.8, 2.9 that 2.6, 2.7 didn't achieve? 3.0 was released almost at the same time as 2.6, and together with 2.7 they got a lot of backported 3.x functionality. Sounds like what you're asking for.

If anything, the transition was too progressive.

The Python ecosystem would have been better served if they killed support for Python 2 much earlier, so that we can avoid wasting time on this tired debate, and more time writing useful code

I think whatever goodies Django 2.x will have, they'll be backported to 1.x by somebody.

At my last job they were still using Django 1.6 when I quit last year. Updating to a new version takes a lot of manhours. Rewriting the codebase in a new language (which basically what Python 2 -> Python 3 transition is) would be completely out of the question.

> Rewriting the codebase in a new language (which basically what Python 2 -> Python 3 transition is) would be completely out of the question.

Not even close to rewriting in a new language. In my experience upgrading from django 1.6 to 1.7 is a bigger change than python 2 to 3

Yep. I've done 1.6->1.7->1.8->1.9 at my current workplace and 1.6->1.7 with Django migrations was the biggest one by a long way. The documentation for upgrades is great too.

Python 3 is a seriously misguided project. It's got tons of newer-to-Python fans (your HN downvoter demographic), and tons of silent-majority "real-world" users especially in scientific programming who just don't like it. I moved to 3.4 a year ago and, as a data scientist, I have to say I find nothing in 3 to be better than 2, other than the extremely marginal default float arithmetic. I may be wrong for web development etc with asyncio whatever, but for me all I get from 3 is Unicode and xrange cruft that simply complicates my code for zero benefit. Personally am hoping that something new emerges that will take over from Python altogether as the default in data science, or that some big entity will sponsor a fork of 2.7 to shutdown this ridiculous "eol" dictatorship.

So what you're saying is that Python 3 changed some small stuff that you see no benefits in, but moved a year ago, and you're now on Py 3.4. And because of that small no-benefit update, you want to move to completely different language that will start with: no scientific libraries, no community, and will likely require rewrite of everything you work with?

Where's the benefit in doing that?

the benefit is that all the wasted energy that went into all the useless 3.x stuff, could have been spent on advancing Python's speed, multicore, or GPU programming capabilities. Instead, for the single use case where Python is clearly the dominant language (for pure network-effect reasons), namely scientific programming, we have been at a standstill for years. In other words, under current stewardship, Python is going down a path where I don't see a long term future for it in my domain, and therefore, I am looking elsewhere already.

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 is particularly true given that Go is rapidly eating Python's lunch in all non-science use cases.

For me Python 3 is worth it just for the time I no longer have to waste in fighting Unicode errors. Obviously, YMMV.

This. Not having to deal with “UnicodeDecodeError: 'ascii' codec can't decode byte” at random places and times is a godsend.

> 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-and-gloom subset of the userbase. Most of us are thankful that Python is striving to improve, and that we continue to pay nothing to use it. The alarmists are far more noisy than those that are happily continuing to build stuff.

Python will remain massively used in the sciences. It's simple, easy to learn, expressive, and has an excellent ecosystem of modules (which now mostly work on Python 3).

Except that personally I see the benefit of Systemd every time I boot my linux computer. It just works, fast, and clean. I don't partake in the philosophical arguments. I just want it to work. Py3 by contrast, simply throws cruft curveballs at me. No tangible benefit. This is not a systemd-style issue.

And yes Python will likely continue massively to be used in the sciences, 3 bears like me notwithstanding, so it would be good if the current stewards would actually recognize the fact that this is their core base of users and please could they focus on them instead of the web people who are much more fickle and moving already.

> core base of users and please could they focus on them instead of the web people who are much more fickle and moving already.

Ahhh, I see what's going on now. You may be vastly underestimating the size of variety of the Python userbase. This is one of the absolute most popular languages on the planet. Your science subset is but one of many. And it's not even the biggest if we're talking sheer user counts.

Python must be steered for the good of the majority of the userbase. Not just for vegabook. The fact that you described them as "useless" to me just speaks to someone being impatient and dismissive of a ton of excellent work by the contributors. These changes weren't made just for the hell of it. Particularly the Unicode example that you gave above.

If you want help understanding the rationale behind some of these changes, feel free to ask here. Someone with more familiarity will chime in and help clear up the confusion or angst.

Directly from core devs: https://snarky.ca/why-python-3-exists/

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

Not denying that Python was/is big in web, but point is that other languages now do that better, which is not true of science.

>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 PyPi stats and everything we've seen), and that's after 6+ years that Python 3 had its chances.

PyPI stats are massively inflated by automated deployments, and anyway even them show a clear rising trend for 3. Also, 3.4+ (from 2014) is a very different beast from 3.0, and it's probably not a coincidence that porting significantly accelerated after its release (about 3 years ago).

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

Interesting that you're looking for those improvements in CPython. From your list (IMO): speed and multicore are going to stay where they are in CPython - GIL is unlikely to be removed, because it's basically part of the behaviour right now. There were a few attempts, but it seems nobody even tries anymore. (and I'm fine with that) Maybe pypy, grumpy, or others will do this instead.

I'm not sure why you expect GPU from the python itself though. That's completely up to libraries and they can exist for either 2.x or 3.x. Was there ever a CPython GPU related project?

The GIL is encoded into practically every C API of the interpreter. It's not going away in CPython, and at the very least any Python implementation supporting CPython extensions will have a global lock for calls into extensions.

And even if (there were patches for removing the GIL already around in the 90s): All of the approaches and patches shown so far significantly degraded single-threaded performance, which matters to way more applications than the GIL, which typically is not a significant limit to using multiple cores/processors.

"Teh GIL" is a very, very overblown issue, and is -- I don't want to be condescending here, but well -- usually brought up by people that have little experience writing software that makes effective use of multiple-many cores.

Yeah, you are a bit condescending here. Part of the topic was multicore. If you're interested in actually cutting down the data transfers without resorting to explicit shared memory, GIL and threads are very much on topic. Whether it's an overblown issue depends specifically on your workload and reasons why you're still using python if you care about multicore.

Actually, between PyPi and "The Gilectomy", there two serious projects to get rid of it, the latter with core developer support: https://us.pycon.org/2016/schedule/presentation/2101/

I attended this talk, and it was really great. PyPi is pursuing software transactional memory, which is massively difficult to implement. The Gilectomy approach is much more community oriented, and focuses on the transition.

Put a bit differently: it's easy to remove the GIL safely, it just incurs a non-trivial performance penalty and breaks C extensions, so the Gilectomy effort is around a combination of removing or avoiding that penalty if you're not multi-threading, and smoothly transitioning C extensions. After that talk, removing the GIL looks inevitable.

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/wide build" distinction (same release). That's about the only every-day advantage I can think of. But I suspect that's too technical, or do you mean that?

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.

"With dynamic typing, the runtime will not warn you, which means you won't know until some crap data comes and your code chokes. With static typing, you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible."

See what I did there?

toyg, I found your comment unbearably rude, condescending and arrogant, and downvoted it for that reason.

> See what I did there?

Confused your terminology? With static typing, the compiler will warn you, not the runtime.

Regardless, the difference is that in practice, file-handling boundary calls don't need to be as flexible as internal interfaces, and it's obviously much more difficult to figure out what The Right Thing To Do is in the latter case (or whether there is a Right Thing at all, in a lot of cases). How many times do you need to change the encoding you use for writing files? How many times do you change an internal class or type? They are totally different ballgames.

> I found your comment unbearably rude, condescending and arrogant

Apologies, but after 8 years and countless hours of bickering on this point, patience can wear really, really thin.

Have you considered that if you find yourself debating for 8 years without success, you're debating the wrong side? :)

Yes, Python 3 is an improvement over Python 2. I like Python 3. No, Python 2's unicode support was fine, contrary to OP's claim.

It's actually easier for people outside of US, who are forced to deal with languages that require Unicode to work properly. If you screw up somewhere, you notice right away.

But those for whom the majority of input is ASCII can often get away with broken code (that e.g. writes out Latin-1 JSON) for a while. And then they get input with a word like "naïve", and oh look, all hell breaks loose.

Python 3 solves this problem by making every transition problem explicit, requiring the developer to stop and think what they're doing when going from byte representation to strings, and vice versa.

"Explicit is better than implicit."

To me, unicode alone was worth the switch. I will go to great length to avoid the hell that is unicode in Python 2.

Besides speed, I never seen any good argument that would make me start a new project on 2.7, rather than the latest v3 release. I get that there was a series of data science libraries that wasn't supported initially, but seems to have been solved at this point. So I really do see why people continue to hate Python 3.

I'm not going to argue that the transition couldn't have been handled more smoothly, the period of broken libraries and terrible performance was a little too long.

>Besides speed, I never seen any good argument that would make me start a new project on 2.7, rather than the latest v3 release.

That's because you start "new projects". Some of us have 10+ years of codebases to maintain, and we don't care for Python 3 features...

If you don't care about the Python 3 features, then don't migrate. I suspect that the issue is that you want at least some of the features, but the cost of moving 10+ years of Python 2 to Python 3 just aren't worth the benefits of those new features.

While I do believe that your point is still valid, one also have to accept that Python 2 will be a legacy platform at some point. In the long run I don't view that as much different than people complaining about Visual Basic 6 being deprecated.

Python 3.0 was released in 2008. Python 2 will EOL in 2020. You've had about 9 years to start the transition to 3.0, and you still have 3 more years before EOL. A 12-year upgrade window sounds pretty reasonable.

>You've had about 9 years to start the transition to 3.0, and you still have 3 more years before EOL.

Most of those years library support was non-existent or lacking. And still today the majority uses Python 2.x (Pypi stats).

So it's not like the migration was some great success since the start, and all those years were just wasted by some minority not migrating.

In the end, it's not a discussion on HN or what the "BDFL" says about an official EOL that will settle the matter, but actual adoption in the field. But in addition to the low adoption rate, we've even seen people leave Python for Go and Node/JS.

I think I know the chart you're referring to, but I can't find it. I remember Python 2 was in the majority in that case. Do you have the source handy?

For what it's worth, as someone who ha been working with Python for 11 years, Python 3 is a huge improvement over Python 2 and is certainly very popular with my peers.

The fact that you personally weren't particularly affected by the problems in 2 doesn't mean the problems weren't serious.

and the converse applies.

> It's got tons of newer-to-Python fans (your HN downvoter demographic)

Please don't make generalizations about people who disagree with you just to score a rhetorical point, and please don't break the HN guidelines by going on about downvotes: https://news.ycombinator.com/newsguidelines.html.

I disagree, I think Django dropping support for 2 will actually push more open source projects to do the same. This will create the momentum and incentive necessary to nudge people over the edge and upgrade.

There is an awful lot of hyperbole around the difficulty of upgrading from python 2 to 3, however with the latest changes in 2.7 and 3.6 the gap isn't as big as you expect. I converted our (admittedly not massive) 35,000loc Django project from 2 to 3 in about four hours, starting with with 2to3 tool then working though test failures it wasn't nearly as bad as I was expecting. Most of the issues were as I expected around the new string handling, but as soon as something broke, I knew before looking at the code what the problem was.

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.

>There is an awful lot of hyperbole around the difficulty of upgrading from python 2 to 3

+1. IMO this is the 2nd most overblown python issue next to the GIL.

It's also not actually that difficult to maintain code that works on both.

Upgrading Django OTOH has caused me quite a bit more pain over the years.

Very true, upgrading from 2 to 3 was an easer change than a couple of the last Django upgrades - and we are doing those every 9 months...

> forces [...] to offer two versions [...] the same is happening for Django!

That's not what the announcement is about. Django worked with python 3.x for a long time already. Now they're actually going to drop 2.7, so back to one supported version.

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.

EOL was extended once. Why not twice? Why not every time Mickey Mouse is about to enter the public domain?

>Some corps may continue to do so

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

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

Sincerely, the only "poor evolution strategy" from Python developer team was that they continued to support Python 2 long after its initial expire date after announcing the Python 3 roadmap.

The support should have been cut a long time ago and now we wouldn't be having this discussion.

Seriously? The entire change to "unsupport" the majority of Python code is a mass delete of from __future__ import unicode_literals and utf-8 encoding? Is that really the extent of the "too difficult to maintain" code? There will be a split.

Just one step. https://code.djangoproject.com/ticket/23919

Gotcha. Thanks for the clarification (actually 2 of those steps). This is a great reference.

Also factor in halving the on going QA, testing and environment dependent bug fixing efforts.

Oh my god stop. You're all over this thread. What bit you?

This is the price you pay for staying on an old version. You do not get to stick to an old version AND demand that others do too.

You CAN stay on Python 2. You CAN stay on Django 1.11. It's LTS. So is Python 2.7. You get to use both until 2020 with no issues. After that, not upgrading is a technical debt that will start to accrue, faster and faster as you can no longer use recent versions of various software.

You are free to make your infrastructure immutable; you then become responsible for it of course. And the money you're not willing to spend porting to Python 3 today will be money you spend on costs related to being on outdated infrastructure, years in the future. That's a tradeoff. Banks do it a lot I hear. A bunch of companies still use ancient hardware and technologies nobody would think of starting a business with today. These companies make billions.

You know what the employees of these companies aren't doing? They're not bitching on HN that the tech they're using is no longer supported.

>Oh my god stop. You're all over this thread. What bit you?

As someone who has 6 comments in this thread yourself, I don't think you are in position to complaint.

I also find "what bit you" and "please stop" rude. You don't get to dictate what others opinion should be.

>This is the price you pay for staying on an old version. You do not get to stick to an old version AND demand that others do too.

7+ years on and the "old" version has more users than the new one. That's a fact supported by numbers. So maybe you want to recheck with reality whether the transition was a success instead of arguing with me?

Not all transitions go well, the Perl 6 transition killed Perl, the PHP 4 to 5 transition (another major one) went quite smoothly.

> As someone who has 6 comments in this thread yourself, I don't think you are in position to complaint.

This isn't a numbers contest. Unlike yours, none of my comments are shitting on the efforts of volunteers that are doing their best to keep people like you happy and making money using a project you're not paying for.

> So maybe you want to recheck with reality whether the transition was a success instead of arguing with me?

You completely missed the point.

> making money using a project you're not paying for

says who? It this the standard FOSS strives for?

Where do you get the idea that it's OK to "demand" things from a project when you're not paying for it?

FOSS gives you freedom to do these things on your own. Money gets you other people doing it for you.

Why is "demand" in scare-quotes? I never said that, and it's a loaded term.

The issue here is suggesting you shouldn't freely criticise flaws in FOSS software. This is harmful, and goes directly to affecting information people have available to them in choosing whether or not to use a piece of software in the first place.

Do you actually know what money/time OP might be spending, losing, or making on Django?

> FOSS gives you freedom to do these things on your own. Money gets you other people doing it for you.

What a cop out. A lack of being paid (money at least) doesn't imply no obligations, nor freedom from criticism.

Do you speak for every Django contributor?

> Why is "demand" in scare-quotes? I never said that, and it's a loaded term.

Because I was referring to coldtea's demands.

> What a cop out. A lack of being paid (money at least) doesn't imply no obligations, nor freedom from criticism.

Excellent, then you should be fine with me criticizing the attitude that's been displayed here.

> The issue here is suggesting you shouldn't freely criticise flaws in FOSS software. This is harmful, and goes directly to affecting information people have available to them in choosing whether or not to use a piece of software ion the first place.

Why is this the conclusion you draw from my posts? I said it before, the Python 3 transition sucked. It's something we kind of all agree on. There is plenty of criticism to be made.

However, I really want to recontextualize this: Django is an open source project, maintained by a non-profit. Python is an open source project, maintained by a non-profit. The projects in question, with "tens of millions of lines of Python 2 code" (only a tiny amount of which would need to be ported, but I disgress...), are most often for-profit projects. Yeah, it's a bit rich.

This is the same as the IE6 situation: Want support for it? Pay extra for it! You should not expect free support for technology for which the EOL was announced years in advance just because you're using a lot of it. And you will have no issue finding paid support. Heck tell you what, if you do, shoot me an email, I do contract work sometimes.

You know why FOSS is great? It's great because the PSF/DSF do not get to revoke your license to use the software they're no longer supporting. You get to use it forever. This is your freedom and it's a good one. Make use of it!

Which comments are you interpreting as demands?

>> A lack of being paid (money at least) doesn't imply no obligations, nor freedom from criticism.

> Excellent, then you should be fine with me criticizing the attitude that's been displayed here.

Great. Do you actually have a response to this point in context, then?

> This is the same as the IE6 situation: Want support for it? Pay extra for it!

You did not argue this. You said "shit on", which doesn't translate to "demanding support". you are deflecting from the one thing I actually criticised.

Your strawman is "support is being demanded" - this isn't the case. Any further arguments on that topic are just beating the strawman.

Furthermore, oficially changing the direction of Django also may affect contributions, changes to the roadmap or architectural design for example.

You're appropriating criticism that was not directed to you, but to coldtea. Here and elsewhere.

Edit: Yes, appropriating. You're taking criticism I specifically directed at coldtea, applying them to your comments and then complaining it doesn't fit. I am done talking to you.

Edit 2: This was not meant to sound as aggressive as it did, sorry.

appropriating? That criticism was general, so what does it matter?

You've been breaking HN's civility rule with bits like "I am done talking to you", "Oh my god stop", "bitching on HN", etc. That's not cool, regardless of how wrong other commenters may be. Please take greater care to be respectful in comments here.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

> You're taking criticism I specifically directed at coldtea, applying them to your comments

Perhaps, can you give an example?

>This isn't a numbers contest.

And yet you complained about my many comments. If you just had an issue with their content, you could have said so instead of that, and with specific arguments not just "stop" and "lalala hands in the ears, I don't want to hear you".

>Unlike yours, none of my comments are shitting on the efforts of volunteers that are doing their best to keep people like you happy and making money using a project you're not paying for.

You don't know what I've paid or what I've donated to the PSF since 1998 that I've been using the language, or what the companies I've worked for have done for Python. So it's not your business to talk about me personally as I've not talked about you. Can you stop being rude and ad hominem?

(And of course, any user who has evangelized, worked with, and devoted time to a language pays the opportunity cost, whether he pays for its development directly or not).

The community of a language's users can, and do, have an opinion on its progress and the changes that happen to it, whether it goes against the ideas of the volunteers working on it, or not (and it's not all volunteers, a lot of programmers are paid by corporations to work on OSS projects, including Guido who was paid by Google and now Dropbox, and that way companies often get a say on the direction a project takes).

> If you just had an issue with their content, you could have said so

I did. I did not think I needed an argument to ask you to stop bringing such an incredibly negative attitude to the table.

> You don't know what I've paid

I was referring to Django, to be clear. And whatever you've paid, it's in donations -- that's great! But if you want to see support, you'll need to directly pay people to maintain that support. I believe in fact you yourself said that before, here on HN, about other tech.

> The community of a language's users can, and do, have an opinion on its progress and the changes that happen to it

"as long as that opinion is the same as mine", right?

I mean, here is one of your comments for example:

> Some of us have 10+ years of codebases to maintain, and we don't care for Python 3 features

This is basically saying "I do not care for python 3 features, therefore Python 2 should continue being supported even longer [because I have an old codebase to maintain]".

The argument in a nutshell is that because the transition is hard, the Python team should just give up on the transition and support both. It's an argument I've heard before. The reason it doesn't hold water is because doing so would completely kill the language, for good.

We all, as the python community, collectively admitted that the Python 3 transition was awful. It still is pretty bad, although it has improved a lot. Could still be better! But now, we're on the final stretch and the remaining complaints are from people in similar situations as you: Large Python 2 codebase to maintain, therefore can't switch, therefore "please give us more time, and by more time I mean just forget Python 3 ever happened and come back".

Another place I've heard that argument is back when IE6 went EOL. And went EOL again. And a third time for good measure. And then MS had to declare it dead for good. It was holding the web back and we've been better since. We had the same sort of people back then, asking for "more time", "more leeway", "more support" and "please add ActiveX back to the web we promise we'll switch eventually". Do I need to give an argument why that didn't hold water then either?

I am sorry that you have to deal with that. It sucks. I've been in this position before (different language) and back then, FWIW, we bit the bullet and we migrated. It sucked for two months, and then it didn't. The longer we'd have waited, the longer it would have sucked. I can only recommend you do the same; it's a good long term investment.

At the end of the day, you can try to pull all the numbers you want, the Python team isn't going to suddenly go back on the plan they've been making very clear and insisted on for several years now. Because it would be a betrayal to the rest of the Python community and would severely harm the language and its future. I do believe it's extremely selfish of you at this point to ask that they cater to the group you happen to be a part of, rather than the overall good of the community.

> But if you want to see support, you'll need to directly pay people to maintain that support

You originally said:

> making money using a project you're not paying for

No mention of support, just "shitting on the efforts of" (IYHO), So it seems you are moving the goalposts.

I didn't move the goalposts? I reworded what I previously expressed. If you want to see support, you can pay people to provide that support. Free support ends in 2020.

If you're not paying for it and you are making money off it, I don't see this attitude as being okay. You can ask. You can also be told no!

Python 2 advocates like to bring up the PyPI download numbers as some kind of "reality". But here is the reality: The PSF, governing body for the Python project, has decided years ago that Python 3 will EOL in 2020. It has given ample heads up for everybody to migrate.

Years. That's the reality. This decision didn't come out of nowhere. Don't expect a yes.

Edit: I am wasting my time replying to you.

> Unlike yours, none of my comments are shitting on the efforts of volunteers that are doing their best to keep people like you happy and making money using a project you're not paying for

This was the line I responded to, and it has nothing to do with support, but with the ability to criticise something you aren't paying for. You introduced the idea that something was being "demanded" so that you could beat up that strawman.

>I did. I did not think I needed an argument to ask you to stop bringing such an incredibly negative attitude to the table.

Not argument or not (and as you said, you didn't think you needed one) you don't have the right to tell me to stop bringing my opinion to the table.

Whether you think it's negative or not, it's not your place to conduct the discussion on HN. Just state your case, and let others state their case. I wouldn't even have left all those comments if I didn't have to defend myself, as most as responses to your demands that I "just stop" and your accusations.

>I was referring to Django, to be clear. And whatever you've paid, it's in donations -- that's great! But if you want to see support, you'll need to directly pay people to maintain that support. I believe in fact you yourself said that before, here on HN, about other tech.

I didn't force anybody to provide me support. I didn't even ask anybody for support for me specifically, and I didn't hold a gun to anybody's head on the matter.

I criticized projects dropping support for Python 2.x, and made my case. Criticizing is not the same as demanding.

>This is basically saying "I do not care for python 3 features, therefore Python 2 should continue being supported even longer [because I have an old codebase to maintain]"

Which is a perfectly reasonable argument, only you omitted the part where I said that the majority of Python users seem to be in the same position (and thus such a drop could be bad for Django itself -- if people are forced to migrated an old project, they might as well bite the bullet and try something else entirely, Node for example).

>The argument in a nutshell is that because the transition is hard, the Python team should just give up on the transition and support both. It's an argument I've heard before. The reason it doesn't hold water is because doing so would completely kill the language, for good.

The transition itself might kill the language, it has already taken far too long with meagre results thus far. It's not impressive that "nearly all popular libraries" have been ported to 3, when it's close to 10 years past 3.x and the majority of users are still on 2.

In any case, there are ways to "support both" that don't kill anything, e.g. making a "merged" Python 2/3 hybrid release that runs both 2.x and 3.x codebases, and is the official CPython going forward.

Or supporting 2.x as longer as needed for 60 or 70% of the users to migrate, as opposed to an arbitrary optimistic cutoff date in 2020, set when people still thought 3.x will get quickly adopted.

>now, we're on the final stretch and the remaining complaints are from people in similar situations as you: Large Python 2 codebase to maintain, therefore can't switch, therefore "please give us more time, and by more time I mean just forget Python 3 ever happened and come back"

Sounds perfectly reasonable. If the largest stakeholders (people with actually large Python codebases) can't speak up, then who can? Newbs that started some small greenfield project with 3.x?

Please see https://news.ycombinator.com/item?id=13436656.

We detached this subthread from https://news.ycombinator.com/item?id=13434460 and marked it off-topic.

A VERY GOOD NEWS!!!

Yea, I know, shouting is not the best thing, but this is a really good news.

Django was designed for making content based sites and CMS's quickly. It wasn't designed for webapps and REST APIs, and it can be used in those cases, but it's not great. I'd look at other options.

Reply on news.ycombinator.com