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

151–160 of 237 posts

Re: Code that will break in Python 4

#151

Post by chishaku »

colanderman wrote: post #145
sandGorgon wrote: post #136

Earlier quoted context omitted.

I think this is fundamentally because of the Python philosophy around one-true-way to do things (something that's open to interpretation given the number of string functions that are around). IMHO, the Python 3 vs Python 2 split is a phlisophical rift rather than a technical one. There is no real technical reasons why print and print() cannot coexist. In all reality, Python 2 and Python 3 are completely differently l…

As an aside, this: > the Python philosophy around one-true-way to do things I've always thought to be a total joke. There's been like 5 different modules each for string interpolation, subprocess management, and argument parsing. Heck, I thought I was on top of which was in vogue and apparently just two weeks ago there's a new "one true way" to do string interpolation.

I came across this recently:

> Barry Warsaw, one of the core Python developers, once said that it frustrated him that "The Zen of Python" (PEP 20) is used as a style guide for Python code, since it was originally written as a poem about Python's internal design. [0]

I did a quick search for a little more background but didn't find anything. I'd be curious to hear more.

[0]: https://github.com/amontalenti/elements-of-python-style#a-li...

Re: Code that will break in Python 4

#152

Post by such_a_casual »

colanderman wrote: post #145
sandGorgon wrote: post #136

Earlier quoted context omitted.

I think this is fundamentally because of the Python philosophy around one-true-way to do things (something that's open to interpretation given the number of string functions that are around). IMHO, the Python 3 vs Python 2 split is a phlisophical rift rather than a technical one. There is no real technical reasons why print and print() cannot coexist. In all reality, Python 2 and Python 3 are completely differently l…

As an aside, this: > the Python philosophy around one-true-way to do things I've always thought to be a total joke. There's been like 5 different modules each for string interpolation, subprocess management, and argument parsing. Heck, I thought I was on top of which was in vogue and apparently just two weeks ago there's a new "one true way" to do string interpolation.

I think this needs to be the responsibility of things like PEP rather than the actual language. Otherwise you break old code every time you find a better way.

Re: Code that will break in Python 4

#154

Post by Grue3 »

ngoldbaum wrote: post #64
Grue3 wrote: post #30

There isn't all that much code written for Python 3 to care about backwards compatibility. IMO Python 4 should be: - backwards compatible with the latest release of Python 2 - contain all features of Python 3 in some form I think this will result in a very speedy adoption. In the future I propose the following numbering scheme: for any N > M, Python N contains all features of Python M and is backwards compatible with…

Those two statements are mutually incompatible. Python3 is a different language with different semantics. It is possible to work in a subset of python2 and python3 that is syntactically valid under both interpreters but this is not what you are suggesting.

No, you are confusing "features" and "syntax". Both Python 2 and Python 3 are Turing complete. They have the same expressiveness. It's possible to backwards-compatibly extend Python 2 to achieve feature-parity with Python 3 while preserving Python 2 syntax. Python 4 proposed by me is possible, while Python 6 (which must be backwards-compatible with both 2 and 3) is probably not possible.

Re: Code that will break in Python 4

#155

Post by comex »

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…

But imagine what would happen if they had created a compatibility layer. Yes, it would be very hacky, and require a lot of seemingly gratuitous work - tons of standard library functions would have to check the compatibility version of the caller and change behavior accordingly. And the goal of cleaning up the codebase by removing things like old-style classes wouldn't be achievable. But what if that work had been done, and the mess accepted?

Then Python 3 code could use every unmodified Python 2 library (albeit potentially requiring the former to do some messy conversions between str and bytes when making calls), including the long tail of legacy libraries that will never be upgraded. Meanwhile, once the issues in the first Python 3 release or two were straightened out, there would be very little reason to use the Python 2 interpreter, since the Python 3 one would be a drop-in replacement; so migration to the latter would be relatively swift, and it wouldn't be too much of a burden to ask someone to upgrade as a prerequisite to using your code. So there would be very little reason to write new Python code in the Python 2 dialect (unless you really really hate making print a function :), and existing code could be migrated one file at a time. Including popular libraries that wanted to maintain backwards compatibility with Python 2 programs - they would have to add compatibility checks similar to the standard library, but could otherwise go full Python 3, rather than having to use the awkward intersection of language semantics and compatibility libraries currently required.

With the transition so much smoother overall, native Python 3 code would probably take over relatively quickly. (Maybe it would have even been feasible to remove the Python 2 compatibility layer eventually, though probably not.) Whereas in reality, today, over 7 years later, Python 2 is still more popular than Python 3 [1].

[1] https://lwn.net/Articles/640181/

Re: Code that will break in Python 4

#156

Post by Grue3 »

orf wrote: post #66
Grue3 wrote: post #30

There isn't all that much code written for Python 3 to care about backwards compatibility. IMO Python 4 should be: - backwards compatible with the latest release of Python 2 - contain all features of Python 3 in some form I think this will result in a very speedy adoption. In the future I propose the following numbering scheme: for any N > M, Python N contains all features of Python M and is backwards compatible with…

> IMO Python 4 should be: > - backwards compatible with the latest release of Python 2 > - contain all features of Python 3 in some form I'm lost for words.

Please elaborate. Which feature of Python 3 would be impossible to implement in Python 2? Note that Python 3 code is not guaranteed to work in Python 4, but you are guaranteed to (relatively) painlessly port it, since all Python 3 features are implemented in Python 4 in some way.

Re: Code that will break in Python 4

#157

Post by Latty »

vegabook wrote: post #143
gipp wrote: post #94

Earlier quoted context omitted.

Usually when it's hard to tell that's because it applies to both. The differences between the two are really not that large.

...which begs the question: why are there any differences at all!

Because the differences were important and central to the language.

Re: Code that will break in Python 4

#158

Post by Latty »

incepted wrote: post #99

> We don't really know yet what Python 4 will look like, but we can be pretty sure that the transition from Python 3 to Python 4 will be a lot smoother Doesn't compute. You can't say you don't know anything about Python4 and immediately follow up with suggestions on how to program for it. And if you really want to be consistent, at least: if (python2): // python 2 else if (python3): // python 3 else: raise "I have no…

Because he said "we don't really know" - the core developers for Python have said they don't plan to do another big break like Python 3.

Re: Code that will break in Python 4

#159

Post by vegabook »

daveguy wrote: post #92
untothebreach wrote: post #8

Earlier quoted context omitted.

I don't have any links but I know there have been statements by core devs that, when/if there is another major version of python being developed, there will be an upgrade path to make the 3->4 transition much better than the 2->3 transition.

Yeah, they pretty much botched the 2->3 transition. I would love to see a 4 that included a viable 2->4 transition with semantic versioning until then. But Guido&Co are going to do whatever the hell they feel like doing, community be damned. Py2.7 will be forked and going strong long after 2020. Actually 2020 will probably be a Python renaissance when the cruft, incompatibilities, gil, no jit, etc can finally be addr…

> community be damned

couldn't agree more. Yet all the evidence is that they're still using 3.x as their personal little hobby playground. Exhibit A: type annotations. Just because others are doing it. Nobody is asking for this. Even the PEP took ages to approve because even the yes-men had their doubts. Exhibit B: re-invent green threads. There are 15 solutions already.

Where is GPU? Where is multicore? Where is speed?

Where is the leadership?

Re: Code that will break in Python 4

#160

Post by mahouse »

douchescript wrote: post #101

Why even adapt for python 3? Nobody uses that stalinist version of python anyway. Its incredibly bad to have to use ifdefs in a scripting language like that. Code should be written so that it works regardless of version.

Stalinist version of Python. That's a new one
Post reply on HN