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

Attributes of Python classes missing #5

Open
JukkaL opened this issue Jan 24, 2013 · 3 comments
Open

Attributes of Python classes missing #5

JukkaL opened this issue Jan 24, 2013 · 3 comments

Comments

@JukkaL
Copy link

JukkaL commented Jan 24, 2013

Some classes are missing attributes in the stubs (e.g. quotes of shlex.shlex).

@ashleyh
Copy link
Owner

ashleyh commented Jan 25, 2013

I can think of 4 ways to do this, none of which are particularly easy or
certain to be accurate:

  • Parsing the source code
  • Importing the class and then disassembling the code objects
  • Importing the class, patching getattr and setattr to record which
    attributes are referred to, then running the tests for that class and
    hoping that all relevant attributes are covered
  • Somehow scraping the documentation

On 24 January 2013 18:00, Jukka Lehtosalo [email protected] wrote:

Some classes are missing attributes in the stubs (e.g. quotes of
shlex.shlex).


Reply to this email directly or view it on GitHubhttps://github.com//issues/5.

@JukkaL
Copy link
Author

JukkaL commented Jan 25, 2013

Here's a fifth way (an alternative to the __getattr__ way): you could transform the test suite to record all attribute accesses. So each expression of form x.y would be transformed into something like __checked_getattr(x, 'y'). This would work for C extension classes as well.

This (or the __getattr__ approach) could be used for dynamic type inference as well. We could also transform calls to __checked_call(callee, args...) to infer argument and return types (and method names).

@JukkaL
Copy link
Author

JukkaL commented Jan 25, 2013

There probably isn't a reliable way of inferring all attributes. But I think that's fine; a 97% or 99% solution would still save a lot of effort. Besides, a lot of library functionality is used very rarely (though we might have the problem of the "long tail"), and it's easy to see if commonly used functionality is missing since code using the module will just not work. The rest could be added manually over time as people find gaps in the stubs.

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

No branches or pull requests

2 participants