[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

2022-07-12 Thread Petr Viktorin 

On 12. 07. 22 6:30, Guido van Rossum wrote:
After several rounds of debate on typing-sig, I'd like to request 
feedback on PEP 695: https://peps.python.org/pep-0695/ 



I am sponsoring this PEP, which was written by Eric Traut. The PEP 
attempts to solve the problem that defining generic classes, functions 
and type aliases currently is lacking dedicated syntax, instead using 
the cumbersome `T = TypeVar("T", ...)` notation to create global 
variables that serve as type variables.


As a personal historical note, I should mention that over 22 years ago I 
already pondered type parameters. In an old document that I saved I 
found the following code snippet:

```
def f (a: T) -> T: ...
```
which is eerily close to the proposal in this PEP, except that the PEP 
uses square brackets:

```
def f[T](a: T) -> T: ...
```
It's been a long and circuitous road!

I am not quoting the entire PEP here, please follow the link: 
https://peps.python.org/pep-0695/ 




A beautifully written PEP, thank you!
An extra thank you for clearly specifying compile-/run-time vs. type 
checker behavior!



In “Type Parameter Declarations” it would be nice to better specify why 
this example is an error:

```
class ClassA[__T, _ClassA__S]:
__T = 0  # OK
__S = 0  # Syntax Error (because mangled name is _ClassA__S)
```
It's specified later in the Compiler changes section (“An active type 
variable symbol cannot be used for other purposes”), but it would be 
nice to mention it up here too – perhaps replace the specific “Type 
parameters for a generic function cannot overlap the name of a function 
parameter.”



I'm not a fan of a third overload of `type`, after the “get type of” 
function and “default metatype” class.

Would `typevar` not work?
(The addition of a soft keyword itself is a heavy change, though I'll 
let grammar experts weigh in on that.)


I wonder if we should give some thought to other cases where a name is 
repeated – for example, a hypothetical:

namedtuple Point = ("x", "y")
replacing:
Point = namedtuple("Point", ("x", "y"))
Is the proposed `type` potentially setting a precedent? A good one?


`TypeVar` taking `covariant`, `contravariant` and `autovariance` looks 
inconsistent to an outsider. Why is it not `autovariant`?



The Rejected ideas mention “various syntactic options for specifying 
type parameters that preceded def and class statements” rejected because 
scoping is less clear and doesn't work well with decorators. I wonder if 
decorator-like syntax itself was considered, e.g. something like:

```
@with type S
@with type T
@dec(Foo[S])
class ClassA: ...
```


And finally, I need to ask...
The reference implementation doesn't include documentation. Is there any 
plan to document this feature outside this enhancement proposal?


If not, what needs to happen to get this documented?
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/U3TBVMXBXDCLTW7AAF5RAYKUMHKOYPBW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

2022-07-12 Thread Jelle Zijlstra 
El mar, 12 jul 2022 a las 6:15, Petr Viktorin ()
escribió:

> On 12. 07. 22 6:30, Guido van Rossum wrote:
> > After several rounds of debate on typing-sig, I'd like to request
> > feedback on PEP 695: https://peps.python.org/pep-0695/
> > 
> >
> > I am sponsoring this PEP, which was written by Eric Traut. The PEP
> > attempts to solve the problem that defining generic classes, functions
> > and type aliases currently is lacking dedicated syntax, instead using
> > the cumbersome `T = TypeVar("T", ...)` notation to create global
> > variables that serve as type variables.
> >
> > As a personal historical note, I should mention that over 22 years ago I
> > already pondered type parameters. In an old document that I saved I
> > found the following code snippet:
> > ```
> > def f (a: T) -> T: ...
> > ```
> > which is eerily close to the proposal in this PEP, except that the PEP
> > uses square brackets:
> > ```
> > def f[T](a: T) -> T: ...
> > ```
> > It's been a long and circuitous road!
> >
> > I am not quoting the entire PEP here, please follow the link:
> > https://peps.python.org/pep-0695/ 
> >
>
> A beautifully written PEP, thank you!
> An extra thank you for clearly specifying compile-/run-time vs. type
> checker behavior!
>
>
> In “Type Parameter Declarations” it would be nice to better specify why
> this example is an error:
> ```
> class ClassA[__T, _ClassA__S]:
>  __T = 0  # OK
>  __S = 0  # Syntax Error (because mangled name is _ClassA__S)
> ```
> It's specified later in the Compiler changes section (“An active type
> variable symbol cannot be used for other purposes”), but it would be
> nice to mention it up here too – perhaps replace the specific “Type
> parameters for a generic function cannot overlap the name of a function
> parameter.”
>
>
> I'm not a fan of a third overload of `type`, after the “get type of”
> function and “default metatype” class.
> Would `typevar` not work?
>

