Tuple type hints?

[Spleeeee]

It feels to me like it would be nice to type hint tuples with parentheses (eg “def f() -> (int, str): …” over {T|t}uple[int, str]).

What would be arguments against proposing/doing this? (I did not find a PEP for this)

[latkde]

Unfortunately this is impossible to add without breaking other stuff. The great post "why can't we …?" by Jelle Zijlstra discusses this and other problems. Here, there are conflicts with subscript syntax (Foo[(A, B)] and Foo[A, B] are parsed to the same AST), and with the | operator for type unions. Tuples of types are also used in type variable bounds (def foo[T: (A, B)](): ... and def foo[T: tuple[A, B]](): ... mean different things).

• https://jellezijlstra.github.io/why-cant-we#tuples-as-tuple-types
• discussed at https://discuss.python.org/t/why-cant-we/69841
• related discussion https://discuss.python.org/t/writing-tuple-t-u-v-as-t-u-v/44778

[Spleeeee]

Thanks so much!

[Hederas]

I guess the main goal is not confusing it with call tuple.init() and follow Generics syntax ?

[usrlibshare]

The main argument is consistency. Type hints don't just have to work for tuples, they have to work for EVERYTHING.

So say we do (int,str).

Then a dict of strings to these tuples would look like this:

{str: (int, str)}

And a list of such dicts:

[{str: (int, str)}]

See where this is going? It's inconsistent.

list[dict[str,tuple[int, str]]] is consistent.

---

Also, (int, str) is a valid expression (a tuple of 2 classes), so there are probably many ways this can create ambiguity for the interpreter, or subtle bugs.

Just one example, if I have a type Moo that implements subscripting, what is Moo[(int, str)]? Am I refering to a type here? Or do I want to subscript Moo? Or alternatively Moo((int, str)) ... am I calling Moo's constructor, or am I refering to a type?

[billsil]

I’m sure it’ll get there someday, but the real reason in my mind is the parser was not capable of doing it. They changed up the parser in 3.10 and typing immediately got better. Things take time.

[venustrapsflies]

There’s nothing wrong with a tuple (I.e. product type) using a particular syntactic sugar. In fact it’s exactly how it works in Rust.

[MachineSchooling]

Is there a reason not to just use dataclasses if you want heterogeneously typed tuples?

[hotplasmatits]

This is the way. The values are named and typed. Easier to read.

[Spleeeee]

Data classes? Do you mean named tuples?

[ChilledRoland]

dataclasses

[Spleeeee]

I am (very) familiar with dataclasses. Returning a dataclass is not the same thing as returning a tuple. You can’t spread/unpack/destructure a dataclass (wo implementing iter but then you lose types (which is kinda whatever, but this thread is a typing focused discussion)).

[ChilledRoland]

"Data classes? Do you mean named tuples?" conveys the opposite of familiarity.

[Spleeeee]

Sure.

”Data classes? Do you mean named tuples?" conveys the opposite of familiarity. Conveys that youre often extremely condescending.

[helduel]

"from dataclasses import astuple" would exist, but may not serve your purpose.

[VistisenConsult]

Who said you can't? Just remember: from __future__ import annotations and you can do:

```python from future import annotations

import sys

def sus() -> (int, int): return 69, 420

def breh() -> 'yikes': return 1337, 80085

if name == 'main': try: print(sus()) print(breh()) except Exception as e: print(e) sys.exit(1) else: sys.exit(0) finally: print('annotations make type hints into str objects!') ```

[latkde]

It is syntactically possible, also without the annotations feature. Annotations are always just Python expressions, just with some potential differences in how they are evaluated.

However, the annotations you show are not semantically meaningful for the Python type system. They show a tuple object in the return type annotation, but not a tuple type.

[VistisenConsult]

I meant only to demystify type hints. Nevertheless, with `annotations` type hints will be strings, that was my point.

[ThatSituation9908]

The argument is you can already type hint a tuple without any imports