6 ms·

> Python not only has types but it's type system is superior to typeScript. I strongly disagree. It might be better at some things, but it's much worse at othe

by Timon3 3y ago

> Python not only has types but it's type system is superior to typeScript. I strongly disagree. It might be better at some things, but it's much worse at others. Many functions can't be accurately typed (try, for example, to make a well-typed function that concatenates two arbitrary fixed-size tuples), and as far as I know generic type transformations can't be implemented (random example "this type takes a Dict[str, Any] and returns an object with each key turned into a function").

dazzlefruit 3y ago
For the tuple example: from typing import TypeVar T, U, V, W = TypeVar('T'), TypeVar('U'), TypeVar('V'), TypeVar('W') def concatenate(a: tuple[T, U], b: tuple[V, W]) -> tuple[T, U, V, W]: return a + b For the generic type transformation example, I'm not sure what you mean: from typing import Any, Callable Transformer = Callable[[dict[str, Any]], dict[Callable, Any]] This seems to match your question but it's really weird.
- Timon3 3y ago
  Your tuple example only works if both tuples have two elements. I specifically mentioned arbitrary fixed-size tuples (as in, tuples with an arbitrary non-variable length). Your generic type transformation example also doesn't come close to what Typescript does. The resulting dict will not have known keys based on the keys of the input dict. In Typescript I can write a function that takes an object with known keys, and it returns an object with those same keys having their values mapped to a different type, with the keys still known. I threw together a quick example - just look at the type of resultA/resultB by hovering over the variables[0]. But both are great examples - they are probably the closest you can get in Python, and they are so far removed from the thing I want to represent that they are completely useless. [0]: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhjAvDA3gKBjAZiEAuGKAJwFcBTAGgxgCM4iCs4AbCS6ugLwLBOeaoBfNGlCRYNJKmo58MACwAmKpjoMYAIgAWZfiBgB3EEWYATDStpxuMANoBdISKwkwwKAEtwhInEg4iAFsAeRoAKzJ3AB4AFRgyAA8oMjBTCBgAJUjjUyjoIg8wAHMKeDAATwA+SoAKEHCCGIBKAhQ7AGkYQpgAazJykCwYGPsCGqakSuHbdvsYQWlMIjIoEiIwGAB6TcIQUxA0YVFwaBhliD4oAEEpYj8IAJDwyKgauCbj8TOyC+YoACFbr5-MYnhF3DUaE0gA https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhjAvDA...
  - Izkata 3y ago
    Tuples are already fixed size by nature, so adding a redundant "fixed-size" in that description was confusing. I also thought you meant a predefined size like always 2-tuples or always 3-tuples.
    - Timon3 3y ago
      > Tuples are already fixed size by nature, so adding a redundant "fixed-size" in that description was confusing. No, you can type variable-length tuples in Python. A variable int tuple, for example, can be typed as Tuple[int, ...]. You can't concatenate two variable-length tuples, which makes sense - where would the cutoff be? But you should absolutely be able to concatenate two fixed-size tuples, and it's very limiting that you can't.
      - Izkata 3y ago
        > A variable int tuple, for example, can be typed as Tuple[int, ...]. That's a type that matches tuples of any length, not a variable-length tuple. The size of a tuple can't be changed. A variable-length tuple doesn't even really make sense, what you'd want there is a list. > You can't concatenate two variable-length tuples, which makes sense - where would the cutoff be? But you should absolutely be able to concatenate two fixed-size tuples, and it's very limiting that you can't. This whole statement doesn't make sense. I'm assuming you're still talking about type definitions and not actually tuples.
        Timon3 3y ago
        > That's a type that matches tuples of any length, not a variable-length tuple. A tuple with a type that matches variable lengths of tuples is a variable-length tuple for that piece of code. You're free to show me some official definitions that proves this wording false, but until then it's useless nitpicking. Though you should probably take that up with Guido, who also calls them variable-length tuples: https://github.com/python/typing/issues/30 https://github.com/python/typing/issues/30 > This whole statement doesn't make sense. I'm assuming you're still talking about type definitions and not actually tuples. The statement makes perfect sense, thank you. If you have trouble understanding my messages without me repeating the whole definition every time, maybe just skip them.
