I would be happy to make tensors in most numeric libraries default to float. Most tensors I come across in numpy/tensorflow are float/int tensors and given int < float making default be float would capture most usages. There are occasionally times where other tensors like string tensor are used, but I think it's reasonable to expect those to specify type variable. Similarly for tensorflow most layers take 1 tensor as input and return 1 tensor as output. But layer is free to take much more complex types so I still use Layer(Generic[InputT, OutputT]). In practice how I've handled this so far is not with aliases, but with subclasses. So I have, class LayerGeneric(Generic[InputT, OutputT]): ... class Layer(LayerGeneric[Tensor, Tensor]): ... Since alias does not work for isinstance/issubclass checks, but a subclass does. Those are the 2 biggest examples I've encountered where I would probably use this.

Maybe I'm just misinformed but I can't see any reason to add support for this, _QuerySet should probably only have one type parameter if you can use that work around. Ontop of that, It would probably be very hard to support this, are there any other languages that you know of that have this feature?

I’m currently skiing and just following along between runs so I can’t offer links or a concrete example, but Hacklang/HHVM also supports defaults for generics based on other generics on a type. Jon

On Mar 5, 2022, at 12:22, James H-B wrote:

I've just realised Rust actually supports this, I might mention this, I'll have to think about how hard it is to implement. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9c7043e365f44f97f42a36e1cd62655d _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jon@jonjanzen.com

Thanks for writing this proposal. I do think this is a valuable addition to the type system, and I’m generally supportive of the idea as long as it remains simple and we can avoid feature creep. Here are some thoughts… *Default ordering* I'm not convinced that we need to enforce ordering here. In effect, every type variable already has an implicit default value of `Any`, so it is unnecessary for type checkers or the runtime to detect cases where a TypeVar with no explicit default comes after a TypeVar with an explicit default. This is just added complexity that limits flexibility of the feature. I recommend deleting this entire section. I noticed that there's a section under "rejected alternatives" that tries to justify the default ordering constraint. I don't buy the justification here because, as I mentioned above, there's really no such thing as a TypeVar without a default. There's just "explicit defaults" and "implicit defaults". That's a very different situation from parameters in a call signature. *Constrained TypeVars* You talk about the interaction between bound TypeVars and default, but you don’t specify the interaction between constrained TypeVars and default. For constrained TypeVars, I think the default needs to be the same type as one of the constraints. It would be an error if it were a subtype. ```python T1 = TypeVar("T1", int, str, default=int) # OK T2 = TypeVar("T2", int, str, default=float) # Error ``` *Use of generics in default* The PEP doesn't explicitly disallow the use of generics in the default type. I think this is implied, but it would be better if it was explicitly called out as invalid. ```python T1 = TypeVar("T1", default=T) # Error T2 = TypeVar("T2", default=list[T]) # Error ``` *Function defaults* I don't understand why a function parameter annotated with a TypeVar with a default must have a default argument value associated with it. Why are the two concepts (a default type argument type and a default argument value for a parameter) related? If this is required, what about more complicated parameter type annotations that involve a TypeVar with a default type argument, such as `T | None` or `List[T]`? What about cases where the TypeVar appears for multiple input parameters? ```python DefaultIntT = TypeVar("DefaultIntT", default=int) def bar(a: DefaultInt = 0, b: DefaultInt = 0) -> DefaultInt: ... bar(3.14) ``` Unless there's a strong justification for tying these two concepts together, I would recommend deleting this entire section and removing this constraint. I think it unnecessarily complicates the design and takes us down a rabbit hole of additional concerns that would need to be discussed and addressed in the PEP. Let's avoid that if possible. *TypeVarTuple* Can more complex forms of unpacked tuples be used in the default value? I think the answer is probably yes, but it would be good to include an example. ```python Ts = TypeVarTuple("Ts", default=(int, *tuple[float, ...], str)) ``` *TypeVarTuple "subscription"* This subsection could use some additional text to explain the problem and the proposed solution. I'm trying to infer the intent from the code sample. I think the intent here is to avoid an ambiguity when a TypeVarTuple is used with a "suffix" that includes a TypeVar with a default. There are two ways to avoid that ambiguity. One is to disallow the use of a TypeVar with a default in a suffix. The other way is to simply document how it will be interpreted in that case. Your sample here seems to imply that it works in a prefix position by requiring that a type argument be provided explicitly. Maybe that's the same rule that should apply for suffixes. I don't have a strong opinion on this one, but I prefer consistency between prefixes and suffixes unless there's a good reason for them to be inconsistent. *ParamSpec Defaults* Is `...` a legal default for ParamSpec? It probably should be, since that's the implicit default. I presume that Concatenate cannot be used in a ParamSpec default. It might be good to call that out explicitly. *Missing type argument detection and reporting* Pyright has a diagnostic rule called reportMissingTypeArgument that emits a diagnostic when a generic class is used in an annotation without providing the expected type arguments. I don't know if mypy, pyre or pytype have a similar feature. The introduction of default type argument values will necessarily affect that logic. I don't know if this is worth mentioning in the PEP. It's something I'll need to consider if/when I implement this feature in pyright. *Specifying a default of Any* I wonder if the PEP should express an opinion about an explicit default of `Any`. The implicit default is already `Any`, but there's an important distinction between the two, at least for pyright which distinguishes between explicit `Any` and implicit `Any`, which it refers to as `Unknown`. I would like to encourage people (especially library authors) _not_ to use an explicit `Any` default, because that will potentially mask type errors. *Alternative syntax* Shantanu suggested an alternative syntax that brings the default closer to the code. I'd recommend against doing that in this PEP. I think we all recognize that the current syntax for TypeVars in Python is problematic and a fix is needed, but let's not do it piecemeal. That's bound to create problems. I like that this proposal fits in nicely with the existing TypeVar infrastructure and syntax. If we deviate from that, getting the PEP accepted will be more difficult, and we're likely to complicate our efforts in the future to improve the overall syntax for TypeVars. *Specifying defaults of one TypeVar in terms of another TypeVar* @syastrov asked whether the default type argument for one TypeVar could depend on the type argument provided for a different TypeVar. I understand the use case, but I'd strongly push back on this requirement. Many programming languages have support for default type arguments, but I've never seen one that supports defaults that depend on other type argument values — and there's a good reason for this. It would greatly complicate the design. Perhaps there are other ways to solve the problem with django stubs, but this doesn't strike me as a viable solution. -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft

