Asana / python-asana

Official Python client library for the Asana API v1

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Linter has no knowledge of some member functions and attributes

yankee14 opened this issue · comments

I'm playing with this API for the first time, running 0.10.3 installed from pip. Pylint is not aware of some members for some reason, but it still runs correctly. The image below shows no-member for some functions and attributes of client.

no-member

These are the only members it knows:

image

I know this may be an issue that isn't your fault (my problem), but I'm not sure where to start looking to make it aware of all the members.

Hello @yankee14 !

I believe this is a problem with the library and I haven't dug into it yet. I'll make a task for someone to take a look!

Thank you for calling it out!

@rossgrambo

I just noticed this as well, my jupyter auto-complete doesn't pick it up, and the docs don't provide many breadcrumbs. I have a slight hunch it's because RESOURCE_CLASSES is run through a for-loop of setattrs() during __init__ of the object.

This for-loop calls global RESOURCE_CLASSES at __init__ to set the supported class attributes from the module

for name, Klass in RESOURCE_CLASSES.items():
setattr(self, name, Klass(self))

I don't think I'd personally use a global variable during __init__ to set these attributes (Could it make sense to use *args or **kwargs instead and unpack the resource classes from there?), but it does seem to have the resource values after initialization, if I intentionally inspect the module in my IDE:

import asana.client
for name, Klass in asana.client.RESOURCE_CLASSES.items():
    print(name, Klass)

attachments <class 'asana.resources.attachments.Attachments'>
custom_field_settings <class 'asana.resources.custom_field_settings.CustomFieldSettings'>
custom_fields <class 'asana.resources.custom_fields.CustomFields'>
events <class 'asana.resources.events.Events'>
jobs <class 'asana.resources.jobs.Jobs'>
organization_exports <class 'asana.resources.organization_exports.OrganizationExports'>
portfolios <class 'asana.resources.portfolios.Portfolios'>
portfolio_memberships <class 'asana.resources.portfolio_memberships.PortfolioMemberships'>
project_memberships <class 'asana.resources.project_memberships.ProjectMemberships'>
project_statuses <class 'asana.resources.project_statuses.ProjectStatuses'>
projects <class 'asana.resources.projects.Projects'>
sections <class 'asana.resources.sections.Sections'>
stories <class 'asana.resources.stories.Stories'>
tags <class 'asana.resources.tags.Tags'>
tasks <class 'asana.resources.tasks.Tasks'>
teams <class 'asana.resources.teams.Teams'>
typeahead <class 'asana.resources.typeahead.Typeahead'>
users <class 'asana.resources.users.Users'>
user_task_lists <class 'asana.resources.user_task_lists.UserTaskLists'>
webhooks <class 'asana.resources.webhooks.Webhooks'>
workspace_memberships <class 'asana.resources.workspace_memberships.WorkspaceMemberships'>
workspaces <class 'asana.resources.workspaces.Workspaces'>

Additionally, VSCode shows the same behavior, it does not show the attrs set from RESOURCE_CLASSES:

image

Doing some cursory research on VSCode and Jupyter indicate that both of these tools use JEDI for their language servers (In my case, Jupyter defaults, and VSCode has defaulted to it, but I see this behavior ) and it's tooling like code-completion: and setattr() is explicitly unsupported, as well as writing to globals():
https://jedi.readthedocs.io/en/latest/docs/features.html#limitations

Additionally there are some Python patterns Jedi does not support. This is intentional and below should be a complete list:

  • Arbitrary metaclasses: Some metaclasses like enums and dataclasses are reimplemented in Jedi to make them work. Most of the time stubs are good enough to get type inference working, even when metaclasses are involved.
  • setattr(), import()
  • Writing to some dicts: globals(), locals(), object.dict
  • Manipulations of instances outside the instance variables without using methods

Also, the Microsoft Python Language Server for VSCode (A drop-in that a user can use to replace JEDI) seems to have a similar limitation based on this comment from one of the mantainers here

So while I don't think this is directly an issue with the asana package, I do think Asana could re-factor this package to support code completion

  • The current documentation is bare, so a lack of code completion makes increases the difficulty in efficiently using the asana package, and understand what is available to me.
  • The global for-loop feels risky in that a bad actor could re-package this asana package with some very unscrupulous modules inside the resources folder that would then be automatically loaded by Client object as a supported resource attribute without any safety check, only because the unscrupulous code exists inside the folder the Client class object is drawing it's attribute methods from.

Hi @webdog, first off I want to apologies for the late reply from my team. I also want to thank you for the level of detail that you have provided us and appreciate your contribution.

I was able to do a bit of digging and experimentation and it does look like we’ll have to do a bit of refactoring in order to get auto-completion to work. I managed to test out a solution for auto-completion (See attached .gif) and was able to get this working locally. We are currently working on updating our client libraries and are mainly focused on improving parity with our API. I'll see if we can add this work in as part of our updates. For now, I'll close out this issue.

auto-complete

Hi!
Is it in release already? It seems not working. VS Code with ms-python.python (Official by Microsoft) doesn't resolve nor API endpoint types, nor methods.

Hi @Danand, no this feature was never released. This was something I experimented with and we ultimately decided not to pursue it since we wanted to work on refactoring our python client library to make it easier for our team to maintain and provide updates to our python SDK.