Oh boy. And here I am still using Py2.7 with Django 1.6
I still have a project on 1.2!
Removing Python 2.x support from Django for version 2.0
201–210 of 413 posts
Re: Removing Python 2.x support from Django for version 2.0
#202This 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.
>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.
> 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.
Re: Removing Python 2.x support from Django for version 2.0
#203Earlier quoted context omitted.
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 goi…
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.
Re: Removing Python 2.x support from Django for version 2.0
#204Earlier quoted context omitted.
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…
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?
Re: Removing Python 2.x support from Django for version 2.0
#205Earlier quoted context omitted.
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 a…
> 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.
Re: Removing Python 2.x support from Django for version 2.0
#206Earlier quoted context omitted.
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.
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 a…
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.
Re: Removing Python 2.x support from Django for version 2.0
#207Earlier quoted context omitted.
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…
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.
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.
Re: Removing Python 2.x support from Django for version 2.0
#208Earlier quoted context omitted.
> 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 usi…
> 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…
> 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.
Re: Removing Python 2.x support from Django for version 2.0
#209Earlier quoted context omitted.
>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.
Re: Removing Python 2.x support from Django for version 2.0
#210Earlier quoted context omitted.
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 g…
> 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!