python
Update ``symtable`` stubs for 3.13 and 3.14
This incorporates the changes of the following PRs:
- https://github.com/python/cpython/pull/120028
- https://github.com/python/cpython/pull/120099
- https://github.com/python/cpython/pull/120151
- https://github.com/python/cpython/pull/119976
@JelleZijlstra Should I also write the stubs for _symtable or should I leave it to the IDEs? (PyCharm generates it automatically from the compiled file, but I don't know for others).
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Looks like we'll have to wait for the release of 3.13b3 before adding the new-in-3.13 methods. They exist on 3.13b3 but not on 3.13b2, so stubtest is complaining.
I'd be fine with any of the following options:
- leaving the PR open for a bit until 3.13b3 is out
- cutting out the 3.13 additions for now and just merging the 3.14 additions
- merge the PR as-is, but add allowlist entries to this file to shut up stubtest until 3.13b3 is out: https://github.com/python/typeshed/blob/main/stdlib/%40tests/stubtest_allowlists/py313.txt. (Once 3.13b3 is released, stubtest will immediately start complaining about the allowlist entries being unused, so there's no chance of us forgetting to get rid of the allowlist entries.)
@JelleZijlstra Should I also write the stubs for
_symtableor should I leave it to the IDEs? (PyCharm generates it automatically from the compiled file, but I don't know for others).
Unless there's a specific reason why someone might want or need to import something from _symtable rather than symtable, I'd prefer it if we avoided writing stubs for these internal modules which are implementation details of the runtime.
(If anything from _symtable was reexported from symtable as public API, I could make a case for including the module, as it's generally good to accurately reflect in the stubs the module things were actually defined in. But it doesn't look like anything is reexported in symtable as public API.)
Looks like we'll have to wait for the release of 3.13b3 before adding the new-in-3.13 methods
Yes that's what I was just checking! since docs.python.org reports 3.13b2 I thought it was the "next" release and not the one that was "just" released. Not sure if it's possible for the docs to actually know which feature was added after a release and that is not yet available in the release that can be downloaded. I'll ask Hugo on CPython for that.
leaving the PR open for a bit until 3.13b3 is out
I think it's easier to do that. It's less error-prone (otherwise, I'd need to update the allow_list afterwards, so it's still 2 commits where 1 could have been fine), and more complete IMO (because if someone has 3.14, they would also expect the features from 3.13 since it was written in the docs that this feature was available). And I don't want to change 3.13 with 3.14 and then change it back again afterwards... (also, the use of an enumeration is somewhat breaking between 3.12 and 3.13 so it's important to know that in 3.13, something changed IMO).
I'll leave it as a draft until the next release.
But it doesn't look like anything is reexported in symtable as public API.
No, indeed. It's just importing names but since _socket also had that kind of treatment (where there are a lot of constants), I wondered about it. But if I don't need to, it's easier for me!
the use of an enumeration is somewhat breaking between 3.12 and 3.13
I hope it isn't! Since instances of StrEnum are also instances of str (and all members of a StrEnum enumeration are instances of StrEnum), it should be fully backwards compatible, no?
Actually, the types are compatible but not the values. We did not change what is returned in 3.12.x but in 3.13, it was decided to change the values. Because the old values were incorrect (semantically speaking, like "TypeVar bound" was returned for the symbol table of a default type parameter value...). And we used an enumeration to avoid a constant string which could not be changed in the future.