-
Notifications
You must be signed in to change notification settings - Fork 117
[bugfix] Restrict reference tuples acceptable types #2702
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
[bugfix] Restrict reference tuples acceptable types #2702
Conversation
- Reference tuples cannot accept a deferrable.
This is achieved nicely by extending the type checking system to support
composite types and by allowing to insert in the type check subsystem any custom
type. For example, one can do the following:
```python
Deferrable = typ.make_meta_type('Deferrable', _DeferredExpression)
x = variable(typ.Integer|Deferrable|typ.List[typ.Integer|typ.Float])
y = variable(~typ.Deferrable)
```
7df66a1 to
519bc9f
Compare
ekouts
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, just a small comment about imports
victorusu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
|
@jenkins-cscs retry all |
Codecov ReportBase: 86.59% // Head: 86.59% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #2702 +/- ##
==========================================
- Coverage 86.59% 86.59% -0.01%
==========================================
Files 60 60
Lines 11198 11223 +25
==========================================
+ Hits 9697 9718 +21
- Misses 1501 1505 +4
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Reference tuples cannot accept a deferrable as their elements.
This is achieved nicely by extending the type checking system to support composite types and by allowing to insert in the type check subsystem any custom type. For example, one can do the following:
This mechanism allows us to remove the
other_typeargument ofTypedField, but it will probably break existingvariabledefinitions of users.Fixes #2630.