Hacker News Reader

I began using python during the python3.0 betas, and I watched the 2 vs 3 saga from the (unusual?) perspective of a v3 hobbyist with no back-compat requirements.

What struck me as most significant was the opportunistic breakage of things not related to the unicode transition. In the many years it took to win people over to v3, they could have marched over all the breaking changes a year at a time. Given that side-by-side installs of python3.x point versions are very functional, with or without venvs, this would have been much more palatable. Perhaps harder than it sounds though.

I attempted a couple of 2to3 translations of open source libraries over the years, with varying degrees of success. Every time I found that most of the changes were easy, but debugging the broken bits was hard due to the sheer volume of source changes. If instead I could have done conversions where there was only a single major semantic change at a time, it would be so much easier to figure out what was going wrong at any given step. Furthermore, I imagine that a single-breaking-change mentality would lead to better documentation on how to transition for each version.

For this reason, I have become rather suspicious of yearly release schedules. Swift is even more frustrating: the version changes are really just dictated by Apple's yearly PR calendar. Some big things get rushed out for WWDC before they are ready, and smaller fixes can get held back until the next year. I would much rather that the language teams just prioritize one thing at a time, release it when it is ready, and foster a community where staying up-to-date on the latest version is easy and desirable (a more complicated story for Apple than for Python I think, due to ABI, OS version, etc).

From past discussions on HN I've gathered that there is such a thing as release fatigue, where developers get irritated when libraries release breaking changes too often. Nevertheless I often wonder if languages and libraries could improve faster by making more breaking changes, one at a time, with robust side-by-side installs to facilitate testing across versions. I wish side-by-side library versions were possible in Python, just to facilitate regression testing.

Bringing this all back to the post, I sincerely hope that if Python 4 is a breaking change to the GIL, that it will be only that.

I'm curious what others think about all this. Thoughts?

View on HN

def foo() return ... def bar(): yield ... while foo() or (w := bar()) < 10: # w is in-scope here, but possibly nonexistent! # Even in C++ it would at least *exist*! print(w) # The variable is still in-scope here, and still *nonexistent* # Ditto as above, but even worse outside the loop print(w := w + 1)

def thing(): return True if thing() or w:= "ok": # SyntaxError: cannot use assignment expressions with operator pass print(w) . . . if thing() or (w := "ok"): pass print(w) # NameError: name 'w' is not defined

import random def foo(): return random.randrange(2) def bar(): global w w = return random.randrange(20) return w while foo() or (bar() < 10): print(w)

import re def parse_str(s): def m(pattern): # I <3 Perl! nonlocal _ _ = re.match(pattern, s) return _ is not None if m("Name: (.*)$"): return ("name", _[1]) if m("State: (..) City: (.*)$"): return ("city", (_[2], _[1])) if m(r"ZIP: (\d{5})(-(\d{4}))?$"): return ("zip", _[1] + (_[2] if _[2] else "")) return ("Unknown", s) del _ # Remove this line and the function isn't valid Python(!) for line in ( "Name: Ernest Hemingway", "State: FL City: Key West", "ZIP: 33040", ): print(parse_str(line))

>>> try: ... 1/0 ... except Exception as err: ... err = "Hello" ... >>> err Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'err' is not defined

>>> def f(a, b, /, **kwargs): ... print(a, b, kwargs) ... >>> f(10, 20, a=1, b=2, c=3) 10 20 {'a': 1, 'b': 2, 'c': 3} a and b are used in two ways. Since the parameters to the left of / are not exposed as possible keywords, the parameters names remain available for use in **kwargs