Runtimeerror Super() No Arguments

[Etienne Levic]

whichtwo properties of the context are used to derive the two arguments for super when it is called without any?

more generally, given any python code where the statement super() is executed, how do i determine the 2 arguments it is implicitly called with.

if this understanding of the argumentless super() call is incorrect, elaborate how it is handled instead

many thanks for your answer

This PEP is a historical document: see Variance Inference,Type aliases,Type parameter lists,The type statement andAnnotation scopes. for up-to-date specs and documentation. Canonical typing specs are maintained at the typing specs site; runtime typing behaviour is described in the CPython documentation.

While the use of type variables has become widespread, the manner in whichthey are specified within code is the source of confusion among manyPython developers. There are a couple of factors that contribute to thisconfusion.

The scoping rules for type variables are difficult to understand. Typevariables are typically allocated within the global scope, but their semanticmeaning is valid only when used within the context of a generic class,function, or type alias. A single runtime instance of a type variable may bereused in multiple generic contexts, and it has a different semantic meaningin each of these contexts. This PEP proposes to eliminate this source ofconfusion by declaring type parameters at a natural place within a class,function, or type alias declaration statement.

Generic type aliases are often misused because it is not clear to developersthat a type argument must be supplied when the type alias is used. This leadsto an implied type argument of Any, which is rarely the intent. This PEPproposes to add new syntax that makes generic type alias declarationsclear.

Defining type parameters today requires importing the TypeVar andGeneric symbols from the typing module. Over the past several releasesof Python, efforts have been made to eliminate the need to import typingsymbols for common use cases, and the PEP furthers this goal.

Here is a new syntax for declaring type parameters for genericclasses, functions, and type aliases. The syntax adds support fora comma-delimited list of type parameters in square brackets afterthe name of the class, function, or type alias.

There is no need to include Generic as a base class. Its inclusion asa base class is implied by the presence of type parameters, and it willautomatically be included in the __mro__ and __orig_bases__ attributesfor the class. The explicit use of a Generic base class will result in aruntime error.

A Protocol base class with type arguments may generate a runtimeerror. Type checkers should generate an error in this case becausethe use of type arguments is not needed, and the order of type parametersfor the class are no longer dictated by their order in the Protocolbase class.

Type parameter names within a generic class, function, or type alias must beunique within that same class, function, or type alias. A duplicate namegenerates a syntax error at compile time. This is consistent with therequirement that parameter names within a function signature must be unique.

Class type parameter names are mangled if they begin with a doubleunderscore, to avoid complicating the name lookup mechanism for names usedwithin the class. However, the __name__ attribute of the type parameterwill hold the non-mangled name.

The specified upper bound type must use an expression form that is allowed intype annotations. More complex expression forms should be flaggedas an error by a type checker. Quoted forward references are allowed.

The specified upper bound type must be concrete. An attempt to use a generictype should be flagged as an error by a type checker. This is consistent withthe existing rules enforced by type checkers for a TypeVar constructor call.

If the specified type is not a tuple expression or the tuple expression includescomplex expression forms that are not allowed in a type annotation, a typechecker should generate an error. Quoted forward references are allowed.

The specified constrained types must be concrete. An attempt to use a generictype should be flagged as an error by a type checker. This is consistent withthe existing rules enforced by type checkers for a TypeVar constructor call.

The upper bounds and constraints of TypeVar objects are accessible atruntime through the __bound__ and __constraints__ attributes.For TypeVar objects defined through the new syntax, these attributesbecome lazily evaluated, as discussed under Lazy Evaluation below.

As with typing.TypeAlias, type checkers should restrict the right-handexpression to expression forms that are allowed within type annotations.The use of more complex expression forms (call expressions, ternary operators,arithmetic operators, comparison operators, etc.) should be flagged as anerror.

When the new syntax is used, a new lexical scope is introduced, and this scopeincludes the type parameters. Type parameters can be accessed by namewithin inner scopes. As with other symbols in Python, an inner scope candefine its own symbol that overrides an outer-scope symbol of the same name.This section provides a verbal description of the new scoping rules.The Scoping Behavior section below specifies the behavior in termsof a translation to near-equivalent existing Python code.

