43 ms·

Removing Python 2.x support from Django for version 2.0

720 points by ReticentMonkey 10y ago

ReticentMonkey 10y ago
reddit discussion at /r/python : https://www.reddit.com/r/Python/comments/5otufg/django_20_now_on_master_will_not_support_python_2/?ref=share&ref_source=link https://www.reddit.com/r/Python/comments/5otufg/django_20_no...
alanfranzoni 10y ago
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.
- alanfranzoni 10y ago
  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.
  - scrollaway 10y ago
    > 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?
    - coldtea 10y ago
      No, he means language level progressive deprecation and evolution, as opposed to an abrupt jump to a changed 3 from 2.
      - scrollaway 10y ago
        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.
        throwawayish 10y ago
        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.
      - rbanffy 10y ago
        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.
        billoday 10y ago
        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.
  - Al-Khwarizmi 10y ago
    Or if they had called Python 3 a different name, and let both branches evolve freely and compete.
    - gtaylor 10y ago
      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.
      - coldtea 10y ago
        >This sounds like a fork. Python 3 is already a fork.
        gtaylor 10y ago
        It's a major release.
        throwawayish 10y ago
        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.
        coldtea 10y ago
        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.
        throwawayish 10y ago
        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.
  - kamyarg 10y ago
    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.
  - viraptor 10y ago
    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.
  - yen223 10y ago
    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
- Grue3 10y ago
  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.
  - shawabawa3 10y ago
    > 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
    - danpalmer 10y ago
      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.
- vegabook 10y ago
  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.
  - viraptor 10y ago
    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?
    - deleted 10y ago
      [deleted]
    - vegabook 10y ago
      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.
- samwillis 10y ago
  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.
  - danpalmer 10y ago
    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.
    - mrfusion 10y ago
      One day sounds impressive. What's your strategy?
      - danpalmer 10y ago
        - 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.
- viraptor 10y ago
  > 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.
- ageofwant 10y ago
  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.
  - JCzynski 10y ago
    EOL was extended once. Why not twice? Why not every time Mickey Mouse is about to enter the public domain?
  - xrange 10y ago
    >Some corps may continue to do so https://www.naftaliharris.com/blog/why-making-python-2.8/ https://www.naftaliharris.com/blog/why-making-python-2.8/ https://news.ycombinator.com/item?id=13144713 https://news.ycombinator.com/item?id=13144713
  - stefantalpalaru 10y ago
    > No core Python dev will support Python 2 after EOL. You say it like it's a bad thing. Core Python devs are terrible programmers. I'm personally rooting for this fork now: https://github.com/naftaliharris/placeholder https://github.com/naftaliharris/placeholder - it's what Python3 should have been.
- jbmorgado 10y ago
  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.
Flimm 10y ago
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/ 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.
- Galanwe 10y ago
  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.
  - nsomaru 10y ago
    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.
    - stuaxo 10y ago
      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).
yuvadam 10y ago
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.
- hueving 10y ago
  Easy to say when you don't depend on C extensions only compatible with 2.7.
  - gkya 10y ago
    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?
    - novocaine 10y ago
      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
    - throwawayish 10y ago
      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/_compat.h https://github.com/zopefoundation/BTrees/blob/master/BTrees/... https://github.com/zopefoundation/BTrees/blob/master/BTrees/BTreeModuleTemplate.c 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 https://docs.python.org/3/howto/cporting.html ) and adding a few #ifs. Total time maybe an hour or two.
    - deleted 10y ago
stevehiehn 10y ago
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.
- viraptor 10y ago
  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.
- jaipilot747 10y ago
  Which libraries do you have in mind? Numpy, SciPy, Pandas and packages based off them all support Python 3.
  - stevehiehn 10y ago
    It believe it was a digital signal processing library. I don't recall the name.
    - rbanffy 10y ago
      You used the word "many"...
      - stevehiehn 10y ago
        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.
- joeyspn 10y ago
  > 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/ http://www.python3statement.org/
karthikp 10y ago
Oh boy. And here I am still using Py2.7 with Django 1.6
- deleted 10y ago
  [deleted]
- Ensorceled 10y ago
  I'm in the midst of upgraded a 1.6 project to 1.10 and Python 3. Wish me continued success :-)
  - karthikp 10y ago
    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
    - Daishiman 10y ago
      This is not a sustainable position to be in. Migrations are product issues.
