Earlier quoted context omitted.
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.
Removing Python 2.x support from Django for version 2.0
271–280 of 413 posts
Re: Removing Python 2.x support from Django for version 2.0
#272Earlier quoted context omitted.
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.
Re: Removing Python 2.x support from Django for version 2.0
#273So, 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.
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.
Re: Removing Python 2.x support from Django for version 2.0
#274So, 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.
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?
Re: Removing Python 2.x support from Django for version 2.0
#275The next release, Django 1.11, will be a long-term support release, and the one after that, Django 2.0, will no longer support Python 2. https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ I've grow to highly respect the Django project for its good documentation, its healthy consideration for backwards compatibility, security, steady improvements and all round goodness.
> its healthy consideration for backwards compatibility Is this a joke? They break backwards compatibility with every minor version, wasting tens of thousands of man-hours all over the world - time that, if we're honest, is not exactly billable. Most people don't upgrade because of this and keep on using vulnerable versions. It's good that they are trying to kill the project. It saves newbies from stepping into the t…
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?
Re: Removing Python 2.x support from Django for version 2.0
#276The next release, Django 1.11, will be a long-term support release, and the one after that, Django 2.0, will no longer support Python 2. https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ I've grow to highly respect the Django project for its good documentation, its healthy consideration for backwards compatibility, security, steady improvements and all round goodness.
> its healthy consideration for backwards compatibility Is this a joke? They break backwards compatibility with every minor version, wasting tens of thousands of man-hours all over the world - time that, if we're honest, is not exactly billable. Most people don't upgrade because of this and keep on using vulnerable versions. It's good that they are trying to kill the project. It saves newbies from stepping into the t…
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.
Re: Removing Python 2.x support from Django for version 2.0
#277I 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.
Re: Removing Python 2.x support from Django for version 2.0
#278Earlier quoted context omitted.
> 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…
If you're building a form in React why do you even bother with django forms when there's Django Rest Framework?
Re: Removing Python 2.x support from Django for version 2.0
#279Earlier quoted context omitted.
> its healthy consideration for backwards compatibility Is this a joke? They break backwards compatibility with every minor version, wasting tens of thousands of man-hours all over the world - time that, if we're honest, is not exactly billable. Most people don't upgrade because of this and keep on using vulnerable versions. It's good that they are trying to kill the project. It saves newbies from stepping into the t…
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.
Re: Removing Python 2.x support from Django for version 2.0
#280Earlier quoted context omitted.
I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.
I always expected Pyramid to offer some performance benefits over Django, given the origins (taking the best of framework X and Y), esp given that you can choose your own ORM (e.g., SQLAlchemy), etc. However, once you're out of the unrealistic scenarios (single query benchmarks, etc.), it doesn't do that well[1]. It's not prohibitively slow, but to make the jump from something as well documented and with as large a c…
I used Pyramid for a couple of large projects back when it was Pylons, and around the time of the merger that resulted in Pyramid.
Django has grown up a lot in the last several years. It used to be really hard to use a different templating language, and I personally really dislike Django's templating language. That was the biggest turn off for me every time I looked into Django. If it had been pluggable earlier, this 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.