I have a preference for having the defaults live close to the class. TypeVar scoping and binding is kind of confusing as is.

Completely agree on this point, it's really unfortunate that 637 was rejected. I've updated the draft to add a note about how some metaclasses/supertypes might already consume a parameter with the same name as the TypeVar.

It might be worth spelling out the rules for generic subclasses of generic classes that both have defaulted TypeVars are.

Good idea, done.

It'd also be good to write up some more real-world-code places where this would be useful.

I've added the both the projects from Mehdi2277 and also discord.py which is where the Context example is from.

To what extent would we still want this if we had a commonly used `GenIter = Generator[T, None, None]` generic type alias in typing.py?

Whilst Generator is a compelling use case for this it's certainly not the only place this comes up. Adding type aliases for all of these cases would be annoying and potentially error prone. As others have pointed out it means creating intermediary classes which makes code more confusing to read. Not only that there are also cases that currently can't be supported without defaults like Context where there would have to be two different exported classes for it to work (e.g. BotContext and Context[BotT]) where users could be confused as when they should use one over the other.

Am 05.03.22 um 00:33 schrieb Shantanu Jain:

I have a preference for having the defaults live close to the class.

Ideally, generics would be initialized at the point where they are used, like in all other languages I'm familiar with. But I don't think we can do this is in a readable manner without new syntax, and that is unlikely to happen soon, considering the SC's stance on typing features. For the moment I think defining the default as part of the TypeVar declaration is the best option, so as not to split the definition of the type var across multiple places.  - Sebastian

Am 07.03.22 um 17:46 schrieb Guido van Rossum:

On Mon, Mar 7, 2022 at 3:11 AM Sebastian Rittau wrote:

Ideally, generics would be initialized at the point where they are used, like in all other languages I'm familiar with. But I don't think we can do this is in a readable manner without new syntax, and that is unlikely to happen soon, considering the SC's stance on typing features.

I wouldn't be quite so pessimistic. The SC rejected PEP 677 at least in part because, being a type annotation, it has to be an expression, but it's a form of expression that's not useful in other contexts.

If we're considering syntax to replace TypeVar(), like

def foo<T>(arg1: T, arg2: T) -> list[T]:     ...

class C:     def __init__(self, arg1: T, arg2: S):         self.attr1 = arg1         self.attr2 = attr2     ...

that would not be general expression syntax. (It would be good to poll on python-dev what people would think of such a proposal though.)

Not python-dev and not really relevant for this discussion, but I would really like to see "standard" generic syntax, as in your example, in Python.  - Sebastian

I see the benefits of allowing other TypeVarLike as the default, but I suspect there are complexities and edge-case behaviors that are not contemplated or described in the PEP. A few comments about this section as it's currently written: * It says "they have to be of the same type". By "type", I presume that you mean TypeVar vs ParamSpec vs TypeVarTuple, right? The word "type" is a bit ambiguous here. * Is it allowed for the second type variable to be bound to some type that is parameterized by the first type variable? For example, T1 = TypeVar("T1"), T2 = TypeVar("T2", default=list[T1])? Or is this disallowed? * Can a default refer to a TypeVar scoped to an outer class or function? If not, why? * It says "must be used before in the signature of the class". This wording probably needs to be tightened up somewhat because the order in which TypeVars appear is not always the order in which they parameterize the class. The order can be explicitly overridden through the use of a Generic or Protocol. And if PEP 695 passes, it will always be explicit. * The section mentions only classes. Is it intended to work also with generic functions and type aliases? * There are two ways to specialize a generic type: explicitly (using a subscript expression) and through the use of a call expression, which uses the constraint solver to "solve" the type arguments. This section focuses on explicit specialization. Have you considered the impact on specialization through a call expression? Consider, for example, if T2 has a default type of T1. If the constraint solver doesn't produce a solution for T2, it presumably "adopts" the default type which is solved value of T1. What if the converse occurs (i.e. T1 has no solution but T2 does)? I'd feel more confident if someone were to prototype this feature in an existing type checker and work out all of the above edge cases and discover if there are any others. Is such an effort under way? -Eric