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

Code that will break in Python 4

astrofrog.github.io

Post reply on HN
Print view View original

211–220 of 237 posts

Re: Code that will break in Python 4

#211

Post by andybak »

Nrpf wrote: post #210
andybak wrote: post #208

Earlier quoted context omitted.

> new, faster, parallel-aware languages There were faster languages (and probably more 'parallel-aware' languages - it's not an area I'm very knowledgeable about) before Python but that wasn't the reason it took off. It's fairly unlikely to be the reason it dies off either. Python remains one of the most humane languages out there and that's a quality that is much more intangible and hard to replicate.

What do you think about Julia?

I don't do much (any) numerical stuff so I don't have a terribly informed opinion.

Glancing at the code samples, I don't hate it. It looks rather pleasant.

I can't fathom

Re: Code that will break in Python 4

#212

Post by BuckRogers »

orf wrote: post #199
BuckRogers wrote: post #150

Guido has stated to not compare semver in the past.[0] Will there be a 3.10 or go to 4.0 after 3.9, per one of his core developers?[1] It's hard to tell with Python's leadership (no intentional mockery of the term leadership). My guess is that they'll indeed push onwards to Python4 as soon as possible. This being another attempt to make Python2 look as old and crufty as possible. "You're still on Python2? Wow, I'm on…

Damn, I upvoted you way too early. > They have also adopted every niche feature into Python3 by whoever came along to ask for it. You link to async/await as an example? You realize that's a huge deal and is an awesome feature right? It was something sorely missing, but replicated well with generators (thanks to Python being awesome) since Twisted and Python 2.4. Now is exactly the time to ratify it into the language.…

No, I don't have any significant Python2 codebase. I'm making my own judgement calls off the situation and facts as I see them. I wouldn't build any project in Python3 today, because the prod-ready PyPy option isn't there which adds CPU performance as a Python feature and removes the GIL.

Just because you agree with part of my post and arguments doesn't mean you have to downvote. I had the GVR quote about semver to directly responded to and added to the original post, which is more than most comments.

Anytime I post something critical of Python3 it seems to be a big tug-o-war between those who want to shame me and those who want to show approval. I do it because someone has to say this stuff because I believe the silent majority sees it this way and I frankly find the vocal Python3 promoters to be the loudest of the bunch. There's nothing wrong with other viewpoints unless you're wrong. :)

By the way, Mark Lutz is well respected. He has been teaching Python for decades.

Re: Code that will break in Python 4

#213

Post by Nrpf »

andybak wrote: post #211
Nrpf wrote: post #210

Earlier quoted context omitted.

What do you think about Julia?

I don't do much (any) numerical stuff so I don't have a terribly informed opinion. Glancing at the code samples, I don't hate it. It looks rather pleasant. I can't fathom

Its also for general programming.

Re: Code that will break in Python 4

#214

Post by azernik »

rjurney wrote: post #182
Latty wrote: post #157

Earlier quoted context omitted.

Because the differences were important and central to the language.

print "HI" # oh my god, the horror! print("HI") # yaaaah, order out of chaos Unconvincing.

That is not the central and essential change. It's just a style cleanup that they did while they were breaking compatibility anyway.

The big change was string/byte-array typing, which was a mess in Python 2 and was cleaned up in Python 3. That's one of those things that, when changed, inherently breaks old code in ways that, like wizards, are subtle and quick to anger.

Also changing lots of sequence functions like range() to return iterators instead of lists, but those are mostly pure performance wins that don't break compatibility except for some very specific use cases.

Re: Code that will break in Python 4

#215

Post by orf »

BuckRogers wrote: post #212
orf wrote: post #199

Earlier quoted context omitted.

Damn, I upvoted you way too early. > They have also adopted every niche feature into Python3 by whoever came along to ask for it. You link to async/await as an example? You realize that's a huge deal and is an awesome feature right? It was something sorely missing, but replicated well with generators (thanks to Python being awesome) since Twisted and Python 2.4. Now is exactly the time to ratify it into the language.…

