-
-
Notifications
You must be signed in to change notification settings - Fork 110
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
Backport Python 3.10 NewTypes #156
Comments
Here you go: #157 |
Amazing. Thanks for being so quick! |
@effigies may I ask why it's important to you that types are picklable? We have quite a lot of code to deal with pickling types and on first sight I don't really understand why people would care. This may be relevant to implementing new type system features in the future. |
Sure. It's not a principled requirement so much as practically it's causing me problems while trying to add static type checking to an existing code-base that uses type annotations at runtime. The context is a workflow engine where we use types to annotate inputs and outputs (basically @attr.s
class InputSpec:
in_file: File = attr.ib(...)
@attr.s
class OutputSpec:
out_file: File = attr.ib(...)
class MyTask(Task):
input_spec = InputSpec
output_spec = OutputSpec
def run(self, runtime):
# run task
return runtime This is a static example to give you the flavor. The @task
def mytask(in_file: File) -> File:
... Here, the input/output specs are dynamically constructed. In order to dispatch them to run in separate interpreters or on other servers, some form of pickling is required. It's possible that there's a way to rewrite our code base to avoid it, but I found that when adding a
To be honest, I'm not even sure if we'll end up making |
Thanks, that's helpful! |
As of Python 3.10, the following types are picklable:
Prior to that, this fails. Would it be possible to backport the
NewType
class to Python 3.7+?The text was updated successfully, but these errors were encountered: