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

201–210 of 237 posts

Re: Code that will break in Python 4

#201

Post by netmare »

sanderjd wrote: post #120
Pxtl wrote: post #114

Earlier quoted context omitted.

Hell, the reason Windows 10 is Windows 10 is because of all the bad version checks looking for "9X"

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

Re: Code that will break in Python 4

#202

Post by rspeer »

vegabook wrote: post #166
Latty wrote: post #157

Earlier quoted context omitted.

Because the differences were important and central to the language.

Only central to the pedants who wanted to "clean it up", and not central to the user base which, as anybody can see, is now cleaved into two warring factions, a result which is far worse than any of the marginal "improvements" can compensate for.

> Only central to the pedants who wanted to "clean it up"

You're talking about the Python development team, by the way.

Of course they're pedants who want to clean things up. That's why we have Python.

Re: Code that will break in Python 4

#203

Post by mark-r »

kedean wrote: post #111
mark-r wrote: post #33

Earlier quoted context omitted.

Yes, they should make the constant True for both Python 3 and Python 4. If you need to make a finer distinction, use a different package.

Then what was the point of using the PY3 constant?

The only legitimate purpose of using six.PY3 is for managing a module that runs in both Python 2 or Python 3; for that purpose it's almost essential. When Python 4 eventually comes out you may find vestiges of code that still rely on it, even though it hasn't been required for ages. If PY3 is still True, your code will continue to run just fine without changes. If you find it necessary to manage the upgrade from 3 to 4 I'm sure there will be another package available with the required constants.

Re: Code that will break in Python 4

#204

Post by marcosdumay »

colanderman wrote: post #200
marcosdumay wrote: post #165

Earlier quoted context omitted.

I always thought that was mocking with Perl, and nothing else.

Then my analysis that it is a total joke is correct ;)

Looks like so.

Almost all the lines on the Zen of Python are inversion of the Perl guidelines. Some with the exact same phrasing, just with the antonyms of the original.

Re: Code that will break in Python 4

#205

Post by andybak »

twblalock wrote: post #197

The history of Python 2, 3, and 4 is a great lesson in how not to manage changes and versioning in a language.

Give a specific example of something that should have been done differently. It's hard to know which angle you're coming from with a throwaway comment like this.

Re: Code that will break in Python 4

#206

Post by andybak »

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.

Oh come on. That was a wart that was worth fixing at the same time as other more fundamental breaking changes. I doubt you really think that was all the 2>3 shift was about so why play dumb?

Re: Code that will break in Python 4

#207

Post by andybak »

rjurney wrote: post #183
vegabook wrote: post #166

Earlier quoted context omitted.

Only central to the pedants who wanted to "clean it up", and not central to the user base which, as anybody can see, is now cleaved into two warring factions, a result which is far worse than any of the marginal "improvements" can compensate for.

This, so much. Python 3 has failed in the market. A reboot is needed.

Looking pretty good to me: https://python3wos.appspot.com/

Re: Code that will break in Python 4

#208

Post by andybak »

vegabook wrote: post #147
to3m wrote: post #5

2020! I wonder if I'll have more luck finding the time to upgrade my python 2 scripts in the next four years than I've had in the last four?

much more likely: you'll finally find the motivation to upgrade your code, not to Python 3 which is 5% better than 2 and 50% more of a pain-in-the-butt, but because there are a multitude of new, faster, parallel-aware languages that are orders of magnitude better, and already make 3.x look like a dinosaur. Move from one dinosaur to a marginally better-but-fussier dinosaur? Doubt it.

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

Re: Code that will break in Python 4

#209

Post by eevee »

colanderman wrote: post #108

The whole Python versioning fiasco is simply baffling to me as an outsider. Why not mark Python 3 modules with a tag, or different file extension, or anything , and require the Python 3 interpreter to be able to interpret Python 2 code as well as Python 3 code? This is e.g. how the (roughly analogous) split between C and C++ is handled, and it works fine for the most part. No bizarre polyglot code games. Edit: Just t…

What do you do when a value passes between major versions which have different implementations of its type? What do you do with the `int` type, which was actually two separate types in Python 2? What do you do when the binary representation of strings changes (as it did in the 3 series) and you want to pass that into Python 2 land? What do you do about extension modules written in C, which many popular Python libraries use to speed up hot code? Do you include copies of both standard libraries, meaning you now have duplicate modules and may get one or the other depending on the tag in your file? Which version of Python 2 do you target? What happens when there's a bug in one Python 2 implementation but not the other? How do you handle having two C APIs at the same time?

You mention C++ as though it worked out great, but C++ is still full of sharp edges and features that interact weirdly with its C legacy, and it has never completely replaced C (especially for libraries). And that's despite having a few advantages that made it possible in the first place, like having a completely different stdlib built on top of the C stdlib, and producing machine code rather than compiling for a VM on the fly.

Re: Code that will break in Python 4

#210

Post by Nrpf »

andybak wrote: post #208
vegabook wrote: post #147

Earlier quoted context omitted.

much more likely: you'll finally find the motivation to upgrade your code, not to Python 3 which is 5% better than 2 and 50% more of a pain-in-the-butt, but because there are a multitude of new, faster, parallel-aware languages that are orders of magnitude better, and already make 3.x look like a dinosaur. Move from one dinosaur to a marginally better-but-fussier dinosaur? Doubt it.

> 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?
Post reply on HN