Optional attributes and kernels #9
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The following ARTIQ issue points out an interesting use-case https://github.com/m-labs/artiq/issues/1654 .
In this scenario, we have an optional attribute that should be annotated kernel invariant. The same could happen with regular kernel attributes.
The typing proposed in #5 and #8 with type annotations as part of the class definition does not support dynamically adding type annotations at runtime.
How will we deal with this situation?
Potential ideas:
I guess the first one is actually fine and easy from a user perspective, but not sure what your perspective is. The other two are maybe undesired from a user or compiler perspective.
I suggest adding a pseusocomment that disables the warning, e.g.
For 1, what should we do if we try to access it without initializing it? Runtime exception? And should we add a way to check if the field is initialized or not?
For Python typing, there is a type called
Optional[T]
which does exactly this.Maybe we should also change the
Union
in our previous proposal into this:As we previously wanted to make the type static.
Those runtime checks would reduce performance. And I think there could be a compilation error in this case?
In the example above
Optional[int32]
would cover the case wherex
can also have the valueNone
, but not the actual situation where thex
attribute does not exist.OK I guess I misunderstood the requirement here, I thought we are dealing with something like a null value. It should be possible to use something like a pseudocomment, or annotation if it can be supported (something like
@no_warn_unused
), and we could return an error when the user try to access it without checking if the field is initialized (the check should be optimized away in the compiled binary, as the information should be available statically)btw, what do you think about the idea about union I mentioned previously? I do think users may want to have union that requires runtime type checking.
Maybe I was not clear enough, but I am on the same line with Sebastien. This was not about a Null/None value. For this case, annotating an attribute that might or might not be initialized, I would expect a compile error if the attribute is not available but still accessed in a kernel.
I like the
# nac3:no_warn_unused
idea because it matches the style of many other tools (e.g. mypy, flake8). I do not think a decorator, such as@no_warn_unused
, can be used on a type annotation, that is a syntax error (see below). A class-wide suppression for warnings seems undesired.Syntax error for decorating a type annotation
For the
Union
and theTypeVar
, these two things are used for different scenarios and have distinct purposes. I think bothUnion
andTypeVar
should be allowed in function signatures to prevent users from having to make many one-useTypeVar
objects. Like the snippet below would otherwise need two separateTypeVar
objects to describe the behavior of two unions.pca006132 referenced this issue2021-06-09 10:01:32 +08:00