No, I don't have any significant Python2 codebase. I'm making my own judgement calls off the situation and facts as I see them. I wouldn't build any project in Python3 today, because the prod-ready PyPy option isn't there which adds CPU performance as a Python feature and removes the GIL. Just because you agree with part of my post and arguments doesn't mean you have to downvote. I had the GVR quote about semver to d…

> I wouldn't build any project in Python3 today, because the prod-ready PyPy option isn't there which adds CPU performance as a Python feature and removes the GIL.

But... that's a corner area of Python. Not everyone needs GIL-less STM, and arguably if you're using tonnes of threads maybe you're doing it wrong? Perhaps you should try asyncio :)

I mean that reason doesn't even make sense - I'm not using PyPy3 because of the GIL. Great, so uhh what about Django apps? What about small scripts and projects? What about using it for anything other than highly threaded applications that benefit from no GIL?

> Just because you agree with part of my post and arguments doesn't mean you have to downvote

I didn't (and I wouldn't have), I just upvoted after reading "This being another attempt to make Python2 look as old and crufty as possible" - thinking you viewed this in a positive light.

> frankly find the vocal Python3 promoters to be the loudest of the bunch

I see the opposite. I see lots of people angry about a statement being turned into a function, angry at not understanding encoding and angry at the Python developers. People demanding a JIT in cPython, people crying about type annotations, etc. Plus a shedload of FUD.

I'm sorry, your comments reek of someone angry for not very good reasons and I can't work out why. Python 3 is a much much nicer language to work with, it's more consistent and has less WTF's (along with far less UnicodeEncodeErrors). I took the plunge a year ago and won't ever look back, coding in 2.7-8 at work hurts.

I know Mark Lutz is well respected but that doesn't make some of his comments on Python 3 less silly. Anything that has been added to Python 3 has a comment explaining why it sucks, and most of those explanations are senseless. Even things like the statistics module - apparently that sucks because NumPy is better? He implies that should be bundled instead. :/

The matrix operator saves 3+ lines of Numpy code (and is a common operation). This of course sucks because "it's not used by the core language". Oh and it "expands Python's complexity and learning curve needlessly", despite not being used by the core language. Ok Mark.

Re: Code that will break in Python 4

#216

Post by dietrichepp »

netmare wrote: post #201
sanderjd wrote: post #120

Earlier quoted context omitted.

Ha! Is that true in a documented fashion or just widely suspected? I had never heard that, but it makes perfect sense.

That's just a silly rumor. The only examples I've seen of programs using strings to do version checks are Java ones. The function that returns "Windows 95" for Win4.0.xx could simply have been made to return "Windows Nine" or "Windows\xa09" for Win6.4.xx. "Problem" solved. The rest of the world, who's been using GetVersionEx(), wouldn't even notice it. IMHO, the most probable reason was marketing (OS X).

No, it's not a silly rumor. It was Java programs (among others), but Microsoft takes backwards compatibility very seriously. Windows 9 builds were tested internally at Microsoft, and the bugs in third-party programs drove the decision to bump the version to 10.

Re: Code that will break in Python 4

#217

Post by andreasvc »

CamperBob2 wrote: post #188
andreasvc wrote: post #186

Earlier quoted context omitted.

That's not an argument, you could say the exact same thing about braces in other languages. Truth is, it's something that works that really doesn't need to be debated to death like it is.

Yet strangely, hardly anyone complains about braces. I wonder why?

Well I think they're annoying, but there's not much point in complaining because it's not going to change overnight. Either way syntax is a very superficial aspect about programming languages, more interesting to consider semantics.

Re: Code that will break in Python 4

#218

Post by orangecat »

azernik wrote: post #214
rjurney wrote: post #182

Earlier quoted context omitted.

print "HI" # oh my god, the horror! print("HI") # yaaaah, order out of chaos Unconvincing.

That is not the central and essential change. It's just a style cleanup that they did while they were breaking compatibility anyway. The big change was string/byte-array typing, which was a mess in Python 2 and was cleaned up in Python 3. That's one of those things that, when changed, inherently breaks old code in ways that, like wizards, are subtle and quick to anger. Also changing lots of sequence functions like ra…

