A VERY GOOD NEWS!!!
Yea, I know, shouting is not the best thing, but this is a really good news.
Removing Python 2.x support from Django for version 2.0
191–200 of 413 posts
Re: Removing Python 2.x support from Django for version 2.0
#192This 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.
Re: Removing Python 2.x support from Django for version 2.0
#193Earlier quoted context omitted.
> 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 argui…
> 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.
Re: Removing Python 2.x support from Django for version 2.0
#194Earlier quoted context omitted.
I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.
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
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.
Re: Removing Python 2.x support from Django for version 2.0
#195Earlier quoted context omitted.
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 "s…
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.
Re: Removing Python 2.x support from Django for version 2.0
#196Oh 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
Re: Removing Python 2.x support from Django for version 2.0
#197Earlier 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…
> 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.
Re: Removing Python 2.x support from Django for version 2.0
#198Earlier quoted context omitted.
I'd prefer to hold judgement on the internals of Django, however as a developer using the API, I also think it's a pleasure to use. There is a very high level of consistency, similar patterns used throughout, and the architecture results in a project structure that I can explain to a new developer who has never used Django before in minutes. I find few frameworks really scale in terms of structure and consistency, an…
I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.
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=...
Re: Removing Python 2.x support from Django for version 2.0
#199This 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.
What critical packages still need to be ported to Python 3? Might be a fun project if they're open source.
Re: Removing Python 2.x support from Django for version 2.0
#200Earlier quoted context omitted.
> 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?