rstudio / rstudio/pins-python

Add explicit `-> Any` return type annotation to `.pin_read` and `.pin_download`

Open
#352 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
59
Forks
11
PR merge metrics
No merged PRs in 30d

Description

These functions are currently un-annotated, so some type checkers (e.g. pyright) will try to infer based on the underlying function calls like load_data and by extension function calls like pd.DataFrame.

It would be better if we explicitly annotated these with typing.Any since it would mean the type checker short-circuits this inference and wouldn't raise an error if the user fails to narrow down the type through case-checking from DataFrame | dict etc.

It would also play nicer with extension packages like geopins which extend the interface to give extra return types dynamically, which the type checker doesn't know about.

I understand that pins isn't typically used in the context of heavy-duty type checking but I think this is pretty easy thing to add and would make it more pleasant to work with in VS Code which usually does light pyright analysis via pylance.

I can put in a PR

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Locate the definitions of .pin_read and .pin_download, then inspect how their current return types are inferred from calls such as load_data and pd.DataFrame. Add the requested typing.Any return annotations and verify that type checking no longer requires callers to narrow inferred return types.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api
Issue type
Refactor
Difficulty
1/5
Estimated time
Under an hour
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.