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

231–237 of 237 posts

Re: Code that will break in Python 4

#231

Post by jug »

> My current expectation is that Python 4.0 will merely be "the release that comes after Python 3.9". That's it.

What? If that's the idea, don't be stupid and just call it Python 3.10 then.

Otherwise, won't we risk a completely unnecessary major versioning problem as outlined in this very article??

Sometimes it feels like the Python team wants to change the major version number only to teach the development community a lesson about coding libraries right, not because they have to. This kind of masochistic idea of deciding version numbers, if it's there, needs to go since this lesson will never be learnt by each and everyone due to the immense size of the community. And if there is a support issue in some libraries, the ripple effect can and will affect other projects as well.

Re: Code that will break in Python 4

#232

Post by jug »

gruez wrote: post #148
renata wrote: post #89

Earlier quoted context omitted.

This search turns up some quite a few results, including some OpenJDK code: https://searchcode.com/?q=if%28version%2Cstartswith%28%22win... .

that's irrelevant because Microsoft fakes version information for applications by default[1]. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...

But the above isn't looking at (faked) version information / GetVersion, but the name of the operating system, which is not faked in any call that I know.

Re: Code that will break in Python 4

#233

Post by tempodox »

Python 4, really? I wonder how that will work out. Currently, we have to maintain at least 2 incompatible Python ecosystems on a box. With Python 4 it will be at least 3 to maintain if nothing changes. That's not something I'm looking forward to.

Re: Code that will break in Python 4

#234

Post by ptx »

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.

More like:

  print >>sys.stderr, "Hi",             # horror

  print("Hi", file=sys.stderr, end="")  # order
But the important change was Unicode.

Re: Code that will break in Python 4

#236

Post by sitkack »

andybak wrote: post #205
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.

From Brett Cannon http://www.snarky.ca/why-python-3-exists

I think maybe the Python 2/3 split was a huge performance piece on how NOT to evolve a language, but we just copied Perl 6.

Do you think a stop the world, forced upgrade is something that should be done in the future? Was it avoidable?

Re: Code that will break in Python 4

#237

Post by ac29 »

rogerbinns wrote: post #131
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…

Are you expecting the same running interpreter to have both python 2 and 3 modules at the same time, with calls between the modules working? You can easily keep things separate - python 2 executable is named python while python 3 is python3. https://www.python.org/dev/peps/pep-0397/ Sadly concurrent running in the same interpreter won't work because Python 3 has different types for strings (unicode only) and a bytes…

> python 2 executable is named python while python 3 is python3

Nope, not quite. Python 2 is named python2 and python 3 is named python3, on every system I am aware of. 'python' is ambiguous and can be linked to either [1]. I know at least on Arch Linux, python links to python3, and I have run into a handful of scripts that break by assuming python is always linked to python2.

[1] https://www.python.org/dev/peps/pep-0394/

Post reply on HN