dragonwriter 3y ago
Python can almost do this with Variadic Generics from Python 3.11; its missing an exception to the single-unpacking rule (which exists to prevent ambiguity) to allow unambiguous cases. Then you would have: from typing import TypeVarTuple Ts = TypeVarTuple("Ts”) Us = TypeVarTuple("Us”) def tconcat( t1: tuple[*Ts], t2: tuple[*Us] ) -> tuple[*Ts, *Us]: ...
- Timon3 3y ago
  That's the conclusion I also arrived at. The type system is slowly getting there, but many operations like this one are still not possible. It's a shame, because it makes features like decorators significantly harder to use with static typing.
  - corethree 3y ago
    I haven't seen a type system that allows variadic types for Tuples. This would be equivalent to creating a struct with variadic amount of properties. The definition for tuples here is similar to a struct. They are one in the same except structs have names for each property while tuples don't. That is literally the main concept of a tuple, just a struct with no names for properties. The type system for python is already "there", it is in fact superior to many other type systems from other popular languages.
    - Timon3 3y ago
      That's confusing, considering Python has them with TypeVarTuples?
      - corethree 3y ago
        Yeah they're getting flexible with the definitions. The developers are committees of people many of which don't know type theory and introduce arbitrary concepts based off of misguided intuitions. It's the same with typescript I'm sure. You will note that this thing doesn't exist in haskell for tuples because haskell devs tend to be well versed with concept of what a tuple is.
corethree 3y ago
def concat_tuples(tuple1: Tuple[int, str, float], tuple2: Tuple[str, str, str]) -> Tuple[int, str, float, str, str, str]: return tuple1 + tuple2 Your second function you just broke out of the type system with Any. Give me a more exact, are you saying Any is a constrained type variable? The only possibility here is this: T = TypeVar('T') def transform(x: Dict[str, T]) -> Dict[str, Callable[[], T]]: return {key: lambda : value for key, value in x.items()} If you want that lambda to do something else you have to constrain T. Constraining T will give me more options in the definition: from numbers import Number def transform2(x: Dict[str, Number]) -> Dict[str, Callable[[Number], Number]]: return {key: lambda y: value + y for key, value in x.items()} def transform3(x: Dict[str, Number]) -> Dict[str, Callable[[], Number]]: return {key: lambda: value + value for key, value in x.items()} etc... The thing is because these type checkers are external, anyone can add arbitrary features to them and extend it. Someone can make it to the level of proof checking... eliminating the need for testing in general. Of course the syntax has to support it too.
- Timon3 3y ago
  > concat_tuples I specifically talked about arbitrary tuples. Your function only handles specific tuples. > Your second function you just broke out of the type system with Any. Give me a more exact, are you saying Any is a constrained type variable? I'm not sure what you're trying to say here. Yes, you can implement the function, I never claimed otherwise. I'm talking about the _type system_. > The thing is because these type checkers are external, anyone can add arbitrary features to them and extend it. The type system is a core feature of Python. Until it supports what I want, I can't really use what I want with Python.
  - corethree 3y ago
    >I'm not sure what you're trying to say here. Yes, you can implement the function, I never claimed otherwise. I'm talking about the _type system_. The type constrains the definition. Look at the definition, there is ONLY one possible definition when converting this: Dict[str, T] -> Dict[str, Callable[[], T]] Literally. Try to think of another way to define the lambda, you can't. The more open the type the more constrained the definition the more constrained the type the more open the definition. > I specifically talked about arbitrary tuples. Your function only handles specific tuples. I remarked on this in other replies. How will you define the return value of the concat and have it exactly type correct? It's not possible bro. You can't do much with tuples of arbitrary types. Not unless you have dependent types. >The type system is a core feature of Python. Until it supports what I want, I can't really use what I want with Python. Type checking in python is an external application. The interpreter doesn't do any type check. Type checking is achieved by running another program. All kinds of additional features and custom interpretations on types can be inserted into these type checkers.

