Hacker News Reader

Comment by mehrdadn | Hacker News Reader

Are you talking about making Python 2.6 code work on Python 2.4, or about making Python 2.4 code work on Python 2.6? The parent is talking about the latter for Python 3 (edit: looks like I misunderstood, never mind), but you seem to be talking about the former. They're not the same thing.

View on HN

Python doesn't break backwards compatibility like that. Code written against 3.0 will still work perfectly fine on 3.8; likewise for 2.0 code running against 2.7.

Parent seemed to be talking about the reverse: going backwards, and implying that 2 didn't have major new features, even though it very much did.

> Code written against 3.0 will still work perfectly fine on 3.8

Not 100%. For example, using `async` as a variable name works in 3.0 but not in 3.8, where it is a keyword.

Are you talking about PEP-0492? It was added in 3.5.2 with deprecation of previous behavior in 3.7, release dates of those are separated by exactly 2 years, with deprecation warnings in 3.6.

Looks like PEP 492 introduced `async` as a contextual keyword in 3.5, and it became a proper keyword in 3.7.

No, it does break backward compatibility, especially when they introduce new keywords, but also with stuff like: https://news.ycombinator.com/item?id=22928672

Python3.8 is breaking things left and right because people are using the walrus operator and then realizing that users don't actually have python3.8 installed.

https://github.com/search?q=remove+%22walrus+operator%22&typ...

Wow this is horrifying:

  if (diff := coord - lower) < self.view_dist:

I would've assumed walrus would've only been used at the top level of the expression, not nested inside a conditional!

A pretty normal C idiom. Maybe some old C programmers wanted it? (One of which I am but I like my python pythonic so it wasn't me).

Yeah I know it's common in C, but that sure as heck doesn't imply it should be done in Python!

The parent is talking about the former.

Reply on news.ycombinator.com