Hey all, Our next tensor typing meeting will be next week. WHEN? Monday 12th October, 9:30am San Francisco Time, 5:30pm London time. WHERE? http://meet.google.com/fft-dzjq-ksu WHAT? We have a relatively sparse agenda this time. I'll lead a discussion, but if anyone else would like to present/discuss something, let me know! 1. Status updates 2. Discussion: Use of ... (Ellipsis) for unspecified parts of shapes Cheers! Matthew
Reminder that this is tonight/tomorrow depending on your timezone :) See you all soon! On Mon, 5 Oct 2020 at 18:51, Matthew Rahtz <mrahtz@google.com> wrote:
Hey all,
Our next tensor typing meeting will be next week.
WHEN? Monday 12th October, 9:30am San Francisco Time, 5:30pm London time.
WHERE? http://meet.google.com/fft-dzjq-ksu
WHAT? We have a relatively sparse agenda this time. I'll lead a discussion, but if anyone else would like to present/discuss something, let me know! 1. Status updates 2. Discussion: Use of ... (Ellipsis) for unspecified parts of shapes
Cheers! Matthew
Thanks for coming yesterday, everyone! It was great to see you all again and we had some great discussion. As always, we've updated the open meeting doc <https://docs.google.com/document/d/1oaG0V2ZE5BRDjd9N-Tr1N0IKGwZQcraIlZ0N8ayq...> with outputs from our session: - Recording <https://drive.google.com/file/d/1SPOF7ws8jQHJXsMNeslEd78pVl6I7Gzk/view> (and chat log <https://drive.google.com/file/d/1dn4bCCfFMWgBJD6N4_rdDLo31SFElKVI/view>, since we ended up using it quite a bit for clarifications) - Slides <https://docs.google.com/presentation/d/17thiWYhjMh5gZyF6ZSm4I_FouAAU9jrAwvpR...> - Notes <https://docs.google.com/document/d/16r14MCVtd46whXwS4SdeiycIgIs0Dxvj8ePqH-Sp...> on discussion on how the shape version of Any should work Our next meeting will tentatively be on Monday the 9th of November at the same time (9:30am San Francisco time, 5:30pm London time), but as discussed it's possible we might skip the next one given that the main work at the moment is to finish the PEPs. We'll send out an email confirming closer to the day. Until then, take care, everyone, and enjoy Hallowe'en! Cheers, Matthew On Mon, 12 Oct 2020 at 10:57, Matthew Rahtz <mrahtz@google.com> wrote:
Reminder that this is tonight/tomorrow depending on your timezone :) See you all soon!
On Mon, 5 Oct 2020 at 18:51, Matthew Rahtz <mrahtz@google.com> wrote:
Hey all,
Our next tensor typing meeting will be next week.
WHEN? Monday 12th October, 9:30am San Francisco Time, 5:30pm London time.
WHERE? http://meet.google.com/fft-dzjq-ksu
WHAT? We have a relatively sparse agenda this time. I'll lead a discussion, but if anyone else would like to present/discuss something, let me know! 1. Status updates 2. Discussion: Use of ... (Ellipsis) for unspecified parts of shapes
Cheers! Matthew
hi Matthew, As promised, I ran an experiment on using the splat operator aka * notation on the variadic type. The results are pretty nice and pythonic-looking. Here you can see the PEP examples re-written with that notation https://docs.google.com/document/d/1aU5gXlfIZI13raXoHe534qsJMuDiEwfq2e6U1sQw... I think the readability is improved because it's more consistent with other python idioms. Also, it removes the need for Map and Concatenate, if we accept the rule that Tuple[*Ts] means Tuple[T1, T2,...] while *Tuple[Ts] means Tuple[T1], Tuple[T2],..... This approach was suggested here https://github.com/python/typing/issues/193#issuecomment-236090279 and it was described as "Variadic type variables are contagious; when you use one as a type argument to some other type, it too becomes variadic" I think my favourite part is how zip would be typed: `zip(*iterables:*Iterable[ArgTs]) -> Iterable[*ArgTs])`. There's a great symmetry to it, especially since *zip is kind of the opposite operation of zip, ie tuple(zip(*zip(Iter1, Iter2))) == (tuple(Iter1), tuple(Iter2)) It's all great BUT .... big one coming.... using * inside square brackets is not valid syntax :-( So that would require an expanded PEP (or separate one) to make it valid. Back when the original conversation took place in 2016 it seems that this option was not considered practical or desirable, I wonder if the new PEG parser changes things in any way. In summary, some strong pros, but some strong cons too. Cheers, Luk ps: in case the shared version does not work, here's the published version https://docs.google.com/document/u/2/d/e/2PACX-1vRf3m9pMJi13Z6lL7kJR3E2fOAsX...
On Tue, Oct 13, 2020 at 2:57 PM <luk-f-a@outlook.com> wrote:
It's all great BUT .... big one coming.... using * inside square brackets is not valid syntax :-( So that would require an expanded PEP (or separate one) to make it valid. Back when the original conversation took place in 2016 it seems that this option was not considered practical or desirable, I wonder if the new PEG parser changes things in any way.
No, the old parser would have been able to support this too. We were reluctant to require *any* new syntax because we wanted to be able to type-check versions of Python that had already been released (by simply making the typing module available from PyPI). A relevant development: PEP 637 ("Support for indexing with keyword arguments", currently in draft) is proposing to add keywords to index, e.g. a[k=1], and also proposes *args and **kwargs. Depending on how you want this to look at runtime that could either make it easier or harder to support C[*Ts] -- easier, because the syntax will be supported, or harder, because at runtime this requires Ts to be iterable and is indistinguishable from C[T1, ..., Tn] where [T1, ..., Tn] is whatever list(Ts) (i.e., list(iter(Ts)) returns. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
thanks Guido! I knew about PEP 637 but had not realized that it would make `*args` available in indexing. @all: So PEP 637 might make this available, but the point about syntax changes making tensor typing unavailable to existing Python versions still remains. Which means that even if we agreed `Tuple[*Ts]` is better (and not everyone might agree), we face the choice of nicer syntax vs something immediately available. I wonder what folks think about a hybrid approach with a `Expand` or `Map`/`Concatenate` operator-based solution for Python <= 3.9, plus unpack/splat approach for >= 3.10. Cheers, Luk
On Wed, Oct 14, 2020 at 12:52 PM <luk-f-a@outlook.com> wrote:
thanks Guido! I knew about PEP 637 but had not realized that it would make `*args` available in indexing.
@all: So PEP 637 might make this available, but the point about syntax changes making tensor typing unavailable to existing Python versions still remains. Which means that even if we agreed `Tuple[*Ts]` is better (and not everyone might agree), we face the choice of nicer syntax vs something immediately available.
I wonder what folks think about a hybrid approach with a `Expand` or `Map`/`Concatenate` operator-based solution for Python <= 3.9, plus unpack/splat approach for >= 3.10.
That sounds like a decent approach. Just like we're using typing.Union[X, Y] but in Python 3.10 you can also use X|Y, due to PEP 604. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
Thanks for looking into this, Luk! I also think the hybrid sounds like a great approach. Guido, would the right thing to do here be to mostly omit talk of Tuple[*Ts] from this PEP, only noting that it was considered, and draft a second PEP for the new syntax? Or should we roll it all into this PEP and say that the new syntax will only be available for future Python? I'll also take a look at the draft for PEP 637 in the next couple of days to think more about how this would interact. On Thu, 15 Oct 2020 at 05:58, Guido van Rossum <guido@python.org> wrote:
On Wed, Oct 14, 2020 at 12:52 PM <luk-f-a@outlook.com> wrote:
thanks Guido! I knew about PEP 637 but had not realized that it would make `*args` available in indexing.
@all: So PEP 637 might make this available, but the point about syntax changes making tensor typing unavailable to existing Python versions still remains. Which means that even if we agreed `Tuple[*Ts]` is better (and not everyone might agree), we face the choice of nicer syntax vs something immediately available.
I wonder what folks think about a hybrid approach with a `Expand` or `Map`/`Concatenate` operator-based solution for Python <= 3.9, plus unpack/splat approach for >= 3.10.
That sounds like a decent approach. Just like we're using typing.Union[X, Y] but in Python 3.10 you can also use X|Y, due to PEP 604.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...> _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mrahtz@google.com
I would suggest defining the primary syntax without using *Ts, but adding in the same PEP that *Ts should be allowed as syntactic sugar assuming PEP 637 is accepted (noting that this will only work in Python 3.10 and later). On Thu, Oct 15, 2020 at 3:00 AM Matthew Rahtz <mrahtz@google.com> wrote:
Thanks for looking into this, Luk! I also think the hybrid sounds like a great approach.
Guido, would the right thing to do here be to mostly omit talk of Tuple[*Ts] from this PEP, only noting that it was considered, and draft a second PEP for the new syntax? Or should we roll it all into this PEP and say that the new syntax will only be available for future Python?
I'll also take a look at the draft for PEP 637 in the next couple of days to think more about how this would interact.
On Thu, 15 Oct 2020 at 05:58, Guido van Rossum <guido@python.org> wrote:
On Wed, Oct 14, 2020 at 12:52 PM <luk-f-a@outlook.com> wrote:
thanks Guido! I knew about PEP 637 but had not realized that it would make `*args` available in indexing.
@all: So PEP 637 might make this available, but the point about syntax changes making tensor typing unavailable to existing Python versions still remains. Which means that even if we agreed `Tuple[*Ts]` is better (and not everyone might agree), we face the choice of nicer syntax vs something immediately available.
I wonder what folks think about a hybrid approach with a `Expand` or `Map`/`Concatenate` operator-based solution for Python <= 3.9, plus unpack/splat approach for >= 3.10.
That sounds like a decent approach. Just like we're using typing.Union[X, Y] but in Python 3.10 you can also use X|Y, due to PEP 604.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...> _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mrahtz@google.com
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
I'm wondering about whether those two versions of the syntax might be incompatible, therefore making it impossible in the future to switch to `Tuple[*Ts]`. I hope we can find a way to make the current draft PEP work without blocking the possibility of having the other PEP in the future. I have used the examples in the draft PEP for a syntax comparison: https://docs.google.com/document/d/1u5N8_x5v5CzsXf8XffR-uuM5uuYW2bZVoEZzmcAm... Looking at that I was wondering about the fact that `Tuple[Ts] == Tuple[T1, T2,...]`, and whether setting this equivalence now would prevent switching to `Tuple[*Ts] == Tuple[T1, T2,...]` without making a backwards incompatible change. What do you think?
Sorry for the slow reply on this - I've been trying to understand how variadics work in Typed Scheme - and actually, I realised it probably relates to the star syntax too! Here's a solution inspired by Typed Scheme (well, more like reading enough Typed Scheme that I gained a bunch of intuition about it's Apply operator), here's a solution I think should work: 1. In general, a variadic type variable behaves similarly to a parameterized Tuple. That is, if we have a variadic type variable Ts, and it's instantiated with types int and str, then Ts behaves similar to Tuple[int, str]. 2. For future versions of Python, we use the star syntax both for 'expanding' variadic type variables *and* concatenation: def foo(x: Tuple[*Ts]): ... class Foo(Generic[*Ts]): ... Tuple[int, *Ts] 3. We go back to calling the map()-like operator Map, and use Apply to refer to a new operator which serves a similar purpose to the star syntax in a backward-compatible way. (This is consistent with how Python used to use apply() before we could do foo(*args).) def foo(x: Apply[Tuple, Ts]): ... class Foo(Apply[Generic, Ts]): ... 4. The Concatenate operator is similarly used to enable concatenation in a backwards-compatible way: Tuple[Concatenate[int, Ts]] # Same as Tuple[int, *Ts] I've mostly updated the current draft with this strategy and it seems to be consistent. (Luk, I confess that because of getting wrapped up in Typed Scheme I haven't read yours yet - sorry if some of this was already in yours. I tried to take a look just now but it seems I'm missing access - could you fiddle with the sharing settings?) On Wed, 21 Oct 2020 at 07:52, <luk-f-a@outlook.com> wrote:
I'm wondering about whether those two versions of the syntax might be incompatible, therefore making it impossible in the future to switch to `Tuple[*Ts]`. I hope we can find a way to make the current draft PEP work without blocking the possibility of having the other PEP in the future.
I have used the examples in the draft PEP for a syntax comparison: https://docs.google.com/document/d/1u5N8_x5v5CzsXf8XffR-uuM5uuYW2bZVoEZzmcAm...
Looking at that I was wondering about the fact that `Tuple[Ts] == Tuple[T1, T2,...]`, and whether setting this equivalence now would prevent switching to `Tuple[*Ts] == Tuple[T1, T2,...]` without making a backwards incompatible change.
What do you think? _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mrahtz@google.com
hi Matthew, sorry about the access problem. it should be fixed now, please let me know if it's not: https://docs.google.com/document/d/1oXWyAtnv0-pbyJud8H5wkpIk8aajbkX-leJ8JXsE... I created a cheatsheet with a comparison of the star syntax and the previous version of your draft PEP: https://docs.google.com/document/d/1u5N8_x5v5CzsXf8XffR-uuM5uuYW2bZVoEZzmcAm.... I will update it with the new Apply/Map version of the draft PEP. That Typed Scheme paper was an interesting one, thanks for sharing. It's good to learn from what other languages are doing. This week I looked at the tensor typing extension for Kotlin from Facebook, but unfortunately it didn't seem to contain variadics. About the new Apply function, do you think that `Apply[Tuple, Ts]` works better than `Tuple[Expand[Ts]]`? I find the latter more intuitive. Almost as having the word "expand" where the star would be. Maybe it's because I never used the old python `apply`, and I associate "apply" more with `pandas.apply` which is (without axis parameters) an element-wise application. This element-wise application I would tend to associate with `Apply[Tuple, Ts] = Tuple[T1], Tuple[T2],...`. A potential advantage of `Expand` is to allow `Tuple[int, Expand[Ts]]` which `Apply` does not allow. Cheers, Luk ps: sorry if this message is duplicated, I replied without being logged in and now I got a message saying the message was blocked and will be reviewed by an administrator. If an admin is reading this, please just delete the other one.
Hi Luk, Ooh, those are great points about Expand. OK, I'll try revising the draft to work with Expand instead and whether things can still be made consistent. That's fixed the access problem to the cheat sheet, thanks! A few questions/thoughts: - Tuple[Ts] == ListVariadic(Tuple[T1], Tuple[T2],...) - I think this should be Tuple[Ts] == Tuple[Tuple[T1], Tuple[T2]]? - But also, even using the star syntax, having Tuple[Ts] == Tuple[Tuple[T1], Tuple[T2]] feels a bit unintuitive to me. I think Tuple[*Ts] (or Tuple[Expand[Ts]]) should mean Tuple[T1, T2, ...], but I think Tuple[Ts] should be a runtime error. If we want Tuple[Tuple[T1], Tuple[T2]], I think we should use Map[Tuple, Ts], to be explicit. - *args: *Ts - Ah, I hadn't thought about whether Ts should also have a star here; but yes, I think you're right, it should. That would also help to differentiate this new way of specifying the type of *args from the old way where the annotation specifies the type of *all* of the variadic arguments. I'll also try updating the draft to include this. - map(..., *iterables: *Iterable[ArgTs]) - This is probably related to the question above of what Tuple[Ts] should mean. In this case also I think we should still use Map - so it would be *iterables: *Map[Iterable, ArgTs]. Could you enable comment permissions on the cheat sheet too and I'll add some more comments there once I've done the next round of edits to the draft? Cheers, Matthew On Thu, 19 Nov 2020 at 21:47, <luk-f-a@outlook.com> wrote:
hi Matthew,
sorry about the access problem. it should be fixed now, please let me know if it's not: https://docs.google.com/document/d/1oXWyAtnv0-pbyJud8H5wkpIk8aajbkX-leJ8JXsE...
I created a cheatsheet with a comparison of the star syntax and the previous version of your draft PEP: https://docs.google.com/document/d/1u5N8_x5v5CzsXf8XffR-uuM5uuYW2bZVoEZzmcAm.... I will update it with the new Apply/Map version of the draft PEP.
That Typed Scheme paper was an interesting one, thanks for sharing. It's good to learn from what other languages are doing. This week I looked at the tensor typing extension for Kotlin from Facebook, but unfortunately it didn't seem to contain variadics.
About the new Apply function, do you think that `Apply[Tuple, Ts]` works better than `Tuple[Expand[Ts]]`? I find the latter more intuitive. Almost as having the word "expand" where the star would be. Maybe it's because I never used the old python `apply`, and I associate "apply" more with `pandas.apply` which is (without axis parameters) an element-wise application. This element-wise application I would tend to associate with `Apply[Tuple, Ts] = Tuple[T1], Tuple[T2],...`. A potential advantage of `Expand` is to allow `Tuple[int, Expand[Ts]]` which `Apply` does not allow.
Cheers, Luk
ps: sorry if this message is duplicated, I replied without being logged in and now I got a message saying the message was blocked and will be reviewed by an administrator. If an admin is reading this, please just delete the other one. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mrahtz@google.com
hi Matthew, I enabled the permissions for editing the cheat sheet. Also, I added two new sheets to make room for comparing your updated draft in both forms: "Unpack*/Map" and "Expand / Map". I populated the comparison with the examples I found in the latest version of the draft. I agree that `Tuple[Ts]` should not be allowed, but I was considering using `*Tuple[Ts]` as a shorter version of `Map[Tuple, Ts]`. However, after looking at the comparisons in the cheatsheet, I'm less sure about it than I was last week. It does feel that `*Tuple[Ts]==Tuple[T1], Tuple[T2], ...` does not behave like other python syntax, and `Map[Tuple, Ts]` is closer to what python currently does in other places. Cheers, Luk
participants (3)
-
Guido van Rossum -
luk-f-a＠outlook.com -
Matthew Rahtz