00:14 <whitequark[cis]> Wanda: oh, neat: https://docs.python.org/3/library/operator.html#operator.attrgetter

00:26 <RobTaylor[m]> Catherine: this seems to work..... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PBqPHoGgTdhcWpgKAtXwvelw>)

00:27 <RobTaylor[m]> now that itch has gone i can sleep >< =)

00:27 <whitequark[cis]> that's not a valid annotation

00:27 <RobTaylor[m]> It is according to pyright

00:27 <whitequark[cis]> only Unsigned[Literal[1]] is valid

00:29 <whitequark[cis]> hmm

00:30 <whitequark[cis]> it's not valid according to python docs: https://typing.readthedocs.io/en/latest/spec/annotations.html#type-and-annotation-expressions

00:31 <whitequark[cis]> mypy will yell at you for Unsigned[1]

00:32 <whitequark[cis]> now, am I potentially open to adding annotations that exclusively work with pyright? maybe, I'd need to see an RFC proposing it comprehensively

00:32 <whitequark[cis]> is going from "illegal according to Python annotations" to "illegal according to Python annotations but different" an improvement? I don't know

00:35 <RobTaylor[m]> Hmm, If i'm reading the python type spec correctly, generic subscripting just must 'confirm to normal subscripting rules'

00:36 <whitequark[cis]> there's two parts to it: one run-time (where __class_getitem__ gets actually called) and one typechecking-time

00:36 <whitequark[cis]> the latter is matched against the grammar in the docs, with pyright being more lax about it

00:37 <RobTaylor[m]> https://typing.readthedocs.io/en/latest/spec/generics.html#generic-type-aliases

00:40 <RobTaylor[m]> yeah, i'm unsure, nontypes in generics is something useful, and doesnt seem to be explictly banned, and only implicitly supported via Literal. I guess it's a case of asking

00:40 <whitequark[cis]> it's explicitly banned in the link I've given above

00:41 <whitequark[cis]> the grammar is unambiguous in that it doesn't allow nontypes in subscripts

00:51 <RobTaylor[m]> ah, yeah i see, missed that

04:03 <Wanda[cis]> <whitequark[cis]> "the grammar is unambiguous in..." <- <del>I mean, `typenum` already solved that problem</del>

09:35 <Chips4MakersakaS> <whitequark[cis]> "ultimately i feel like python..." <- I am a one man company so I don't consider my dev environment a corporate place :)

09:35 <Chips4MakersakaS> I do like static typing in the IDE. I personally feel this is more productive than the run-time type checking Amaranth provides.

09:36 <whitequark[cis]> the run-time typechecking isn't there to improve productivity in and of itself; it's there to make sure nobody ever ends up in a situation where they're getting some error that's probably caused by types, but they don't understand why because it happens deep in Amaranth guts

09:37 <whitequark[cis]> it's kind of a last resort thing or a backstop that covers everyone using Amaranth in any environment no matter who they are

09:37 <whitequark[cis]> (of course, not chasing type errors in Amaranth guts does improve productivity, but that's a secondary effect to reducing frustration of newcomers)

18:00 <RobTaylor[m]> Catherine: i hacked up a patch last night to allow the use of Annotated[] in data.Flow members, for those users who wish to have full type checking available for their codebase. Would it be of interest if I finish that up properly, and would that require an RFC? Thanks!... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dkaOzlzleEdDJibKuXxajUVW>)

19:49 <RobTaylor[m]> a different option for these users would be a docs addition where to use @no_type_check, but I think that doesn't work with classes in mypy still (works with pyright>1.1.347 though)

20:25 <RobTaylor[m]> <RobTaylor[m]> "a different option for these..." <- oh no. pyright also doesnt honour @no_type_check on classes

22:46 <whitequark[cis]> <RobTaylor[m]> "Catherine: i hacked up a patch..." <- > <@rob_chipflow:matrix.org> Catherine: i hacked up a patch last night to allow the use of Annotated[] in data.Flow members, for those users who wish to have full type checking available for their codebase. Would it be of interest if I finish that up... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/IOxmeLzwhZPDJQxMgAgQALqI>)

22:47 <RobTaylor[m]> whitequark[cis]: hmm, its more about users actually being able to write code with a type checker enabled

22:47 <RobTaylor[m]> rather than typing for amaranth overall

22:48 <RobTaylor[m]> its only view/struct/union that breaks

22:48 <RobTaylor[m]> happy to write that up though

22:48 <RobTaylor[m]> currently even switching to basic doesnt work with pyright :(

22:50 <RobTaylor[m]> (i.e. the only solution i have right now is to # type ignore)

23:06 <whitequark[cis]> Rob Taylor: please read all of https://github.com/amaranth-lang/rfcs/pull/11 first, as the reasons that RFC was closed would have to be addressed first

23:06 <RobTaylor[m]> whitequark[cis]: will do!

23:11 <RobTaylor[m]> Yep, think i can answer all that, went through PEP 649 and PEP 563 a few times yesterday (both accepted now)

23:12 <RobTaylor[m]> I'll see what I can pull together

23:21 <whitequark[cis]> oh, they are accepted? that's actually kind of disappointing

23:21 <whitequark[cis]> wait no 649 is fine

23:25 <whitequark[cis]> okay, I re-read 649, this is in fact a good way to implement them and should not have negative effects on us