Typing Meetup for July?

Hi typing folks!

At this year’s Typing Summit, I asked about resuming the Zoom meetups we used to hold every month or two to allow a real-time discussion of typing issues, PEPs, and other topics of interest to the typing community.

I’d be interested in planning a meetup for July; to do this we need to decide on a time and one or more topics with speakers :slight_smile:


Time: in the past we typically held these meetings at 9 or 10 am Pacific, usually on Wednesdays, so that it would be possible for most folks in Europe or the US to join.

I’m happy to move the time as needed for speakers or if there’s a conflict for someone who wants to attend regularly but that seems like a good default.


Topics: I’m open to anything, but a couple of topics I can think of straightaway:

  • @adriangb’s work on PEP 746, typed metadata. I haven’t followed the discussion well but there’s been quite a bit.

  • The group that’s been doing intersection type explorations; it’s possible they may need more time to think about the impact of @carljm’s proposed semantic typing rules for Any.

  • Numeric types and the special case rules (like int <: float) we allow. I think there have been two related but separate discussions, @Jelle’s about proposed spec changes to clarify the special case and @mikeshardmind’s one about whether it would be possible to actually clean up the special case.


My preference is to have 1-2 topics per meetup so there’s time for discussion.

10 Likes

I’d be happy to present on PEP 746 :smiley:

6 Likes

If it helps figure out topics, here are my thoughts on the two of those possible topics I have an unresolved interest in.

I think the proposed semantic changes to Any make the intersection work easier, but I’m refraining from redrafting my thoughts into a full proposal while more things are cleared up than just that at this point. The current less clear roadblock comes in with negated types, currently possible but not denotable via the negative branch of a conditional using TypeIs. This has some relatively difficult things to reconcile, especially when concerning cases involving partial information loss when assigned to less specific types.[1]

I don’t think this one’s likely to be unblocked or cleared up by a discussion on the current state without more exploration into the consequences of type negation. Still, I will try to make time to discuss it if other people are interested.

With the numeric special cases, I don’t think there’s likely going to be room for agreement there[2] (will discuss if others want to), but as long as the actual runtime type rather than only the wider special case is denotable, I have little to add that hasn’t been said already.


  1. While there’s a direct and succinct example here, the problems with negation probably need to be cleaned up before intersections as a prerequisite and not as part of it as this also has an impact on the interpretation of TypeIs. The specification for the negative branch with a TypeIs conditional is specified that it should function like a theoretical negation, but does not include any of the theory explored in either the discussion of intersections, or the issue for adding typing.Not ↩︎

  2. I view pep237 (unifying int and long) to have had a lot of unintended consequences (see int_max_str_digits for one such non-typing consequence), and that the situation with a few operators on ints and floats to be troublesome. I’ve concluded that anyone caring about the distinction shouldn’t use int at all, and should use either fractions.Fraction or a sized type implemented in extension code. (float isn’t arbitrary precision…) There are other problems with the promotion of floats to complex rather than having a domain error and requiring explicit confirmation from a developer that their problem works in that domain. (this also causes issues for typing, see this in the typeshed). I don’t think this is changeable at this point at runtime, so I just want a way to properly denote types that exist at runtime here and for the typeshed to reflect those accurately to runtime. ↩︎

If you think it’s better to wait before presenting on intersection types, that’s no problem at all.

We could potentially make some time for a more narrow and less structured discussion of tricky topics like negation, but I don’t know if it would be helpful and it’s up to you.