Skip to content
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

feat: Correct stubs for TypeVars #67

Merged
merged 20 commits into from
Feb 29, 2024
Merged

feat: Correct stubs for TypeVars #67

merged 20 commits into from
Feb 29, 2024

Conversation

Masara
Copy link
Contributor

@Masara Masara commented Feb 25, 2024

Closes #63

Summary of Changes

TypeVars create correct stubs.

@Masara Masara requested a review from a team as a code owner February 25, 2024 15:51
@Masara
Copy link
Contributor Author

Masara commented Feb 25, 2024

@lars-reimann Like I once mentioned here Mypy seems to be unable to parse square brackets right after function and class names. Therefor I had to use a workaround to get the TypeVar information we need for def fun[T](a: T) -> T like functions. The parameter type and return type are seen as "special Any types" in Mypy and I used that information to assume that we've got a TypeVar. You can see the changes concerning this "workaround" here: 9c30988

Copy link

github-actions bot commented Feb 25, 2024

🦙 MegaLinter status: ✅ SUCCESS

Descriptor Linter Files Fixed Errors Elapsed time
✅ PYTHON black 7 0 0 1.24s
✅ PYTHON mypy 7 0 5.54s
✅ PYTHON ruff 7 0 0 0.04s
✅ REPOSITORY git_diff yes no 0.02s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by OX Security

@Masara
Copy link
Contributor Author

Masara commented Feb 25, 2024

Also it seems like Python 3.11 can't work with the tests containing the def my_fun[T] syntax, what should I do in this case?

@lars-reimann
Copy link
Member

Also it seems like Python 3.11 can't work with the tests containing the def my_fun[T] syntax, what should I do in this case?

That syntax was introduced in Python 3.12, so that's not surprising. Until mypy supports PEP 695 natively, I'm fine with adding a new issue for that syntax to the backlog. Supporting this is not an urgent feature.

Copy link

codecov bot commented Feb 25, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.78%. Comparing base (216e179) to head (b2275b6).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #67      +/-   ##
==========================================
+ Coverage   98.76%   98.78%   +0.02%     
==========================================
  Files          25       25              
  Lines        2017     2053      +36     
==========================================
+ Hits         1992     2028      +36     
  Misses         25       25              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@Masara
Copy link
Contributor Author

Masara commented Feb 25, 2024

I removed the changes and created issue #68. You can now check the PR.

Copy link
Member

@lars-reimann lars-reimann left a comment

Choose a reason for hiding this comment

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

Nice work, this requires only minor changes.

@Masara
Copy link
Contributor Author

Masara commented Feb 28, 2024

@lars-reimann I added the changes you requested. It would be nice, if you also look through the new tests at type_var_module.py and maybe suggest some more cases, since I don't know how the stubs would look like and what would be legal and what not.

@Masara
Copy link
Contributor Author

Masara commented Feb 29, 2024

@lars-reimann I'm done here, you can check this PR now, too.

@lars-reimann lars-reimann merged commit df8c5c9 into main Feb 29, 2024
8 checks passed
@lars-reimann lars-reimann deleted the 63-typevar-stubs branch February 29, 2024 16:22
lars-reimann pushed a commit that referenced this pull request Mar 29, 2024
## [0.2.0](v0.1.0...v0.2.0) (2024-03-29)

### Features

* Added generation for Safe-DS stubs files ([#33](#33)) ([ab45b45](ab45b45))
* Correct stubs for TypeVars ([#67](#67)) ([df8c5c9](df8c5c9)), closes [#63](#63)
* Create stubs for public methods of inherited internal classes ([#69](#69)) ([71b38d7](71b38d7)), closes [#64](#64)
* Rework import generation for stubs. ([#50](#50)) ([216e179](216e179)), closes [#38](#38) [#24](#24) [#38](#38) [#24](#24)
* Safe-DS stubs also contain docstring information. ([#78](#78)) ([bdb43bd](bdb43bd))
* Stubs are created for referenced declarations in other packages ([#70](#70)) ([522f38d](522f38d)), closes [#66](#66)

### Bug Fixes

* Some packages couldn't be analyzed ([#51](#51)) ([fa3d020](fa3d020)), closes [#48](#48)
* Stub generation testing and fixing of miscellaneous bugs ([#76](#76)) ([97b0ab3](97b0ab3))
@lars-reimann
Copy link
Member

🎉 This PR is included in version 0.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@lars-reimann lars-reimann added the released Included in a release label Mar 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
released Included in a release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

feat: Analyzing TypeVar Variables and their usage and generating correct stubs
3 participants