by Timon3 3y ago

dazzlefruit 3y ago

For the tuple example: from typing import TypeVar T, U, V, W = TypeVar('T'), TypeVar('U'), TypeVar('V'), TypeVar('W') def concatenate(a: tuple[T, U], b: tuple[V, W]) -> tuple[T, U, V, W]: return a + b For the generic type transformation example, I'm not sure what you mean: from typing import Any, Callable Transformer = Callable[[dict[str, Any]], dict[Callable, Any]] This seems to match your question but it's really weird.

Timon3 3y ago
Your tuple example only works if both tuples have two elements. I specifically mentioned arbitrary fixed-size tuples (as in, tuples with an arbitrary non-variable length). Your generic type transformation example also doesn't come close to what Typescript does. The resulting dict will not have known keys based on the keys of the input dict. In Typescript I can write a function that takes an object with known keys, and it returns an object with those same keys having their values mapped to a different type, with the keys still known. I threw together a quick example - just look at the type of resultA/resultB by hovering over the variables[0]. But both are great examples - they are probably the closest you can get in Python, and they are so far removed from the thing I want to represent that they are completely useless. [0]: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhjAvDA3gKBjAZiEAuGKAJwFcBTAGgxgCM4iCs4AbCS6ugLwLBOeaoBfNGlCRYNJKmo58MACwAmKpjoMYAIgAWZfiBgB3EEWYATDStpxuMANoBdISKwkwwKAEtwhInEg4iAFsAeRoAKzJ3AB4AFRgyAA8oMjBTCBgAJUjjUyjoIg8wAHMKeDAATwA+SoAKEHCCGIBKAhQ7AGkYQpgAazJykCwYGPsCGqakSuHbdvsYQWlMIjIoEiIwGAB6TcIQUxA0YVFwaBhliD4oAEEpYj8IAJDwyKgauCbj8TOyC+YoACFbr5-MYnhF3DUaE0gA https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhjAvDA...
- Izkata 3y ago
  Tuples are already fixed size by nature, so adding a redundant "fixed-size" in that description was confusing. I also thought you meant a predefined size like always 2-tuples or always 3-tuples.
  - Timon3 3y ago
    > Tuples are already fixed size by nature, so adding a redundant "fixed-size" in that description was confusing. No, you can type variable-length tuples in Python. A variable int tuple, for example, can be typed as Tuple[int, ...]. You can't concatenate two variable-length tuples, which makes sense - where would the cutoff be? But you should absolutely be able to concatenate two fixed-size tuples, and it's very limiting that you can't.
    - Izkata 3y ago
      > A variable int tuple, for example, can be typed as Tuple[int, ...]. That's a type that matches tuples of any length, not a variable-length tuple. The size of a tuple can't be changed. A variable-length tuple doesn't even really make sense, what you'd want there is a list. > You can't concatenate two variable-length tuples, which makes sense - where would the cutoff be? But you should absolutely be able to concatenate two fixed-size tuples, and it's very limiting that you can't. This whole statement doesn't make sense. I'm assuming you're still talking about type definitions and not actually tuples.
      - Timon3 3y ago
        > That's a type that matches tuples of any length, not a variable-length tuple. A tuple with a type that matches variable lengths of tuples is a variable-length tuple for that piece of code. You're free to show me some official definitions that proves this wording false, but until then it's useless nitpicking. Though you should probably take that up with Guido, who also calls them variable-length tuples: https://github.com/python/typing/issues/30 https://github.com/python/typing/issues/30 > This whole statement doesn't make sense. I'm assuming you're still talking about type definitions and not actually tuples. The statement makes perfect sense, thank you. If you have trouble understanding my messages without me repeating the whole definition every time, maybe just skip them.

