Weekly Report 2021, September 20 - 26
This week in numbers: closed 13 issues, closed 46 PRs, and reviewed 7.
I spent a lot of time fiddling with the Github PR activity stats for the blog post I’m writing on the subject. There’s been some hiccups there around linking Github usernames to e-mails in repository commits. At this point I haven’t completed the blog post yet but it’s getting close. Digging through the Github PR stats made me notice a bunch of pretty old PRs that could either be merged or rejected, so I did a bunch of those this week.
There were two interesting
typing-related issues this week. First was about module-level
Final and bare class-level
Final annotations being incorrectly rejected by
get_type_hints when used as forward references or through with
from __future__ import annotations. Fix by Nikita Sobolev in GH-28279. This also identified a discrepancy:
get_type_hints was more forgiving of invalid type annotations when given regular annotations than when getting string annotations. What to do with that is explored in BPO-45283.
The other interesting
typing issue was around PEP 544 Protocols. An important part of those is that they can compose existing classes. However, as the PEP defines them, Protocols aren’t meant to be concrete types and as such cannot be instantiated. So,
typing ensures this is the case by replacing the
__init__() method with an error. Maybe then it would make sense to disallow even putting
__init__() methods on Protocol class definitions? BPO-44807 suggests this and it makes sense: trying to create a Protocol instance is already raising a
__init__() methods aren’t traditionally perceived as part of the instance state (or, for short, “not part of the type"). However, as I pointed out, it is sensible to use an annotation not for an instance (e.g.
SomeProtocol) but for a concrete class that happens to create protocol-conforming instances (e.g.
type[SomeProtocol]). This already works in existing type checkers like Mypy. So, it follows that maybe
__init__() should be considered part of a protocol after all. Currently, that’s not enforced by type checkers but it could. PEP 544 will have to be amended to explicitly include
__init__() (or not, this still needs to be discussed).
Probably the oldest issue I’ve closed is BPO-1514420. Note the high number, that’s from when Python imported their issues from SourceForge to bugs.python.org back in 2006 (Brett Cannon has a very interesting blog post on Python moving to GitHub which includes some historical context as well). Anyway, the issue is about C tracebacks trying to find and read a file named
<stdin> in site-packages and other Python directories when an exception is displayed to the user. It read it to try to map line numbers to content but that was of course silly for a special source like
<stdin>. In any case, after 17 years Irit Katriel solved the issue.
Since we’re talking “oldest”, the oldest PR I’ve merged at this point has got to be GH-2743 from July 2017. It was easy to merge since it was about invalid code object documentation in the
inspect.iscode function. The more important to just deal with such changes in a timely manner.
Another example of a maybe low-severity PR that is nevertheless an improvement to the codebase and posed some backporting challenge was GH-28473 where Mohamad Mansour found instances of non-matching bracket pairs in our project’s files. Of course, C files and Python files are checked by the their respective compilers, but it turned out that in documentation, comments, docstrings, and similar places we had quite a few instances of problematic brackets. Since this touched 29 files, this posed a dilemma: only merge this into 3.11 and risk future merge conflicts for actual bugs in 29 files, or also merge this into 3.10 and 3.9. We decided it makes most sense to backport. 3.10 was close enough that it posed no problems with the backport. 3.9 was different enough already that I had to make a manual backport. So I guess in this case it was more a matter of moving where you want the merge conflicts to be 😆
One interesting issue that is now identified but not yet solved is a stack corruption problem on win32. Reproducer in GH-26204.
Plans for next week
I’m almost done with the blog post on CPython contributor activity, I hope to have that released early next week.
- closed pull request GH-19897
- closed pull request GH-28143
- closed pull request GH-28471
- closed pull request GH-28478
- closed pull request GH-28479
- closed issue BPO-45216
- closed pull request GH-28377
- closed pull request GH-28502
- closed pull request GH-28445
- closed pull request GH-28421
- closed pull request GH-28505
- closed pull request GH-28506
- closed pull request GH-27543
- closed pull request GH-28484
- closed pull request GH-28508
- closed pull request GH-28507
- closed pull request GH-28510
- closed pull request GH-28473
- closed pull request GH-28511
- reviewed pull request GH-28498
- reviewed pull request GH-27543
- reviewed pull request GH-28378
- closed issue BPO-45238
- closed pull request GH-28512
- closed pull request GH-28449
- closed pull request GH-28521
- closed pull request GH-28522
- closed pull request GH-28529
- closed pull request GH-18170
- closed pull request GH-16667
- closed pull request GH-18031
- closed pull request GH-28533
- closed pull request GH-28534
- closed pull request GH-28535
- closed pull request GH-16974
- closed pull request GH-28536
- closed pull request GH-28537
- closed pull request GH-2743
- closed pull request GH-28544
- closed pull request GH-28543
- closed pull request GH-11773
- closed pull request GH-18198
- closed pull request GH-25814
- reviewed pull request GH-28279
- reviewed pull request GH-25582