Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing Python 2.x support from Django for version 2.0

github.com

Post reply on HN
Print view View original

161–170 of 413 posts

Re: Removing Python 2.x support from Django for version 2.0

#161

Post by dkns »

tangue wrote: post #139
ergo14 wrote: post #126

Earlier 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

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

Re: Removing Python 2.x support from Django for version 2.0

#162

Post by ReticentMonkey »

BozeWolf wrote: post #152
Acalyptol wrote: post #80

Earlier quoted context omitted.

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

There are a lot of reasons to upgrade! There is so much more useful stuff in python 3! Even if you think you would not use those features, other libraries you may use might benefit a lot from it. A few features: async/await, lists (and others) use iterators, no var leaking in list comprehensions, super().my_method() instead of super(MyClass, self).my_method(), class MyClass: instead of class MyClass(object):, improve…

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

Re: Removing Python 2.x support from Django for version 2.0

#164

Post by aidos »

BozeWolf wrote: post #159
aidos wrote: post #155

Earlier quoted context omitted.

Of which the improved exception handling is my favourite. You could do ", ".join(["etc"]* 1000) in python2 - what am I missing?

ah well, it was just a geeky way to say etc etc etc.... no python3 stuff intended to be used there. Sorry :) This one then, althoug it sort of works in python 2 as well.. ", ".join(['ètç']* 1000)

Ha! Sorry about that :-)

Re: Removing Python 2.x support from Django for version 2.0

#165

Post by po »

yy77 wrote: post #77
nodamage wrote: post #75

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 act…

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

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

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

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

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

Re: Removing Python 2.x support from Django for version 2.0

#166

Post by xioxox »

lmm wrote: post #127
joeyspn wrote: post #119

Earlier quoted context omitted.

> Many of the science libs want to use seem to be in 2.7 with no signs of moving The most important scientific libraries have pledged to drop support before 2020, and are all python3-ready http://www.python3statement.org/

Is there any hope of other libraries and OSes doing the same thing? I used to work on a GUI app in Python. I ported it to Python 3, then switched OSes for various reasons. 5 years on , on Ubuntu Xenial (so new I can't even use it in Travis, but that's a separate whine), I install pykdeuic4 and it's using Python 2. So I've basically abandoned that project for 5 years now, because every time I looked at it I thought "s…

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

Re: Removing Python 2.x support from Django for version 2.0

#167

Post by vog »

tangue wrote: post #139
ergo14 wrote: post #126

Earlier 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

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

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

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

Re: Removing Python 2.x support from Django for version 2.0

#168

Post by coldtea »

throwawayish wrote: post #130
coldtea wrote: post #122

Earlier quoted context omitted.

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

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

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

And others are bickering for the opposite opinion, so?

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

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

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

Re: Removing Python 2.x support from Django for version 2.0

#169

Post by jsmeaton »

daveguy wrote: post #144

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

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

Re: Removing Python 2.x support from Django for version 2.0

#170

Post by PeterisP »

Flip-per wrote: post #123
surouaue wrote: post #91

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

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

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

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

Post reply on HN