3 ms·

Is there a utility to having your types and your values in the same namespace? The extra [ is not a typo, the syntax is: `Callable[[Arg1Type, Arg2Type], Return

Is there a utility to having your types and your values in the same namespace? The extra [ is not a typo, the syntax is: `Callable[[Arg1Type, Arg2Type], ReturnType]`. Or, if the arguments don't matter, `Callable[..., ReturnType]`, but this does not mean that the type is not a valid expression. Edit: I was missing a ] actually, separating the arguments from the return value.

a1369209993 8y ago
> Is there a utility to having your types and your values in the same namespace? Well somewhat[0], but the main putative benefit would be having types be valid expressions in the target language, since you can do type-checking with function decorators, and generally interact with types useing the normal language mechanism for interacting with values, rather than some horrid bolted-on piece of crap like C++ templates. Server = Tuple[Address,ConnectionOptions] # array subscipt might not the best choice here, but it works UserId = NewType('UserId',int) # ordinary function call Scalar = int | str # could be equivalent to Union[int,str] with appropriate value of Type.__or__ 0: for example: def intBit(N): if N==0: return type(None) if N==1: return Bool if N>INT_WIDTH: return long return int
- basil-rash 8y ago
  mypy's response to that code: error:invalid type comment or annotation note:Suggestion: use intBit[...] instead of intBit(...) So what's really happening is the type expressions are pretending to be "just everyday python", but actually they have arbitrary restrictions (cannot be functions? need to work via overriding `__getitem__`?) that neither you nor I were aware of. This is probably the least "pythonic" implementation possible. And even if the code were valid, it's relying on N being a statically known value, which is a bit off because sure, you could have N be some global const config variable, but it would be very weird for configuring the value of the variable to require you to also go into the code and change things around to work with bool's or None's instead of int's.
  - a1369209993 8y ago
    > So what's really happening is the type expressions are pretending to be "just everyday python", but actually they have arbitrary restrictions (cannot be functions? need to work via overriding `__getitem__`?) that neither you nor I were aware of. Yeah, that sounds about par for the course for bolt-on static-y typing in languages that aren't supposed to be statically typed.
    - basil-rash 8y ago
      At least we have TS.

a1369209993 8y ago

> Is there a utility to having your types and your values in the same namespace? Well somewhat[0], but the main putative benefit would be having types be valid expressions in the target language, since you can do type-checking with function decorators, and generally interact with types useing the normal language mechanism for interacting with values, rather than some horrid bolted-on piece of crap like C++ templates. Server = Tuple[Address,ConnectionOptions] # array subscipt might not the best choice here, but it works UserId = NewType('UserId',int) # ordinary function call Scalar = int | str # could be equivalent to Union[int,str] with appropriate value of Type.__or__ 0: for example: def intBit(N): if N==0: return type(None) if N==1: return Bool if N>INT_WIDTH: return long return int

basil-rash 8y ago
mypy's response to that code: error:invalid type comment or annotation note:Suggestion: use intBit[...] instead of intBit(...) So what's really happening is the type expressions are pretending to be "just everyday python", but actually they have arbitrary restrictions (cannot be functions? need to work via overriding `__getitem__`?) that neither you nor I were aware of. This is probably the least "pythonic" implementation possible. And even if the code were valid, it's relying on N being a statically known value, which is a bit off because sure, you could have N be some global const config variable, but it would be very weird for configuring the value of the variable to require you to also go into the code and change things around to work with bool's or None's instead of int's.
- a1369209993 8y ago
  > So what's really happening is the type expressions are pretending to be "just everyday python", but actually they have arbitrary restrictions (cannot be functions? need to work via overriding `__getitem__`?) that neither you nor I were aware of. Yeah, that sounds about par for the course for bolt-on static-y typing in languages that aren't supposed to be statically typed.
  - basil-rash 8y ago
    At least we have TS.