Proposal: typing.reveal_locals()
In the previous thread about reveal_type(), several people proposed also adding `typing.reveal_locals()`. In this thread I'd like to iron out any details and make sure we're all in agreement. # Specification We will add a new function `typing.reveal_locals()` with the following signature: def reveal_locals() -> None: ... At runtime, this function will do nothing. When a type checker encounters a call to reveal_locals(), it will emit the types of all variables in the local scope. For example: def f() -> None: a = 1 b = "x" reveal_locals() When typechecked, this may produce: Revealed local types are: a: builtins.int b: builtins.str # Motivation `reveal_locals()` is already implemented in mypy ( https://mypy.readthedocs.io/en/stable/common_issues.html#displaying-the-type...) and pyright (undocumented). It is not as commonly used as reveal_type(), but can be useful for debugging type checker behavior. # Open questions What should the runtime behavior be? We could do something like sys._getframe(1).f_locals to get the calling function's locals and print them, but that isn't code I'd like to write.
FWIW, my objection to adding these to stdlib stands. On Sat, 2022-01-22 at 14:32 -0800, Jelle Zijlstra wrote:
In the previous thread about reveal_type(), several people proposed also adding `typing.reveal_locals()`. In this thread I'd like to iron out any details and make sure we're all in agreement.
# Specification
We will add a new function `typing.reveal_locals()` with the following signature:
def reveal_locals() -> None: ...
At runtime, this function will do nothing.
When a type checker encounters a call to reveal_locals(), it will emit the types of all variables in the local scope. For example:
def f() -> None: a = 1 b = "x" reveal_locals()
When typechecked, this may produce:
Revealed local types are: a: builtins.int b: builtins.str
# Motivation
`reveal_locals()` is already implemented in mypy ( https://mypy.readthedocs.io/en/stable/common_issues.html#displaying-the-type... ) and pyright (undocumented). It is not as commonly used as reveal_type(), but can be useful for debugging type checker behavior.
# Open questions
What should the runtime behavior be? We could do something like sys._getframe(1).f_locals to get the calling function's locals and print them, but that isn't code I'd like to write.
_______________________________________________ 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: pbryan@anode.ca
On Sat, Jan 22, 2022 at 3:39 PM Paul Bryan <pbryan@anode.ca> wrote:
FWIW, my objection to adding these to stdlib stands.
Hi Paul, I reviewed previous threads to try to better understand your objection; I don't want you to feel that it's been ignored. It seems to me that your objection may be based on some misunderstandings of what the proposal is or how it will be implemented. You refer several times to the idea that each type-checker will need to "monkeypatch" the version added to the typing module; this is not the case. Static type checkers don't run the code so they don't need to monkeypatch anything; they will simply provide some static type-checking behavior when they see these functions in analyzing the code (e.g. when they see `reveal_type(x)` during static type-checking they will print the statically-known type of the variable `x`.) In fact they already do this, but the problem is the function doesn't exist anywhere at runtime, so people have to delete the call to `reveal_type()` before they can run the code, and if they want to go back and forth between running the code and static-checking it, but they also want this debug information about the type of `x` in their static check, they are constantly having to add and delete the `reveal_type()` call. This problem can be solved by placing a common implementation of `reveal_type()` (which in fact has a useful standard runtime behavior -- it will print the runtime type of the variable!) into the `typing` module. Now people can import `typing.reveal_type`, call it in their code, and get useful debugging information both from running the code and from type-checking it. This is very much in-line with the existing contents and usage of the `typing` module. E.g. `typing.cast()` does nothing at all at runtime, but static type-checkers give it special meaning to change the static type of some expression. Similarly `typing.NewType()` does nothing at runtime, but it's a standardized interface that is given special meaning by type checkers. If your concern is that the contents of the `typing` module should also be useful at runtime, then you should be more pleased with `typing.reveal_type()` than you are with the existing `typing.cast` and `typing.NewType` -- at least `typing.reveal_type` has a useful and obvious runtime behavior that parallels its static-typing-checking behavior! Please let me know if I've missed something important about your objection. If you still feel there is a problem here, it might help clarify if you can give a specific example of how the addition of e.g. `typing.reveal_type` to the stdlib will harm a use case that you care about. Carl
Thanks, Carl. I appreciate you taking the time to provide such a comprehensive response. Your explantion definitely helps me better understand the nature of this change. I see that more than one static type checker will leverage this, and there is precident (`cast`), so I withdraw my objection. I suspect that `reveal_type` will see very little (if any) use at runtime, and will likely be removed by developers when static type debugging is completed to avoid console noise. If this is not true (if `reveal_type` may be retained in code after debugging) then I think it would actually be better for it to have no runtime behavior (e.g. like `cast`). On Sun, 2022-01-30 at 10:56 -0700, Carl Meyer wrote:
On Sat, Jan 22, 2022 at 3:39 PM Paul Bryan <pbryan@anode.ca> wrote:
FWIW, my objection to adding these to stdlib stands.
Hi Paul,
I reviewed previous threads to try to better understand your objection; I don't want you to feel that it's been ignored. It seems to me that your objection may be based on some misunderstandings of what the proposal is or how it will be implemented. You refer several times to the idea that each type-checker will need to "monkeypatch" the version added to the typing module; this is not the case. Static type checkers don't run the code so they don't need to monkeypatch anything; they will simply provide some static type-checking behavior when they see these functions in analyzing the code (e.g. when they see `reveal_type(x)` during static type-checking they will print the statically-known type of the variable `x`.) In fact they already do this, but the problem is the function doesn't exist anywhere at runtime, so people have to delete the call to `reveal_type()` before they can run the code, and if they want to go back and forth between running the code and static-checking it, but they also want this debug information about the type of `x` in their static check, they are constantly having to add and delete the `reveal_type()` call.
This problem can be solved by placing a common implementation of `reveal_type()` (which in fact has a useful standard runtime behavior -- it will print the runtime type of the variable!) into the `typing` module. Now people can import `typing.reveal_type`, call it in their code, and get useful debugging information both from running the code and from type-checking it.
This is very much in-line with the existing contents and usage of the `typing` module. E.g. `typing.cast()` does nothing at all at runtime, but static type-checkers give it special meaning to change the static type of some expression. Similarly `typing.NewType()` does nothing at runtime, but it's a standardized interface that is given special meaning by type checkers. If your concern is that the contents of the `typing` module should also be useful at runtime, then you should be more pleased with `typing.reveal_type()` than you are with the existing `typing.cast` and `typing.NewType` -- at least `typing.reveal_type` has a useful and obvious runtime behavior that parallels its static-typing-checking behavior!
Please let me know if I've missed something important about your objection. If you still feel there is a problem here, it might help clarify if you can give a specific example of how the addition of e.g. `typing.reveal_type` to the stdlib will harm a use case that you care about.
Carl
Hi Paul, On Sun, Jan 30, 2022 at 11:22 AM Paul Bryan <pbryan@anode.ca> wrote:
I suspect that `reveal_type` will see very little (if any) use at runtime, and will likely be removed by developers when static type debugging is completed to avoid console noise. If this is not true (if `reveal_type` may be retained in code after debugging) then I think it would actually be better for it to have no runtime behavior (e.g. like `cast`).
I see it as a debug tool that should be removed before commit, so for that use case the “print type” behavior is useful for iterating and going between running the code and type checking it, with useful debug type information both ways; it’s especially interesting to know if the runtime type does not match the static type. There’s been some discussion also of it’s possible use in test suites for typed libraries, but I haven’t fully followed the ins and outs of that. Carl
On Sun, Jan 30, 2022 at 10:39 AM Carl Meyer <carl@oddbird.net> wrote:
Hi Paul,
On Sun, Jan 30, 2022 at 11:22 AM Paul Bryan <pbryan@anode.ca> wrote:
I suspect that `reveal_type` will see very little (if any) use at runtime, and will likely be removed by developers when static type debugging is completed to avoid console noise. If this is not true (if `reveal_type` may be retained in code after debugging) then I think it would actually be better for it to have no runtime behavior (e.g. like `cast`).
I see it as a debug tool that should be removed before commit, so for that use case the “print type” behavior is useful for iterating and going between running the code and type checking it, with useful debug type information both ways; it’s especially interesting to know if the runtime type does not match the static type.
There’s been some discussion also of it’s possible use in test suites for typed libraries, but I haven’t fully followed the ins and outs of that.
I was skeptical originally, for a reason similar to Paul's objection (IIUC). But I've come across the use case (flipping back and forth between static type checking and running the code to debug it) that I like the proposed solution. IMO accidentally leaving a reveal_type() call in when committing the code is a minor sin, comparable to leaving in a debug print() call. It happens, someone notices, you fix it. -- --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-change-the-world/>
I do have a follow-up question: If static type checkers are not executing the code in question (`reveal_type`), then wouldn't a well-placed (and formatted) comment do just as well? If so, what's the value of adding this to stdlib? On Sun, 2022-01-30 at 11:38 -0700, Carl Meyer wrote:
Hi Paul,
On Sun, Jan 30, 2022 at 11:22 AM Paul Bryan <pbryan@anode.ca> wrote:
I suspect that `reveal_type` will see very little (if any) use at runtime, and will likely be removed by developers when static type debugging is completed to avoid console noise. If this is not true (if `reveal_type` may be retained in code after debugging) then I think it would actually be better for it to have no runtime behavior (e.g. like `cast`).
I see it as a debug tool that should be removed before commit, so for that use case the “print type” behavior is useful for iterating and going between running the code and type checking it, with useful debug type information both ways; it’s especially interesting to know if the runtime type does not match the static type.
There’s been some discussion also of it’s possible use in test suites for typed libraries, but I haven’t fully followed the ins and outs of that.
Carl
El lun, 31 ene 2022 a las 0:56, Paul Bryan (<pbryan@anode.ca>) escribió:
I do have a follow-up question:
If static type checkers are not executing the code in question (`reveal_type`), then wouldn't a well-placed (and formatted) comment do just as well? If so, what's the value of adding this to stdlib?
There's a few advantages: - reveal_type() is already a well-established convention, all type checkers implement it - A function is more discoverable for users than a magical comment - We can give the function useful runtime behavior - reveal_type() is an expression and can be put anywhere in the line. Consider the usage in https://github.com/microsoft/pyright/issues/2916#issuecomment-1025187284, for example—that would have been difficult to do with a magical comment.
On Sun, 2022-01-30 at 11:38 -0700, Carl Meyer wrote:
Hi Paul,
On Sun, Jan 30, 2022 at 11:22 AM Paul Bryan <pbryan@anode.ca> wrote:
I suspect that `reveal_type` will see very little (if any) use at runtime, and will likely be removed by developers when static type debugging is completed to avoid console noise. If this is not true (if `reveal_type` may be retained in code after debugging) then I think it would actually be better for it to have no runtime behavior (e.g. like `cast`).
I see it as a debug tool that should be removed before commit, so for that use case the “print type” behavior is useful for iterating and going between running the code and type checking it, with useful debug type information both ways; it’s especially interesting to know if the runtime type does not match the static type.
There’s been some discussion also of it’s possible use in test suites for typed libraries, but I haven’t fully followed the ins and outs of that.
Carl
Thanks, Jelle. Out of curiousity, do most type checkers expect `reveal_type()` to be a builtin, or in the typing module? How would they cope with `reveal_type` defined and consumed from another module? On Mon, 2022-01-31 at 07:26 -0800, Jelle Zijlstra wrote:
El lun, 31 ene 2022 a las 0:56, Paul Bryan (<pbryan@anode.ca>) escribió:
I do have a follow-up question:
If static type checkers are not executing the code in question (`reveal_type`), then wouldn't a well-placed (and formatted) comment do just as well? If so, what's the value of adding this to stdlib?
There's a few advantages: - reveal_type() is already a well-established convention, all type checkers implement it - A function is more discoverable for users than a magical comment - We can give the function useful runtime behavior - reveal_type() is an expression and can be put anywhere in the line. Consider the usage in https://github.com/microsoft/pyright/issues/2916#issuecomment-1025187284 , for example—that would have been difficult to do with a magical comment.
On Sun, 2022-01-30 at 11:38 -0700, Carl Meyer wrote:
Hi Paul,
On Sun, Jan 30, 2022 at 11:22 AM Paul Bryan <pbryan@anode.ca> wrote:
I suspect that `reveal_type` will see very little (if any) use at runtime, and will likely be removed by developers when static type debugging is completed to avoid console noise. If this is not true (if `reveal_type` may be retained in code after debugging) then I think it would actually be better for it to have no runtime behavior (e.g. like `cast`).
I see it as a debug tool that should be removed before commit, so for that use case the “print type” behavior is useful for iterating and going between running the code and type checking it, with useful debug type information both ways; it’s especially interesting to know if the runtime type does not match the static type.
There’s been some discussion also of it’s possible use in test suites for typed libraries, but I haven’t fully followed the ins and outs of that.
Carl
El lun, 31 ene 2022 a las 11:06, Paul Bryan (<pbryan@anode.ca>) escribió:
Thanks, Jelle. Out of curiousity, do most type checkers expect `reveal_type()` to be a builtin, or in the typing module? How would they cope with `reveal_type` defined and consumed from another module?
They normally expect it to be a builtin. The expectation is that they'll continue to support that in addition to typing.reveal_type() and typing_extensions.reveal_type(). Pyright and pyanalyze already support the typing form, and it should be easy to do for other type checkers.
On Mon, 2022-01-31 at 07:26 -0800, Jelle Zijlstra wrote:
El lun, 31 ene 2022 a las 0:56, Paul Bryan (<pbryan@anode.ca>) escribió:
I do have a follow-up question:
If static type checkers are not executing the code in question (`reveal_type`), then wouldn't a well-placed (and formatted) comment do just as well? If so, what's the value of adding this to stdlib?
There's a few advantages: - reveal_type() is already a well-established convention, all type checkers implement it - A function is more discoverable for users than a magical comment - We can give the function useful runtime behavior - reveal_type() is an expression and can be put anywhere in the line. Consider the usage in https://github.com/microsoft/pyright/issues/2916#issuecomment-1025187284, for example—that would have been difficult to do with a magical comment.
On Sun, 2022-01-30 at 11:38 -0700, Carl Meyer wrote:
Hi Paul,
On Sun, Jan 30, 2022 at 11:22 AM Paul Bryan <pbryan@anode.ca> wrote:
I suspect that `reveal_type` will see very little (if any) use at runtime, and will likely be removed by developers when static type debugging is completed to avoid console noise. If this is not true (if `reveal_type` may be retained in code after debugging) then I think it would actually be better for it to have no runtime behavior (e.g. like `cast`).
I see it as a debug tool that should be removed before commit, so for that use case the “print type” behavior is useful for iterating and going between running the code and type checking it, with useful debug type information both ways; it’s especially interesting to know if the runtime type does not match the static type.
There’s been some discussion also of it’s possible use in test suites for typed libraries, but I haven’t fully followed the ins and outs of that.
Carl
I'm strongly in favour of runtime behaviour being either "do nothing" or "raise an error", on the theory that these are analogous to debug printfs that you want to insert temporarily while debugging and then remove. martin On Sat, Jan 22, 2022 at 2:32 PM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
In the previous thread about reveal_type(), several people proposed also adding `typing.reveal_locals()`. In this thread I'd like to iron out any details and make sure we're all in agreement.
# Specification
We will add a new function `typing.reveal_locals()` with the following signature:
def reveal_locals() -> None: ...
At runtime, this function will do nothing.
When a type checker encounters a call to reveal_locals(), it will emit the types of all variables in the local scope. For example:
def f() -> None: a = 1 b = "x" reveal_locals()
When typechecked, this may produce:
Revealed local types are: a: builtins.int b: builtins.str
# Motivation
`reveal_locals()` is already implemented in mypy ( https://mypy.readthedocs.io/en/stable/common_issues.html#displaying-the-type...) and pyright (undocumented). It is not as commonly used as reveal_type(), but can be useful for debugging type checker behavior.
# Open questions
What should the runtime behavior be? We could do something like sys._getframe(1).f_locals to get the calling function's locals and print them, but that isn't code I'd like to write.
_______________________________________________ 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: mdemello@google.com
El sáb, 22 ene 2022 a las 14:56, Martin DeMello (<mdemello@google.com>) escribió:
I'm strongly in favour of runtime behaviour being either "do nothing" or "raise an error", on the theory that these are analogous to debug printfs that you want to insert temporarily while debugging and then remove.
Raising an error would be inconvenient, because one of the use cases from the reveal_type() thread is to alternate between running the type checker and your test suite. In my mind the two reasonable options for runtime behavior are: - Do nothing at all (current preference) - Use getframe() hackery to get the locals of the calling frame and print them But if someone has other ideas, I'm happy to adapt the proposal.
martin
On Sat, Jan 22, 2022 at 2:32 PM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
In the previous thread about reveal_type(), several people proposed also adding `typing.reveal_locals()`. In this thread I'd like to iron out any details and make sure we're all in agreement.
# Specification
We will add a new function `typing.reveal_locals()` with the following signature:
def reveal_locals() -> None: ...
At runtime, this function will do nothing.
When a type checker encounters a call to reveal_locals(), it will emit the types of all variables in the local scope. For example:
def f() -> None: a = 1 b = "x" reveal_locals()
When typechecked, this may produce:
Revealed local types are: a: builtins.int b: builtins.str
# Motivation
`reveal_locals()` is already implemented in mypy ( https://mypy.readthedocs.io/en/stable/common_issues.html#displaying-the-type...) and pyright (undocumented). It is not as commonly used as reveal_type(), but can be useful for debugging type checker behavior.
# Open questions
What should the runtime behavior be? We could do something like sys._getframe(1).f_locals to get the calling function's locals and print them, but that isn't code I'd like to write.
_______________________________________________ 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: mdemello@google.com
I just opened https://github.com/python/cpython/pull/30839 with a draft implementation. Feedback (especially on the documentation) is welcome. El sáb, 22 ene 2022 a las 14:32, Jelle Zijlstra (<jelle.zijlstra@gmail.com>) escribió:
In the previous thread about reveal_type(), several people proposed also adding `typing.reveal_locals()`. In this thread I'd like to iron out any details and make sure we're all in agreement.
# Specification
We will add a new function `typing.reveal_locals()` with the following signature:
def reveal_locals() -> None: ...
At runtime, this function will do nothing.
When a type checker encounters a call to reveal_locals(), it will emit the types of all variables in the local scope. For example:
def f() -> None: a = 1 b = "x" reveal_locals()
When typechecked, this may produce:
Revealed local types are: a: builtins.int b: builtins.str
# Motivation
`reveal_locals()` is already implemented in mypy ( https://mypy.readthedocs.io/en/stable/common_issues.html#displaying-the-type...) and pyright (undocumented). It is not as commonly used as reveal_type(), but can be useful for debugging type checker behavior.
# Open questions
What should the runtime behavior be? We could do something like sys._getframe(1).f_locals to get the calling function's locals and print them, but that isn't code I'd like to write.
In the PR (https://github.com/python/cpython/pull/30839/), there was some concern that this function isn't broadly useful enough to add it. It's not as widely implemented as reveal_type() and doesn't get used as often with the type checkers that do implement it. In this thread there hasn't been much discussion so far about whether we should add reveal_locals() specifically. So I'd like to ask anyone with an opinion to speak up: Is reveal_locals() sufficiently useful that we should add it to the standard library? El sáb, 22 ene 2022 a las 14:32, Jelle Zijlstra (<jelle.zijlstra@gmail.com>) escribió:
In the previous thread about reveal_type(), several people proposed also adding `typing.reveal_locals()`. In this thread I'd like to iron out any details and make sure we're all in agreement.
# Specification
We will add a new function `typing.reveal_locals()` with the following signature:
def reveal_locals() -> None: ...
At runtime, this function will do nothing.
When a type checker encounters a call to reveal_locals(), it will emit the types of all variables in the local scope. For example:
def f() -> None: a = 1 b = "x" reveal_locals()
When typechecked, this may produce:
Revealed local types are: a: builtins.int b: builtins.str
# Motivation
`reveal_locals()` is already implemented in mypy ( https://mypy.readthedocs.io/en/stable/common_issues.html#displaying-the-type...) and pyright (undocumented). It is not as commonly used as reveal_type(), but can be useful for debugging type checker behavior.
# Open questions
What should the runtime behavior be? We could do something like sys._getframe(1).f_locals to get the calling function's locals and print them, but that isn't code I'd like to write.
On 2/1/22 8:41 PM, Jelle Zijlstra wrote:
So I'd like to ask anyone with an opinion to speak up: Is reveal_locals() sufficiently useful that we should add it to the standard library?
Conservatively, I'm leaning away from adding it. For now I'd just suggest adding it officially to the pyright documentation (where it is already implemented but not documented). -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy
I'm unsure where it's documented currently. I only learned about reveal_locals from this thread. So I think primary value of adding it would be documentation. I think it's doomed to rare usage if it's documented no where. It would be nice if typing page mades references to other docs/included advice for useful typing features even if they may not be defined within typing.py. The mypy docs are main docs I learned basic type usage and I think it's very buried in them/unsure what page it lives in. I think given rare usage, adding documentation and skipping runtime equivalent would be my vote. If years from now it becomes more commonly used, it can be reconsidered for runtime inclusion.
Honestly I think it was added to mypy by an eager contributor who had a spike use case. It sounds like nobody really cares, so let's drop it. On Wed, Feb 2, 2022 at 12:33 AM Mehdi2277 <med2277@gmail.com> wrote:
I'm unsure where it's documented currently. I only learned about reveal_locals from this thread. So I think primary value of adding it would be documentation. I think it's doomed to rare usage if it's documented no where. It would be nice if typing page mades references to other docs/included advice for useful typing features even if they may not be defined within typing.py. The mypy docs are main docs I learned basic type usage and I think it's very buried in them/unsure what page it lives in.
I think given rare usage, adding documentation and skipping runtime equivalent would be my vote. If years from now it becomes more commonly used, it can be reconsidered for runtime inclusion. _______________________________________________ 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: guido@python.org
-- --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-change-the-world/>
I closed my proposal to add reveal_locals() given the underwhelming response here. But one action item is to document reveal_locals() better in the type checkers that support it: - It's documented for mypy at https://mypy.readthedocs.io/en/stable/common_issues.html#displaying-the-type.... It's a bit hidden though, so we should consider making it easier to find. - I added support to pyanalyze and documented it at https://pyanalyze.readthedocs.io/en/latest/reference/extensions.html#pyanaly... - Pyright already supported it but with no documentation; I opened a PR to document it at https://github.com/microsoft/pyright/pull/2996 (and Eric merged it while I was writing this email, thanks!) El mié, 2 feb 2022 a las 8:41, Guido van Rossum (<guido@python.org>) escribió:
Honestly I think it was added to mypy by an eager contributor who had a spike use case. It sounds like nobody really cares, so let's drop it.
On Wed, Feb 2, 2022 at 12:33 AM Mehdi2277 <med2277@gmail.com> wrote:
I'm unsure where it's documented currently. I only learned about reveal_locals from this thread. So I think primary value of adding it would be documentation. I think it's doomed to rare usage if it's documented no where. It would be nice if typing page mades references to other docs/included advice for useful typing features even if they may not be defined within typing.py. The mypy docs are main docs I learned basic type usage and I think it's very buried in them/unsure what page it lives in.
I think given rare usage, adding documentation and skipping runtime equivalent would be my vote. If years from now it becomes more commonly used, it can be reconsidered for runtime inclusion. _______________________________________________ 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: guido@python.org
-- --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-change-the-world/> _______________________________________________ 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: jelle.zijlstra@gmail.com
participants (7)
-
Carl Meyer -
David Foster -
Guido van Rossum -
Jelle Zijlstra -
Martin DeMello -
Mehdi2277 -
Paul Bryan