With the new variable annotation syntax, it is possible to implement a
useful "modifiers" library, all used as superclasses.
* Named / Struct: annotation-defined fields. No monkey patching.
* Immutable / Const
* Sealed / Final: unsubclassable class
* Array: a mutable tuple. (No "+" or "*" operators)
There of course may be others. Subclasses of the modifiers get default
methods and behavior.
The modifiers can used in combinations. For example:
class Command(Immutable, Named):
cmd : str = "NOP"
value : int = None
load = Command(cmd="load", value=1000) # no positional arguments
The syntax for Array is less pretty:
_0 : str = "NOP"
_1 : int = None
load = Command("load", 1000) # no positional arguments
Many other combinations are useful too. "Sealed" is almost orthogonal to
the others, Obviously, some combinations already exists:
* (Immutable, Array) is similar to Tuple
* NamedTuple is another name for (Immutable, Named, Array).
* Enum should be on this list too
Some less promising modifiers:
* Namespace / Static: uninstantiable class. A module.
* Volatile, for externally facing classes. Hints the static checkers /
jitters that they should not assume they know the values.
Alternatives and cons :
I suggest base classes instead of decorators since NamedTuple and tuple go
this way, and since it is static information. I am not sure which is better
Metaclass parameters can be used (and actually used in my implementation,
and in NamedTuple's), but the syntax is uglier.
"array" is only for numeric values in Python, so this name is
problematic.So is struct.
I have a rough implementation for most of the above; much of it is not hard
in general, though some details are hard to get right.
Benefits of putting such a collection in stdlib (instead of as an external
1. This information can be used by typecheckers, and also by users, to
reason about programs. If isinstance(x, ImmutableArray), then x is an
instantiation of ImmutableArray.
2. A conventional syntax and a single answer for "How do I make my class
immutable", "How do I make my class unsubclassable"
3. The syntax, especially for Struct as above, is pretty and clean. The
Array syntax is less so.
4. I think that the array implementation can use internal CPython details
to be implemented efficiently.
I am not sure that typing.modifiers is the right place, since these are not
exactly type hints; they generate methods, and are intended to be enforced
I think that even if this idea is not accepted, the general theme is
something that might be useful to keep in mind, stdlib might accumulate
such modifiers, and it will be nice to keep things uniform.