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

Migrate to using pathlib in most of the SDK #5435

Merged
merged 1 commit into from
Dec 8, 2022

Conversation

SpecLad
Copy link
Contributor

@SpecLad SpecLad commented Dec 8, 2022

For user-facing functions, keep accepting str paths to maintain compatibility and flexibility, but add support for arbitrary path-like objects. For internal functions (in downloading.py and uploading.py), don't bother and require pathlib.Path.

The only code that isn't converted is build-time code (e.g. setup.py) and code that came from openapi-generator.

Motivation and context

pathlib enables simpler, more type-safe code. This also makes the API more convenient for users who are already using pathlib (or an alternative path library).

How has this been tested?

Unit tests.

Checklist

License

  • I submit my code changes under the same MIT License that covers the project.
    Feel free to contact the maintainers if that's a concern.

`pathlib` enables simpler, more type-safe code.

For user-facing functions, keep accepting `str` paths to maintain
compatibility and flexibility, but add support for arbitrary path-like
objects. For internal functions (in `downloading.py` and `uploading.py`),
don't bother and require `pathlib.Path`.

The only code that isn't converted is build-time code (e.g. `setup.py`) and
code that came from openapi-generator.
@SpecLad SpecLad marked this pull request as ready for review December 8, 2022 11:25
@nmanovic nmanovic merged commit 0a032b3 into cvat-ai:develop Dec 8, 2022
@nmanovic nmanovic mentioned this pull request Dec 12, 2022
@SpecLad SpecLad deleted the cvat-sdk-path branch December 15, 2022 10:55
mikhail-treskin pushed a commit to retailnext/cvat that referenced this pull request Jul 1, 2023
For user-facing functions, keep accepting `str` paths to maintain
compatibility and flexibility, but add support for arbitrary path-like
objects. For internal functions (in `downloading.py` and
`uploading.py`), don't bother and require `pathlib.Path`.

The only code that isn't converted is build-time code (e.g. `setup.py`)
and code that came from openapi-generator.
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

Successfully merging this pull request may close these issues.

2 participants