- mrfusion 10y ago
  I still have a project on 1.2!
  - Vaanir 10y ago
    Yikes! I thought we were bad with 1.3 (for a major UK business micro site)
romanovcode 10y ago
Good, it's about time this nonsense ends.
- jdimov11 10y ago
  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.
  - singularity2001 10y ago
    Don't know why you were downvoted: still waiting for a seamless Python X upgrade as well, without code duplication.
    - stefantalpalaru 10y ago
      It already exists, as a Python2 fork: https://github.com/naftaliharris/placeholder https://github.com/naftaliharris/placeholder
      - billoday 10y ago
        This is the greatest thing ever - for systems work, python3 is a nightmare. Thanks for sharing this.
        detaro 10y ago
        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)
        billoday 10y ago
        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.
gkya 10y ago
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/pull/7867.patch https://patch-diff.githubusercontent.com/raw/django/django/p...
karyon 10y ago
The related django issue is here: https://code.djangoproject.com/ticket/23919 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 :)
nodamage 10y ago
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.
- yy77 10y ago
  If everything fine with Python 2 on the current project, why bother to upgrade Django 2.0 which will break the compatibility?
  - nodamage 10y ago
    Right, that's more or less my question. (I'm not actually using Django though.)
    - aidos 10y ago
      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).
Acalyptol 10y ago
Time to introduce Python 4.
- rbanffy 10y ago
  Running on the same VM as Perl 7?
- disconnected 10y ago
  I'm still waiting for Python 3.11 for Workgroups.
jdimov11 10y ago
Says who?? Someone with delusions of grandeur, obviously. Because that's not up to anyone to say. Python 2 is obviously NOT going away any time soon. You can't just look at reality and claim the opposite just because it pleases you. Python 2 is here to stay and is in MUCH better shape than Python 3, in terms of actual production usage globally. Python 3 is a bad joke that someone wants to force down people's throats for NO good reason at all.
- fallenshell 10y ago
  Nope, Python 3 is a sane upgrade to a sane language bringing many enhancements to the consistency and reliability of Python. And it is being used in many production systems already.
  - jdimov11 10y ago
    Congratulations, you've been brainwashed.
    - scrollaway 10y ago
      Claiming people have been brainwashed because you happen to have a different use case than them is not appropriate for HN, nor anywhere. And speaking to your earlier point as somebody using Python 3 in production, says me. Nobody in here cares whether you in particular gets to see the advantages of the new version; but you don't get to say "nobody is using it in production", you don't get to say it's "forced down people's throats" when there's years-long support for it and you certainly don't get to say "no good reason at all" if you're the only one unable to grasp the improvements the language is getting.
      - jdimov11 10y ago
        Oh, it's not appropriate? Should I go sit in the corner now? Who the FUCK do you think you are??
        10y ago
scrollaway 10y ago
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.
- coldtea 10y ago
  >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.
  - scrollaway 10y ago
    > 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.
ReticentMonkey 10y ago
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 https://github.com/channelcat/sanic
- lewiseason 10y ago
  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_now_on_master_will_not_support_python_2/dcmiiv3/?st=iy4izox8&sh=e27de429 https://www.reddit.com/r/Python/comments/5otufg/django_20_no...
jonatron 10y ago
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.
daveguy 10y ago
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.
- jsmeaton 10y ago
  Just one step. https://code.djangoproject.com/ticket/23919 https://code.djangoproject.com/ticket/23919
  - daveguy 10y ago
    Gotcha. Thanks for the clarification (actually 2 of those steps). This is a great reference.
    - Ensorceled 10y ago
      Also factor in halving the on going QA, testing and environment dependent bug fixing efforts.
belvoran 10y ago
A VERY GOOD NEWS!!! Yea, I know, shouting is not the best thing, but this is a really good news.
myf01d 10y ago
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.
- anentropic 10y ago
  > 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"...?
  - myf01d 10y ago
    such as 1. multi-column primary key. 2. annotate several counts for some query correctly. that what I remember for now.
    - jsmeaton 10y ago
      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.
gigatexal 10y ago
This is great news. It will help move people off their python 2 code bases even more. Kudos to the Django team.
rowanseymour 10y ago
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.
mark-r 10y ago
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?
- rowanseymour 10y ago
  Makes sense given Python 3 lets identifiers contain non-ascii characters, e.g. café=123, 变量="x"
  - mark-r 10y ago
    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.
oliwarner 10y ago
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.
misterhtmlcss 10y ago
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 :)
- spiffyman 10y ago
  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.
erikb 10y ago
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.
gojomo 10y ago
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".
hirokiky 10y ago
Say good bye to django.utils.six. yay

720 points by ReticentMonkey 10y ago

reddit discussion at /r/python : https://www.reddit.com/r/Python/comments/5otufg/django_20_now_on_master_will_not_support_python_2/?ref=share&ref_source=link https://www.reddit.com/r/Python/comments/5otufg/django_20_no...

alanfranzoni 10y ago

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.

alanfranzoni 10y ago
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.
- scrollaway 10y ago
  > 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?
  - coldtea 10y ago
    No, he means language level progressive deprecation and evolution, as opposed to an abrupt jump to a changed 3 from 2.
    - scrollaway 10y ago
      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.
      - throwawayish 10y ago
        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.
    - rbanffy 10y ago
      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.
      - billoday 10y ago
        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.
- Al-Khwarizmi 10y ago
  Or if they had called Python 3 a different name, and let both branches evolve freely and compete.
  - gtaylor 10y ago
    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.
    - coldtea 10y ago
      >This sounds like a fork. Python 3 is already a fork.
      - gtaylor 10y ago
        It's a major release.
      - throwawayish 10y ago
        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.
        coldtea 10y ago
        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.
        throwawayish 10y ago
        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.
- kamyarg 10y ago
  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.
- viraptor 10y ago
  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.
- yen223 10y ago
  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
Grue3 10y ago
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.
- shawabawa3 10y ago
  > 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
  - danpalmer 10y ago
    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.
vegabook 10y ago
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.
- viraptor 10y ago
  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?
  - deleted 10y ago
    [deleted]
  - vegabook 10y ago
    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.
samwillis 10y ago
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.
- danpalmer 10y ago
  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.
  - mrfusion 10y ago
    One day sounds impressive. What's your strategy?
    - danpalmer 10y ago
      - 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.
viraptor 10y ago
> 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.
ageofwant 10y ago
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.
- JCzynski 10y ago
  EOL was extended once. Why not twice? Why not every time Mickey Mouse is about to enter the public domain?
- xrange 10y ago
  >Some corps may continue to do so https://www.naftaliharris.com/blog/why-making-python-2.8/ https://www.naftaliharris.com/blog/why-making-python-2.8/ https://news.ycombinator.com/item?id=13144713 https://news.ycombinator.com/item?id=13144713
- stefantalpalaru 10y ago
  > No core Python dev will support Python 2 after EOL. You say it like it's a bad thing. Core Python devs are terrible programmers. I'm personally rooting for this fork now: https://github.com/naftaliharris/placeholder https://github.com/naftaliharris/placeholder - it's what Python3 should have been.
jbmorgado 10y ago
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.

Flimm 10y ago

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

Galanwe 10y ago
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.
- nsomaru 10y ago
  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.
  - stuaxo 10y ago
    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).

yuvadam 10y ago

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.

hueving 10y ago
Easy to say when you don't depend on C extensions only compatible with 2.7.
- gkya 10y ago
  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?
  - novocaine 10y ago
    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
  - throwawayish 10y ago
    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/_compat.h https://github.com/zopefoundation/BTrees/blob/master/BTrees/... https://github.com/zopefoundation/BTrees/blob/master/BTrees/BTreeModuleTemplate.c 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 https://docs.python.org/3/howto/cporting.html ) and adding a few #ifs. Total time maybe an hour or two.
  - deleted 10y ago

stevehiehn 10y ago

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.

viraptor 10y ago
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.
jaipilot747 10y ago
Which libraries do you have in mind? Numpy, SciPy, Pandas and packages based off them all support Python 3.
- stevehiehn 10y ago
  It believe it was a digital signal processing library. I don't recall the name.
  - rbanffy 10y ago
    You used the word "many"...
    - stevehiehn 10y ago
      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.
joeyspn 10y ago
> 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/ http://www.python3statement.org/

karthikp 10y ago

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

deleted 10y ago
[deleted]
Ensorceled 10y ago
I'm in the midst of upgraded a 1.6 project to 1.10 and Python 3. Wish me continued success :-)
- karthikp 10y ago
  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
  - Daishiman 10y ago
    This is not a sustainable position to be in. Migrations are product issues.
mrfusion 10y ago
I still have a project on 1.2!
- Vaanir 10y ago
  Yikes! I thought we were bad with 1.3 (for a major UK business micro site)

romanovcode 10y ago

Good, it's about time this nonsense ends.

jdimov11 10y ago
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.
- singularity2001 10y ago
  Don't know why you were downvoted: still waiting for a seamless Python X upgrade as well, without code duplication.
  - stefantalpalaru 10y ago
    It already exists, as a Python2 fork: https://github.com/naftaliharris/placeholder https://github.com/naftaliharris/placeholder
    - billoday 10y ago
      This is the greatest thing ever - for systems work, python3 is a nightmare. Thanks for sharing this.
      - detaro 10y ago
        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)
        billoday 10y ago
        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.

gkya 10y ago

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/pull/7867.patch https://patch-diff.githubusercontent.com/raw/django/django/p...

karyon 10y ago

The related django issue is here: https://code.djangoproject.com/ticket/23919 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 :)

nodamage 10y ago

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.

yy77 10y ago
If everything fine with Python 2 on the current project, why bother to upgrade Django 2.0 which will break the compatibility?
- nodamage 10y ago
  Right, that's more or less my question. (I'm not actually using Django though.)
  - aidos 10y ago
    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).

Acalyptol 10y ago

Time to introduce Python 4.

rbanffy 10y ago
Running on the same VM as Perl 7?
disconnected 10y ago
I'm still waiting for Python 3.11 for Workgroups.

jdimov11 10y ago

Says who?? Someone with delusions of grandeur, obviously. Because that's not up to anyone to say. Python 2 is obviously NOT going away any time soon. You can't just look at reality and claim the opposite just because it pleases you. Python 2 is here to stay and is in MUCH better shape than Python 3, in terms of actual production usage globally. Python 3 is a bad joke that someone wants to force down people's throats for NO good reason at all.

fallenshell 10y ago
Nope, Python 3 is a sane upgrade to a sane language bringing many enhancements to the consistency and reliability of Python. And it is being used in many production systems already.
- jdimov11 10y ago
  Congratulations, you've been brainwashed.
  - scrollaway 10y ago
    Claiming people have been brainwashed because you happen to have a different use case than them is not appropriate for HN, nor anywhere. And speaking to your earlier point as somebody using Python 3 in production, says me. Nobody in here cares whether you in particular gets to see the advantages of the new version; but you don't get to say "nobody is using it in production", you don't get to say it's "forced down people's throats" when there's years-long support for it and you certainly don't get to say "no good reason at all" if you're the only one unable to grasp the improvements the language is getting.
    - jdimov11 10y ago
      Oh, it's not appropriate? Should I go sit in the corner now? Who the FUCK do you think you are??
      - 10y ago

scrollaway 10y ago

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.

coldtea 10y ago
>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.
- scrollaway 10y ago
  > 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.

ReticentMonkey 10y ago

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 https://github.com/channelcat/sanic

lewiseason 10y ago
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_now_on_master_will_not_support_python_2/dcmiiv3/?st=iy4izox8&sh=e27de429 https://www.reddit.com/r/Python/comments/5otufg/django_20_no...

jonatron 10y ago

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.

daveguy 10y ago

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.

jsmeaton 10y ago
Just one step. https://code.djangoproject.com/ticket/23919 https://code.djangoproject.com/ticket/23919
- daveguy 10y ago
  Gotcha. Thanks for the clarification (actually 2 of those steps). This is a great reference.
  - Ensorceled 10y ago
    Also factor in halving the on going QA, testing and environment dependent bug fixing efforts.

belvoran 10y ago

A VERY GOOD NEWS!!! Yea, I know, shouting is not the best thing, but this is a really good news.

myf01d 10y ago

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.

anentropic 10y ago
> 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"...?
- myf01d 10y ago
  such as 1. multi-column primary key. 2. annotate several counts for some query correctly. that what I remember for now.
  - jsmeaton 10y ago
    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.

gigatexal 10y ago

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

rowanseymour 10y ago

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.

mark-r 10y ago

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?

rowanseymour 10y ago
Makes sense given Python 3 lets identifiers contain non-ascii characters, e.g. café=123, 变量="x"
- mark-r 10y ago
  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.

oliwarner 10y ago

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.

misterhtmlcss 10y ago

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

spiffyman 10y ago
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.

erikb 10y ago

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.

gojomo 10y ago

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

hirokiky 10y ago

Say good bye to django.utils.six. yay