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

Provide access to code of providers via pipeline object #98

Open
dschick opened this issue Jan 10, 2024 · 4 comments
Open

Provide access to code of providers via pipeline object #98

dschick opened this issue Jan 10, 2024 · 4 comments

Comments

@dschick
Copy link

dschick commented Jan 10, 2024

In many situations, it is handy to have access to the source of certain providers within a given pipeline in read-only mode.
While the visualize() functionality is already convenient for getting an overview of the pipeline, the internals of the providers are hidden, possibly even in a multilevel module.

I propose a new method which prints the path, docstring, and source of the provider, like:

pipeline = sciline.Pipeline(providers, params=params)
pipeline.prdef(CleanedData) 

where CleanedData is the key to the provider.
Under the hood, one should be able to do all the magic using the inspect python package.

Another maybe more fancy idea is to show the docstring of providers in the TaskGraph as tooltips and maybe the same for type definitions of domain types.

Best

Daniel

@SimonHeybrock
Copy link
Member

SimonHeybrock commented Jan 15, 2024

I would suggest (for now) to simply add Pipeline.__getitem__. The user can then use inspect themselves, e.g., to get the source or the docstring.

We need to think about how to handle parameters. Currently they are wrapped in a lambda, but even if they are not, getting the docstring of a type defined via NewType doesn't really work. I don't know of Python 3.12 type aliases fare any better.

Adding __getitem__ is quite simple, in principle. It would be a thin wrapper around (probably) Pipeline._get_unique_provider.

@SimonHeybrock
Copy link
Member

@jl-wynen Does your work in #116 which added the Provider class improve what we can do here? Should __getitem__ return Provider? One could then consider adding convenience methods (Such as docstring access) to Provider.

@jl-wynen
Copy link
Member

jl-wynen commented Feb 8, 2024

That was part of the motivation. So, yes, I think we should do

Should getitem return Provider?

And the ProviderLocation class was intended to be extended if we want to access the source code. (I didn't want to name it ProviderSource because it doesn't access the source. But maybe that would be a better name in the end.)

@jl-wynen
Copy link
Member

jl-wynen commented Feb 8, 2024

Actually, there is no need to use the ProviderLocation. If we can access the Provider, it can be inspected:

import inspect
import sciline

def inspect_provider(p: sciline.pipeline.Provider):
    print(f'--{p.kind}--')
    if p.kind == 'function':
        print(p.func)
        print(inspect.getsource(p.func))
    elif p.kind == 'parameter':
        print('value:', p.call({}))
    # else:  something internal that should probably not be inspected

def f(x: int) -> str:
    return str(x)

l = lambda: 3.0
l.__annotations__['return'] = float

pl = sciline.Pipeline((f, l), params={int: 2})

inspect_provider(pl._providers[int])
inspect_provider(pl._providers[str])
inspect_provider(pl._providers[float])

Prints

--parameter--
value: 2
--function--
<function f at 0x7f3966d1b0d0>
def f(x: int) -> str:
    return str(x)

--function--
<function <lambda> at 0x7f3966a2dc10>
l = lambda: 3.0

Lambdas are weird...

@jokasimr jokasimr self-assigned this Feb 19, 2024
@jokasimr jokasimr moved this from Selected to In progress in Development Board Feb 19, 2024
@jokasimr jokasimr moved this from In progress to Blocked in Development Board Mar 11, 2024
@SimonHeybrock SimonHeybrock moved this from Blocked to Triage in Development Board Jun 10, 2024
@jokasimr jokasimr removed their assignment Jun 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Triage
Development

Successfully merging a pull request may close this issue.

4 participants