Yeah I like <> because def f(…) is easier to the eyes to parse than def
f[T](…) but in python we use [] for the types so it might not be consistent.
Why can’t we attach the TypeVar as a class and function attributes?
Abdulla
Sent from my iPhone
> On 8 Feb 2022, at 1:02 PM, Jonathan
Very nice ideas. The plus and minus signs are much better than :: and :::. I am
glad people are working on that. [+T: (str, int)] would be similar to
TypeVar(“T”, str, int, covariant=True).
Abdulla
Sent from my iPhone
> On 8 Feb 2022, at 6:49 PM, Abdulla Al Kathiri
> wrote:
>
> Thank you
Thank you Stephan. Very fair points you brought. I will make sure to check the
typing-sig.
Sent from my iPhone
> On 8 Feb 2022, at 6:00 PM, James H-B wrote:
>
> I really like the idea as a whole presented here. I have a few concerns here
> though:
> 1. The support for constraints overlaps
I really like the idea as a whole presented here. I have a few concerns here
though:
1. The support for constraints overlaps with union which is undesireable, Jelle
has previously suggested using TypeVar in (constraint1, constraint2, ...) which
I think is much nicer.
2. The syntax for defining
Abdulla Al Kathiri writes:
> I thought this is called python-ideas,
It is, and if that's all you know, this is the *right* place to bring
this kind of idea. I'm sorry, I should have been more clear about
this.
> meaning it’s ok to bring ideas even if they are ugly or stupid.
What I was
*Your audience is really in the Typing SIG. Happy hunting!Steve*
Until I read that line I thought I was reading Typing-SIG
I was saying cool for once I found a discussion I completely follow,
but dear me, it turned out to be -ideas. Btw every time I read discussions
on Typing-SIG I'm like:
>
>> class Indexable[T_co::](Protocol[T_co]):
>>def __getitem__(self, n: int) -> T_co: …
>
> This is completely new syntax: between the class name and what it
> subclasses, you have a subscript-like syntax.
>
> This is new semantics for subclassing, I think, unless you want
> Indexable to
Personally, I very much like this approach, although I'd definitely prefer
<> brackets instead, like in other languages.
We could possibly think of it as being syntactic sugar for the current
TypeVar approach, and have it translated into TypeVars at runtime.
However, if we'd define it that way,
On Tue, 8 Feb 2022 at 18:59, Abdulla Al Kathiri
wrote:
>
> I thought this is called python-ideas, meaning it’s ok to bring ideas even if
> they are ugly or stupid. No need to introduce it in Python if it’s too much
> but it might induce discussions.
>
Yes, it's absolutely okay to bring ideas
I thought this is called python-ideas, meaning it’s ok to bring ideas even if
they are ugly or stupid. No need to introduce it in Python if it’s too much but
it might induce discussions. I am not per se convinced of the syntax I wrote.
Any suggestion to make it better is more than welcomed,
10 matches
Mail list logo
