[ty] Add public class_name and class_module_name methods to NominalInstanceType#23147
Conversation
…nalInstanceType` Add two public convenience methods to `NominalInstanceType` so that external crates can retrieve the class name and defining module of an instance type without needing access to the `pub(super)` `class()` method or `pub(crate)` types like `ClassType` and `ClassLiteral`: - `class_name(&self, db) -> &Name`: Returns the class name (e.g. `"str"`) - `class_module_name(&self, db) -> Option<&ModuleName>`: Returns the fully qualified module name where the class is defined (e.g. `"pathlib"` for `pathlib.Path`), or `None` for scripts/notebooks. This enables tools that use `ty_python_semantic` as a library to extract structured type information from instance types for use cases like type attribution in code transformation tools.
knutwannheden
requested review from
AlexWaygood,
carljm,
dcreager and
sharkdp
as code owners
|
Hmm, I think this is the first time we've added Unless we add comments to these methods to indicate why they're I also think we need to be clear to external users that we're not making any backwards compatibility guarantees for ty when it's used as a library. I don't think we should tie our hands if we decide we want to remove the |
|
@AlexWaygood I understand and agree with your reasoning. Even without backwards compatibility it would however be nice if the API remained open enough so that it can be used as a library. |
|
yeah, I'm not totally opposed to this kind of PR! Just want to make sure we've thought through the pros and cons clearly here. And I do think we should at the least definitely add a comment saying to these APIs are for external consumers, or they're quite likely to be deleted in a cleanup PR in the future IMO. Out of interest, would you be happy to say what you're using ty as a library for? No worries if not, just curious |
|
I'm working on a code transformation framework called OpenRewrite, which had up until recently only supported Java and a few other JVM languages. The ASTs are full fidelity in the sense that they retain all whitespace and comments (so a CST, really) as well as being fully type-attributed to allow transformations to query the types of expressions and declarations. I tried quite a few different libraries to get type attribution for Python, but most weren't viable for different reasons (very slow, no longer maintained, bad type inference, etc.). Using ruff/ty I can now either try to work with the LSP or build a small Rust application that extracts all type attribution in bulk for a source file. |
|
that's very cool, thanks for sharing! Good luck with the project |
…ss_name` and `NominalInstanceType::class_module_name` These were added in #23147 for external users who may be using `ty_python_semantic` as a library, but, since they're unused by us I think they're at high risk of being deleted in a cleanup PR without comments to explain why they're there.
…ss_name` and `NominalInstanceType::class_module_name` (#23339) These were added in #23147 for external users who may be using `ty_python_semantic` as a library, but, since they're unused by us I think they're at high risk of being deleted in a cleanup PR without comments to explain why they're there.
3 participants
Add two public convenience methods to
NominalInstanceTypeso that external crates can retrieve the class name and defining module of an instance type without needing access to thepub(super)class()method orpub(crate)types likeClassTypeandClassLiteral:class_name(&self, db) -> &Name: Returns the class name (e.g."str")class_module_name(&self, db) -> Option<&ModuleName>: Returns the fully qualified module name where the class is defined (e.g."pathlib"forpathlib.Path), orNonefor scripts/notebooks.This enables tools that use
ty_python_semanticas a library to extract structured type information from instance types for use cases like type attribution in code transformation tools.