Live data from Hacker News

Removing Python 2.x support from Django for version 2.0

github.com

131–140 of 413 posts

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

#131
post #11

Earlier quoted context omitted.

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.

Python 3 is already a fork. The problem is that Python 2 cannot evolve freely alongside Python 3, because even if someone wants to maintain it and keep releasing versions, the Python Software Foundation won't let them use the name Python (there was a post some weeks ago about someone who actually tried). So there is no free competition between 2 and 3. 2 has been basically killed by a decision from above. Don't get m…

The Python Software Foundation are the people who have earned the reputation that the name "Python" has - they're the ones who get to use it. And their judgement is that Python 3 is the future of Python. A fork under a different name can earn its own reputation based on the technical merits of its decisions.

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

#132

Good, it's about time this nonsense ends.

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.

Don't know why you were downvoted: still waiting for a seamless Python X upgrade as well, without code duplication.

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

#133
post #5

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

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

#134

Earlier quoted context omitted.

What py3 does is it enforces the things that py2 only suggests as far as unicode goes. That means on py2 you can go for the proper handling and if you did do everything right, then py3 migration should be almost boring. The difference is when you didn't handle all the cases correctly. In that situation Py2 will silently do either the right, or the wrong thing and you'll never know. Py3 will likely throw an extension…

I'm fairly sure I'm handling strings correctly under Python 2. What I'm not sure of is the risk of something breaking if I upgrade to Python 3, especially when it comes to upgrading external dependencies. Even if it's just non-backwards compatible API changes, it's more risk to deal with.

Isn't that what test bases are for?

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

#135

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…

> warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version That's exactly how _not_ to break backwards compatibility.

> That's exactly how _not_ to break backwards compatibility.

No, no, no. Backwards compatibility means that there are no breaking changes at all - announced by deprecation warnings or not. Think Linux's public API.

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

#136

Earlier quoted context omitted.

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

> 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?

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

#137
post #41
post #17

Earlier quoted context omitted.

Easy to say when you don't depend on C extensions only compatible with 2.7.

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?

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

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

#138
post #41
post #17

Earlier quoted context omitted.

Easy to say when you don't depend on C extensions only compatible with 2.7.

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?

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/... 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 ) and adding a few #ifs. Total time maybe an hour or two.

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

#139
post #126

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

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

Post reply on HN