dragonwriter 3y ago

Python can almost do this with Variadic Generics from Python 3.11; its missing an exception to the single-unpacking rule (which exists to prevent ambiguity) to allow unambiguous cases. Then you would have: from typing import TypeVarTuple Ts = TypeVarTuple("Ts”) Us = TypeVarTuple("Us”) def tconcat( t1: tuple[*Ts], t2: tuple[*Us] ) -> tuple[*Ts, *Us]: ...

Timon3 3y ago
That's the conclusion I also arrived at. The type system is slowly getting there, but many operations like this one are still not possible. It's a shame, because it makes features like decorators significantly harder to use with static typing.
- corethree 3y ago
  I haven't seen a type system that allows variadic types for Tuples. This would be equivalent to creating a struct with variadic amount of properties. The definition for tuples here is similar to a struct. They are one in the same except structs have names for each property while tuples don't. That is literally the main concept of a tuple, just a struct with no names for properties. The type system for python is already "there", it is in fact superior to many other type systems from other popular languages.
  - Timon3 3y ago
    That's confusing, considering Python has them with TypeVarTuples?
    - corethree 3y ago
      Yeah they're getting flexible with the definitions. The developers are committees of people many of which don't know type theory and introduce arbitrary concepts based off of misguided intuitions. It's the same with typescript I'm sure. You will note that this thing doesn't exist in haskell for tuples because haskell devs tend to be well versed with concept of what a tuple is.

corethree 3y ago

def concat_tuples(tuple1: Tuple[int, str, float], tuple2: Tuple[str, str, str]) -> Tuple[int, str, float, str, str, str]: return tuple1 + tuple2 Your second function you just broke out of the type system with Any. Give me a more exact, are you saying Any is a constrained type variable? The only possibility here is this: T = TypeVar('T') def transform(x: Dict[str, T]) -> Dict[str, Callable[[], T]]: return {key: lambda : value for key, value in x.items()} If you want that lambda to do something else you have to constrain T. Constraining T will give me more options in the definition: from numbers import Number def transform2(x: Dict[str, Number]) -> Dict[str, Callable[[Number], Number]]: return {key: lambda y: value + y for key, value in x.items()} def transform3(x: Dict[str, Number]) -> Dict[str, Callable[[], Number]]: return {key: lambda: value + value for key, value in x.items()} etc... The thing is because these type checkers are external, anyone can add arbitrary features to them and extend it. Someone can make it to the level of proof checking... eliminating the need for testing in general. Of course the syntax has to support it too.

Timon3 3y ago
> concat_tuples I specifically talked about arbitrary tuples. Your function only handles specific tuples. > Your second function you just broke out of the type system with Any. Give me a more exact, are you saying Any is a constrained type variable? I'm not sure what you're trying to say here. Yes, you can implement the function, I never claimed otherwise. I'm talking about the _type system_. > The thing is because these type checkers are external, anyone can add arbitrary features to them and extend it. The type system is a core feature of Python. Until it supports what I want, I can't really use what I want with Python.
- corethree 3y ago
  >I'm not sure what you're trying to say here. Yes, you can implement the function, I never claimed otherwise. I'm talking about the _type system_. The type constrains the definition. Look at the definition, there is ONLY one possible definition when converting this: Dict[str, T] -> Dict[str, Callable[[], T]] Literally. Try to think of another way to define the lambda, you can't. The more open the type the more constrained the definition the more constrained the type the more open the definition. > I specifically talked about arbitrary tuples. Your function only handles specific tuples. I remarked on this in other replies. How will you define the return value of the concat and have it exactly type correct? It's not possible bro. You can't do much with tuples of arbitrary types. Not unless you have dependent types. >The type system is a core feature of Python. Until it supports what I want, I can't really use what I want with Python. Type checking in python is an external application. The interpreter doesn't do any type check. Type checking is achieved by running another program. All kinds of additional features and custom interpretations on types can be inserted into these type checkers.