I guess you could work around this by exploiting the slicing operator:
GenericClass[:(A, B)]
It makes sense to use the : in the context of typing, but I can see how this
syntax can be confusing. The least confusing implementation I could think of is
to limit the use of GenericClass[:_] to tuple
El vie, 15 oct 2021 a las 14:42, Abdulla Al Kathiri (<
alkathiri.abdu...@gmail.com>) escribió:
> I don’t understand why tuple structure is not supported already. It makes
> reading the function signature a breeze and very natural. You can also do
> it without parentheses which mimics the return of
I don’t understand why tuple structure is not supported already. It makes
reading the function signature a breeze and very natural. You can also do it
without parentheses which mimics the return of multiple objects often seen in
functions(def func(*args: int) -> str, [int])
> On 14 Oct 2021, at
> On 14 Oct 2021, at 12:21 PM, Steven D'Aprano wrote:
>
>
> Why abbreviate list and tuple but not string?
>
Empty strings would be confusing as a type unless you mean a Literal empty
string. We just limit the picture of the type to lists, tuples, dicts, and
sets. Builtin most often use
On Fri, Oct 15, 2021 at 1:06 PM Finn Mason wrote:
> I love the proposal for dicts, but I agree that this discourages duck
> typing. Could the curly braces notation represent Mapping, not dict
> specifically?
>
> +1 to shortening tuples but not other sequences.
>
>
> --
> Finn Mason
>
That might
I love the proposal for dicts, but I agree that this discourages duck
typing. Could the curly braces notation represent Mapping, not dict
specifically?
+1 to shortening tuples but not other sequences.
--
Finn Mason
On Thu, Oct 14, 2021, 6:46 AM Paul Moore wrote:
> On Thu, 14 Oct 2021 at 13:04
On Thu, Oct 14, 2021 at 8:46 AM Paul Moore wrote:
>
> ...maybe the energy focused on "making basic types easier to write"
> should be focused on making protocols easier to write, instead.
>
> Paul
>
+ a billion
Rick.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about g
On Thu, 14 Oct 2021 at 13:04, Ricky Teachey wrote:
>
> I think all of this additional syntax is just a mistake.
>
> The reason is it will encourage people to not properly annotate their input
> types for duck typing. Some of these shortcuts might be nice for output
> types. But the more general
I think all of this additional syntax is just a mistake.
The reason is it will encourage people to not properly annotate their input
types for duck typing. Some of these shortcuts might be nice for output
types. But the more general trying.Mapping, typing.Sequence and friends
should be preferred f
I agree with Steven. I very much like Abdulla's proposed syntax for dicts,
TypedDicts and sets. But I'm not sure that the idea for `Annotated` is
workable, and the proposal for lists seems too prone to ambiguity, given how
extensively square brackets are already used in typing syntax.
One ques
On Thu, Oct 14, 2021 at 12:32:57AM +0400, Abdulla Al Kathiri wrote:
> Today I found myself write a function that returns a tuple of list of
> list of strings (tuple[list[list[str]], list[list[str]]]). Wouldn’t it
> easier to read to write it like the following:
> ([[str]], [[str]])?
Not really
I find myself using exactly that "picture of the data" approach informally
for code I don't plan on formally type checking (but want to show intent).
E.g.
def myfun(data: {str: [CustomType]}) -> [(int, OtherType)]: ...
Maybe it's a bad habit, but it feels easier to parse visually than the real
`
12 matches
Mail list logo