That piece of syntax is for type *aliases*, not type *variables*, which are
a different concept. Using "typevar" here would be quite confusing. We
could use something like "alias" or "typealias", but I think "type" is the
most intuitive term, and it matches other languages like TypeScript.


> (The addition of a soft keyword itself is a heavy change, though I'll
> let grammar experts weigh in on that.)
>
> I wonder if we should give some thought to other cases where a name is
> repeated – for example, a hypothetical:
>  namedtuple Point = ("x", "y")
> replacing:
>  Point = namedtuple("Point", ("x", "y"))
> Is the proposed `type` potentially setting a precedent? A good one?
>
>
> `TypeVar` taking `covariant`, `contravariant` and `autovariance` looks
> inconsistent to an outsider. Why is it not `autovariant`?
>
>
> The Rejected ideas mention “various syntactic options for specifying
> type parameters that preceded def and class statements” rejected because
> scoping is less clear and doesn't work well with decorators. I wonder if
> decorator-like syntax itself was considered, e.g. something like:
> ```
> @with type S
> @with type T
> @dec(Foo[S])
> class ClassA: ...
> ```
>
We did consider variations of that. Pure decorator syntax (like your "@dec"
line) wouldn't allow us to get the scoping right, since decorators can't
define new names. (Unless you use a walrus operator, but that wouldn't meet
the goal of providing cleaner syntax.)

We also considered some ideas similar to your "@with type". It can work,
but it feels more verbose than the current proposal, and it's not in line
with what most other languages do.


>
>
> And finally, I need to ask...
> The reference implementation doesn't include documentation. Is there any
> plan to document this feature outside this enhancement proposal?
>
> If not, what needs to happen to get this documented?
>

I'm sure we'll provide detailed documentation if and when the PEP is
accepted; full documentation seems a bit much to ask for in an early
prototype.


> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/U3TBVMXBXDCLTW7AAF5RAYKUMHKOYPBW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GOFZMCRZHSE7Y4FXAU27XS53TGGPDEXN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Structural pattern matching and mangling private names

2022-07-12 Thread Guido van Rossum 
Having thought about it some more, I agree with Daniel Moisset that the
current behavior is correct -- in D(__foo=bar), __foo is a keyword arg
position and those don't get mangled. Anyway, anything mangled would get
mangled according to the containing class (in your example, C), not
according to the class appearing in the call. Using the called class for
mangling would set a dangerous precedent.

So there's your answer -- the current behavior is as it should be. I'll
look into the patch with that in mind.

On Fri, Jul 1, 2022 at 10:54 AM  wrote:

> Guido van Rossum wrote:
> > If you want any kind of traction on this I recommend filing an
> opinionated
> > issue on this (explaining why the current behavior is wrong).
>
> Thanks - I'm asking from the point of view of trying to reimplement it. I
> don't actually have a strong opinion on whether the current behaviour is
> wrong - I'd just like to know if I should match it.
>
> From that point of view I've deviated from your advice slightly and
> created a PR instead to add a test for the current behaviour (
> https://github.com/python/cpython/pull/94500). Hopefully that'll either
> fix it is "intended" or stir up a different decision. I'm happy with either
> outcome.
>
> David
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/DBAJEVHAR6QD7HHECUESU6ZMPQKLBSC5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/4MTUBIKIFZ5GZ7MHPM7CDWTIQPRAYWWM/
Code of Conduct: http://python.org/psf/codeofconduct/