The big change was string/byte-array typing, which was a mess in Python 2 and was cleaned up in Python 3.

And made worse in some cases (e.g. http://legacy.python.org/dev/peps/pep-0461/). Even aside from that, I would argue that the benefits of cleaning up Unicode didn't come close to the cost of breaking everyone's code and fragmenting the language for 7+ years.

Re: Code that will break in Python 4

#219

Post by Dylan16807 »

dietrichepp wrote: post #216
netmare wrote: post #201

Earlier quoted context omitted.

That's just a silly rumor. The only examples I've seen of programs using strings to do version checks are Java ones. The function that returns "Windows 95" for Win4.0.xx could simply have been made to return "Windows Nine" or "Windows\xa09" for Win6.4.xx. "Problem" solved. The rest of the world, who's been using GetVersionEx(), wouldn't even notice it. IMHO, the most probable reason was marketing (OS X).

No, it's not a silly rumor. It was Java programs (among others), but Microsoft takes backwards compatibility very seriously. Windows 9 builds were tested internally at Microsoft, and the bugs in third-party programs drove the decision to bump the version to 10.

Java would have returned "Windows NT (unknown)" as far as I know. How would programs get a string that said "Windows 9"? What API would be involved? What would they be reading that is text-based, wouldn't lie, [and existed on 9x]?

Re: Code that will break in Python 4

#220

Post by BuckRogers »

orf wrote: post #215
BuckRogers wrote: post #212

Earlier quoted context omitted.

No, I don't have any significant Python2 codebase. I'm making my own judgement calls off the situation and facts as I see them. I wouldn't build any project in Python3 today, because the prod-ready PyPy option isn't there which adds CPU performance as a Python feature and removes the GIL. Just because you agree with part of my post and arguments doesn't mean you have to downvote. I had the GVR quote about semver to d…

> I wouldn't build any project in Python3 today, because the prod-ready PyPy option isn't there which adds CPU performance as a Python feature and removes the GIL. But... that's a corner area of Python. Not everyone needs GIL-less STM, and arguably if you're using tonnes of threads maybe you're doing it wrong? Perhaps you should try asyncio :) I mean that reason doesn't even make sense - I'm not using PyPy3 because o…

I understand your frustration, because I've never been able to see eye to eye with Python3 folks either. I'm always searching for a convincing reason why I need to stop using 2 and start using 3 but I have yet to find a reason that makes sense considering what I lose moving from 2.

Example, I completely agree with all of Lutz's comments and can't see how someone could see it another way. I'm trying though because I'd love to be onboard (I'm sure Mark would too)- but I'd be lying to myself currently to turn a blind eye and move to Python3.

On the benefits of Python2 having production-ready PyPy. It's more than GIL free Python. You only discussed that, but the general performance is next-level plus some from CPython3.

>Not everyone needs GIL-less STM,

You don't need anything, until you do. :)

>What about using it for anything other than highly threaded applications that benefit from no GIL?

That's a "niche feature" like building async IO, but it actually matters because Python3 cannot and likely won't have it. When it does, it'll most likely remain 3.2. While Python2 has many ways to achieve async IO.

>Great, so uhh what about Django apps?

What about them? Django is dramatically superior on Python2/PyPy. I use Django on PyPy with gunicorn and nginx and I assure you I have no worries about any CPU bottleneck no matter what I do.

>people crying about type annotations, etc.

Most of the features in Python3 thus far have been gimmicks, and some are downright embarrassing like type annotations.

Python2 is the premier development platform for me. I can use PyPy and I still have the Python3 migration available. Why would I be in any rush when I only lose moving to 3 today. It just doesn't make sense.

I find it amazing folks have been banging down the gates wishing there was no GIL in Python- it's here but Python2 only. Therefore no longer a big deal. Not to mention the pure single threaded CPU performance improvements available to 2. :) That to me reeks of pure desperation.

Frankly, the only possibility of an "upgrade" available from CPython2/PyPy is not Python3. It's Go, Swift etc.

Post reply on HN