8000 Update ``symtable`` stubs for 3.13 and 3.14 by picnixz · Pull Request #12183 · python/typeshed · GitHub
[go: up one dir, main page]

Skip to content

8000 Update symtable stubs for 3.13 and 3.14 #12183

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jul 1, 2024

Conversation

picnixz
Copy link
Member
@picnixz picnixz commented Jun 22, 2024

@picnixz
Copy link
Member Author
picnixz commented Jun 22, 2024

(Ah I think the methods were only in 3.13.0b3 actually)

@picnixz picnixz marked this pull request as draft June 22, 2024 12:55

This comment has been minimized.

@AlexWaygood
Copy link
Member
AlexWaygood commented Jun 22, 2024

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:

  1. leaving the PR open for a bit until 3.13b3 is out
  2. cutting out the 3.13 additions for now and just merging the 3.14 additions
  3. 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.)

@AlexWaygood
Copy link
Member

@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).

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.)

@picnixz
Copy link
Member Author
picnixz commented Jun 22, 2024

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!

@AlexWaygood
Copy link
Member

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?

@AlexWaygood AlexWaygood added the status: deferred Issue or PR deferred until some precondition is fixed label Jun 22, 2024
@picnixz
Copy link
Member Author
picnixz commented Jun 22, 2024

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.

@AlexWaygood
Copy link
Member
AlexWaygood commented Jun 22, 2024

Got it, thanks! (And thanks for the PR!)

@AlexWaygood AlexWaygood removed the status: deferred Issue or PR deferred until some precondition is fixed label Jul 1, 2024
Copy link
Contributor
github-actions bot commented Jul 1, 2024

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

@AlexWaygood AlexWaygood marked this pull request as ready for review July 1, 2024 22:48
Copy link
Member
@AlexWaygood AlexWaygood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@AlexWaygood AlexWaygood merged commit 6b4cd03 into python:main Jul 1, 2024
60 of 63 checks passed
@picnixz picnixz deleted the update-symtable branch July 2, 2024 06:54
max-muoto pushed a commit to max-muoto/typeshed that referenced this pull request Sep 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0