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

Handle the last of the type ignore #292

Open
7 of 9 tasks
Peilonrayz opened this issue Mar 6, 2020 · 3 comments
Open
7 of 9 tasks

Handle the last of the type ignore #292

Peilonrayz opened this issue Mar 6, 2020 · 3 comments

Comments

@Peilonrayz
Copy link
Contributor

Peilonrayz commented Mar 6, 2020

1. Simple changes

With the exception of a couple of # type: ignores that can't really be removed. I would like to remove all that are left. I have had a quick glance at the ones that remain after #290, and to remove them would require:

  • Use --ignore-missing-imports to remove all ignores around imports.

  • Change _parametrize.parametrize_decorator to delegate the transformation of arg_values_list to a function so we don't reuse the same variable name.
    Alternately we could create a new variable and change the two ifs to an if elif else.

  • Change sessions.Session.virtualenv to treat None as an AttributeError, changing the return type to ProcessEnv rather than Optional[ProcessEnv].

    Additionally change all instances of self._runner.venv to self.virtualenv. This would require some changes to the tests.

  • Change sessions.Session.error and skip to not allow keyword arguments. As they just produce the following TypeError:

    TypeError: Exception() takes no keyword arguments

  • Add a create method to virtualenv.ProcessEnv that just raises NotImplementedException. This is because we're using PrecessEnv like an interface, as the two subtypes CondaEnv and VirtualEnv both define this method.

  • Change tox_to_nox to raise an error if pkgutil.get_data returns None.
    Alternately we could just continue ignoring this.

These are all quite small changes, I can't imagine they would take more than a couple lines of code to fix.

2. Complex changes

There are some more complex changes I'd like to make. Any that change what the type annotations are can have the ability to effect large amounts of the code.

To solve the problematic type annotations should be simple, change the annotation to Optional[str] and handle None further down the code. If this isn't clean then I can handle None by throwing an error before entering the function/class/method.


If you say the above is all good then I'll implement the first solution I list on any where I list multiple, such as 1.2. If you think I've missed the mark I'm happy to fix these any other way.

I'm new to GitHub, are the current size of the PRs ok? Should I try split this one up so it's multiple smaller ones, or is just one big one ok?

@theacodes
Copy link
Collaborator

theacodes commented Mar 6, 2020 via email

@Peilonrayz
Copy link
Contributor Author

Peilonrayz commented Mar 6, 2020 via email

@theacodes
Copy link
Collaborator

theacodes commented Mar 6, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants