Skip to content

Add initial types to repo/fun.py #1192

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

Merged
merged 1 commit into from
Mar 12, 2021
Merged

Add initial types to repo/fun.py #1192

merged 1 commit into from
Mar 12, 2021

Conversation

Yobmod
Copy link
Contributor

@Yobmod Yobmod commented Mar 4, 2021

Hi,
This adds types to base.py and fun.py.

  • All annotations are consistant according to both mypy and pyright (but will need refining once whole lib is typed).

  • I've used an alias (TBD, 'to be determined') for Any to show places where I was unsure of the type, but i'm sure it should be more specific than Any.

  • i've avoided changing any runtime code as much as possible, except:

    • i've used Union[str, os._pathlike] to annotate path arguments. Where this showed errors due to use of string-only methods, i've then wrapped the arg in str() within the function. This should mean they are all compatible with pathlib.Paths and pathlib.Purepaths, but that will require tests writing before its official.

    • Adding typeguards: e.g. where git_dir is initialised as None, then assigned later to a string, mypy showed places that needed to be checked that it was actually a string and not still None. This could probably be improved by initializing as "" instead but it touched too much code.

    • changed Except (OSError, IOError) to just Except OSError, as typechecking says it was redundant for python 3.

    • Separate tuple unpacking to seperate lines to provide specific types (unpacked tuples cant be typed yet)

@Yobmod
Copy link
Contributor Author

Yobmod commented Mar 4, 2021

Finally fixed all automated issues!

All functions in base.py and fun.py now typed and passes mypy and pyright (and flake8)

@Byron Byron added this to the v3.1.15 - Bugfixes milestone Mar 5, 2021
Copy link
Member

@Byron Byron left a comment

Choose a reason for hiding this comment

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

Thanks a lot for this tremendous work!

Admittedly I only got to fly through about 2/3 of all changes and think there is a high likelihood of me having missed something.
I will see to finish the rest tomorrow but would hope that another maintainer could also have a look.


# Subclass configuration
# Subclasses may easily bring in their own custom types by placing a constructor or type here
GitCommandWrapperType = Git

def __init__(self, path=None, odbt=GitCmdObjectDB, search_parent_directories=False, expand_vars=True):
def __init__(self, path: Optional[PathLike] = None, odbt: Type[GitCmdObjectDB] = GitCmdObjectDB,
Copy link
Member

Choose a reason for hiding this comment

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

There is an actual base class for object databases which is more general.
There are two implementations for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

LooseObjectDB?

Copy link
Member

Choose a reason for hiding this comment

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

I think it's best to 'make up' a type and call it ObjectDB, as LooseObjectDB is too specific and kind of wrong here, too. Honestly I don't really know what I was thinking and this clearly is an example of OOP being gone wrong.

Otherwise you could dig into GitDB and see how this DB is composed of various types which provide a bundle of methods which may or may not be that useful in practice.

I do recommend to not get into types of GitDB and instead make them up (inside of GitPython) based on what's common usage in GitPython instead.

"""Create a new head within the repository.
For more documentation, please see the Head.create method.

:return: newly created Head Reference"""
return Head.create(self, path, commit, force, logmsg)

def delete_head(self, *heads, **kwargs):
def delete_head(self, *heads: HEAD, **kwargs: Any) -> None:
Copy link
Member

Choose a reason for hiding this comment

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

I think HEAD is too specific - any symbolic reference can be created that way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

amended in #1202

@@ -429,11 +468,16 @@ def _get_config_path(self, config_level):
elif config_level == "global":
return osp.normpath(osp.expanduser("~/.gitconfig"))
elif config_level == "repository":
return osp.normpath(osp.join(self._common_dir or self.git_dir, "config"))
Copy link
Member

Choose a reason for hiding this comment

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

It's probably nicer to do it like this:

if not (self._common_dir or self.git_dir):
    raisereturn osp.normpath(osp.join(self._common_dir or self.git_dir, "config"))

That way there is no duplicate path transformation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

amended in #1202

@Byron
Copy link
Member

Byron commented Mar 12, 2021

As this PR touches a lot of files I am merging it nonetheless even without the requested changes. These can be contributed separately and in the meantime what's there should already be a considerable improvement.

Thanks again, and I am looking forward to your future contributions :).

@Byron Byron merged commit 63c31b6 into gitpython-developers:master Mar 12, 2021
@Yobmod
Copy link
Contributor Author

Yobmod commented Mar 12, 2021

Sorry for slow reply, I was sent to work somewhere with no internet (shocking common in the UK!)

I'll make the suggested changes on next PR.
As types are added to more files, I'll have to review all the previous ones each time anyway, to check for new typing incompatibilities that arise.

@Yobmod Yobmod mentioned this pull request Mar 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants