101–110 of 413 posts
Earlier quoted context omitted.
Why can't your Python 2 services talk to your Python 3 web app?
Why should I maintain code, servers and libs in 2 versions of a backend programming language?
Earlier quoted context omitted.
Nope, Python 3 is a sane upgrade to a sane language bringing many enhancements to the consistency and reliability of Python. And it is being used in many production systems already.
Congratulations, you've been brainwashed.
And speaking to your earlier point as somebody using Python 3 in production, says me. Nobody in here cares whether you in particular gets to see the advantages of the new version; but you don't get to say "nobody is using it in production", you don't get to say it's "forced down people's throats" when there's years-long support for it and you certainly don't get to say "no good reason at all" if you're the only one unable to grasp the improvements the language is getting.
Earlier quoted context omitted.
No, he means language level progressive deprecation and evolution, as opposed to an abrupt jump to a changed 3 from 2.
The Django project has added Python 3 compatibility in Django 1.5 as experimental. It remained experimental in 1.6. It became supported in 1.7. They announced around that time that Django 2.0 would only support Python 3. Then, they released a first 3.x compatible LTS with Django 1.8. Then they released 1.9, compatible with 3.4 and 3.5. They then release 1.10. And they are releasing 1.11 soon as an LTS, which they pre…
Earlier quoted context omitted.
> instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them
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…
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.
> This sounds like a fork. Python 3 is already a fork.
Earlier quoted context omitted.
> instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them
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…
That's exactly how _not_ to break backwards compatibility.
Earlier quoted context omitted.
> instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them
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…
IIRC the most impacting changes I remember were in Config, replacement of South with a native solution and some timezone issues
Earlier quoted context omitted.
Congratulations, you've been brainwashed.
Claiming people have been brainwashed because you happen to have a different use case than them is not appropriate for HN, nor anywhere. And speaking to your earlier point as somebody using Python 3 in production, says me . Nobody in here cares whether you in particular gets to see the advantages of the new version; but you don't get to say "nobody is using it in production", you don't get to say it's "forced down pe…
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…
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…