Type parameters are visible to othertype parameters declared elsewhere in the list. This allows type parametersto use other type parameters within their definition. While there is currentlyno use for this capability, it preserves the ability in the future to supportupper bound expressions or type argument defaults that depend on earliertype parameters.

A type parameter declared as part of a generic class is valid within theclass body and inner scopes contained therein. Type parameters are alsoaccessible when evaluating the argument list (base classes and any keywordarguments) that comprise the class definition. This allows base classesto be parameterized by these type parameters. Type parameters are notaccessible outside of the class body, including class decorators.

A type parameter declared as part of a generic function is valid withinthe function body and any scopes contained therein. It is also valid withinparameter and return type annotations. Default argument values for functionparameters are evaluated outside of this scope, so type parameters arenot accessible in default value expressions. Likewise, type parameters are notin scope for function decorators.

Consistent with the scoping rules defined in PEP 484, type checkers shouldgenerate an error if inner-scoped generic classes, functions, or type aliasesreuse the same type parameter name as an outer scope.

When the new type parameter syntax is used for a generic class, assignmentexpressions are not allowed within the argument list for the class definition.Likewise, with functions that use the new type parameter syntax, assignmentexpressions are not allowed within parameter or return type annotations, norare they allowed within the expression that defines a type alias, or withinthe bounds and constraints of a TypeVar. Similarly, yield, yield from,and await expressions are disallowed in these contexts.

This restriction is necessary because expressions evaluated within thenew lexical scope should not introduce symbols within that scope other thanthe defined type parameters, and should not affect whether the enclosing functionis a generator or coroutine.

A new attribute called __type_params__ is available on generic classes,functions, and type aliases. This attribute is a tuple of thetype parameters that parameterize the class, function, or alias.The tuple contains TypeVar, ParamSpec, and TypeVarTuple instances.

This PEP eliminates the need for variance to be specified for typeparameters. Instead, type checkers will infer the variance of type parametersbased on their usage within a class. Type parameters are inferred to beinvariant, covariant, or contravariant depending on how they are used.

Python type checkers already include the ability to determine the variance oftype parameters for the purpose of validating variance within a genericprotocol class. This capability can be used for all classes (whether or notthey are protocols) to calculate the variance of each type parameter.

2. If the type parameter comes from a traditional TypeVar declaration andis not specified as infer_variance (see below), its variance is specifiedby the TypeVar constructor call. No further inference is needed.

4. Determine whether lower can be assigned to upper using normal typecompatibility rules. If so, the target type parameter is covariant. If not,determine whether upper can be assigned to lower. If so, the targettype parameter is contravariant. If neither of these combinations areassignable, the target type parameter is invariant.

The existing TypeVar class constructor accepts keyword parameters namedcovariant and contravariant. If both of these are False, thetype variable is assumed to be invariant. We propose to add another keywordparameter named infer_variance indicating that a type checker should useinference to determine whether the type variable is invariant, covariant orcontravariant. A corresponding instance variable __infer_variance__ can beaccessed at runtime to determine whether the variance is inferred. Typevariables that are implicitly allocated using the new syntax will alwayshave __infer_variance__ set to True.

It is OK to combine traditional type variables with new-style type parametersif the class, function, or type alias does not use the new syntax. Thenew-style type parameters must come from an outer scope in this case.

It also modifies existing AST node types FunctionDef, AsyncFunctionDefand ClassDef to include an additional optional attribute calledtypeparams that includes a list of type parameters associated with thefunction or class.

This PEP introduces three new contexts where expressions may occur that representstatic types: TypeVar bounds, TypeVar constraints, and the value of typealiases. These expressions may contain references to namesthat are not yet defined. For example, type aliases may be recursive, or even mutuallyrecursive, and type variable bounds may refer back to the current class. If theseexpressions were evaluated eagerly, users would need to enclose such expressions inquotes to prevent runtime errors. PEP 563 and PEP 649 detail the problems withthis situation for type annotations.

3a8082e126