Should typing.Union be deprecated?
Now that Python 3.10 is in Arch Linux, I'm starting to kick the tires on its typing changes. Now that types.Union is in place for the `type | type` construct, I'm wondering if there's a future for typing.Union (and typing.Optional), or if it should be flagged as deprecated. Thoughts?
El dom, 12 dic 2021 a las 19:47, Paul Bryan (<pbryan@anode.ca>) escribió:
Now that Python 3.10 is in Arch Linux, I'm starting to kick the tires on its typing changes.
Now that types.Union is in place for the `type | type` construct, I'm wondering if there's a future for typing.Union (and typing.Optional), or if it should be flagged as deprecated.
What would you propose specifically? https://docs.python.org/3.10/library/typing.html#typing.Union already encourages using | in 3.10+. I would not want to start the process of removing typing.Union from the standard library until the Python versions that need it are dead.
Thoughts?
_______________________________________________ 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
On Sun, 2021-12-12 at 20:01 -0800, Jelle Zijlstra wrote:
What would you propose specifically? https://docs.python.org/3.10/library/typing.html#typing.Union already encourages using | in 3.10+.
I would not want to start the process of removing typing.Union from the standard library until the Python versions that need it are dead.
If types.UnionType is intended to supplant typing.Union (and I'd say it certainly qualifies), then I would suggest deprecating typing.Union and typing.Optional. It would require multiple releases of Python—likely taking years—before they could actually be removed from stdlib.
On Mon, 13 Dec 2021 at 04:02, Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
El dom, 12 dic 2021 a las 19:47, Paul Bryan (<pbryan@anode.ca>) escribió:
Now that Python 3.10 is in Arch Linux, I'm starting to kick the tires on its typing changes.
Now that types.Union is in place for the `type | type` construct, I'm wondering if there's a future for typing.Union (and typing.Optional), or if it should be flagged as deprecated.
What would you propose specifically? https://docs.python.org/3.10/library/typing.html#typing.Union already encourages using | in 3.10+.
I would not want to start the process of removing typing.Union from the standard library until the Python versions that need it are dead.
+1 from me. I support libraries that have to work with Python 3.7 and later, so we'll be using Union[...] for some time yet. It would be annoying if that issued deprecation warnings or anything like that in newer Python versions before we had the option to switch to | for all of our supported versions. Paul
typing types supporting the PEP 604 syntax are actually using typing.Union underneath, not PEP 604 types.UnionType. To greatly simplify some of our C code, Serhiy added the `__or__`/`__ror__` dunders to the typing types so that they return a typing.Union. types.Union is only used for the builtin types.
typing.List | typing.Tuple typing.Union[typing.List, typing.Tuple]
There's no way we can deprecate typing.Union unless we choose one of the following: 1. Re-implement the C code in types.UnionType. (-100 from me on this, unfortunately, anything we do in C is the source of many painful edge cases :( ) 2. Allow initializing arbitrary types.UnionType, like how we already do for types.GenericAlias. This is farly easy in C, but once we add that in it's part of public API forever, and we will never be able to deprecate it. So the signature needs some careful consideration! Personally I favor option 2 if we really want the deprecation route. But I don't really see how it's any better than our current typing.Union if it's just an implementation detail. One last possibility: 3. Deprecate the square-bracket notation for typing.Union[] specifically, but keep the type around for internal representation. I also like option 3. Any sort of migration will probably take >5 years IMO.
There's no way we can deprecate typing.Union unless we choose one of the following:
Of the choices Ken presents, option (3) feels like the sanest option, to me. Keep `typing.Union` around as the return type of `TypeVar.__or__` and `TypeVar.__ror__`, etc. -- there's no reason to needlessly complicate the implementation of `types.UnionType`, nor is there any reason we should want arbitrary objects to be accepted by the `types.UnionType` constructor. But deprecate direct usage of `typing.Union` with the square-bracket syntax, with a view to eventually (in many years' time) changing the implementation such that it *cannot* be directly used in that way. Best, Alex On Tue, Dec 14, 2021 at 2:33 PM Ken Jin <kenjin4096@gmail.com> wrote:
typing types supporting the PEP 604 syntax are actually using typing.Union underneath, not PEP 604 types.UnionType. To greatly simplify some of our C code, Serhiy added the `__or__`/`__ror__` dunders to the typing types so that they return a typing.Union. types.Union is only used for the builtin types.
typing.List | typing.Tuple typing.Union[typing.List, typing.Tuple]
There's no way we can deprecate typing.Union unless we choose one of the following: 1. Re-implement the C code in types.UnionType. (-100 from me on this, unfortunately, anything we do in C is the source of many painful edge cases :( ) 2. Allow initializing arbitrary types.UnionType, like how we already do for types.GenericAlias. This is farly easy in C, but once we add that in it's part of public API forever, and we will never be able to deprecate it. So the signature needs some careful consideration!
Personally I favor option 2 if we really want the deprecation route. But I don't really see how it's any better than our current typing.Union if it's just an implementation detail. One last possibility:
3. Deprecate the square-bracket notation for typing.Union[] specifically, but keep the type around for internal representation.
I also like option 3. Any sort of migration will probably take >5 years IMO. _______________________________________________ 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: alex.waygood@gmail.com
Alright, I propose the following timeline: 1. Python 3.10 added | for Union. 2. Python 3.12 will mark subscripting typing.Union as deprecated in docs. 3. Python >=3.15 will emit deprecation warning specifically for square-bracket form of typing.Union[]. But keep typing.Union around for runtime simplicity, introspection and runtime typing `isinstance()` uses. By then, 3.9 should be EOL, so library authors shouldn't need to worry supporting that. 4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself. What do y'all think?
Yeah, sounds about right. Not sure where to put something like that -- nobody will remember that we decided on this timeline by the time 3.15 goes out, unless it's immortalized in a PEP. Maybe we should have a PEP with timelines for various typing features that are now in the core -- PEP 585, PEP 646 and PEP 677 come to mind. On Wed, Dec 15, 2021 at 7:33 AM Ken Jin <kenjin4096@gmail.com> wrote:
Alright, I propose the following timeline:
1. Python 3.10 added | for Union. 2. Python 3.12 will mark subscripting typing.Union as deprecated in docs. 3. Python >=3.15 will emit deprecation warning specifically for square-bracket form of typing.Union[]. But keep typing.Union around for runtime simplicity, introspection and runtime typing `isinstance()` uses. By then, 3.9 should be EOL, so library authors shouldn't need to worry supporting that. 4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
What do y'all 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: 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-c...>
+1 from me on this timeline, FWIW. And IMO I agree it would be good to document timelines somewhere. Some sort of "Typing feature timelines" PEP might be the best answer, similar to the release schedule PEPs for Python releases. Paul On Wed, 15 Dec 2021 at 15:52, Guido van Rossum <guido@python.org> wrote:
Yeah, sounds about right. Not sure where to put something like that -- nobody will remember that we decided on this timeline by the time 3.15 goes out, unless it's immortalized in a PEP. Maybe we should have a PEP with timelines for various typing features that are now in the core -- PEP 585, PEP 646 and PEP 677 come to mind.
On Wed, Dec 15, 2021 at 7:33 AM Ken Jin <kenjin4096@gmail.com> wrote:
Alright, I propose the following timeline:
1. Python 3.10 added | for Union. 2. Python 3.12 will mark subscripting typing.Union as deprecated in docs. 3. Python >=3.15 will emit deprecation warning specifically for square-bracket form of typing.Union[]. But keep typing.Union around for runtime simplicity, introspection and runtime typing `isinstance()` uses. By then, 3.9 should be EOL, so library authors shouldn't need to worry supporting that. 4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
What do y'all 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: guido@python.org
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ 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: p.f.moore@gmail.com
This seems reasonable, but I have a couple of suggestions/questions: Would this also apply to subscripting Optional? I might also suggest we emit a PendingDeprecationWarning on 3.12 when the docs change is made. As for where to put this timeline, an informational PEP would be fitting, or it could simply go on typing.readthedocs.io Ethan On Wed, Dec 15, 2021 at 8:21 AM Paul Moore <p.f.moore@gmail.com> wrote:
+1 from me on this timeline, FWIW. And IMO I agree it would be good to document timelines somewhere. Some sort of "Typing feature timelines" PEP might be the best answer, similar to the release schedule PEPs for Python releases.
Paul
On Wed, 15 Dec 2021 at 15:52, Guido van Rossum <guido@python.org> wrote:
Yeah, sounds about right. Not sure where to put something like that --
nobody will remember that we decided on this timeline by the time 3.15 goes out, unless it's immortalized in a PEP. Maybe we should have a PEP with timelines for various typing features that are now in the core -- PEP 585, PEP 646 and PEP 677 come to mind.
On Wed, Dec 15, 2021 at 7:33 AM Ken Jin <kenjin4096@gmail.com> wrote:
Alright, I propose the following timeline:
1. Python 3.10 added | for Union. 2. Python 3.12 will mark subscripting typing.Union as deprecated in
docs.
3. Python >=3.15 will emit deprecation warning specifically for square-bracket form of typing.Union[]. But keep typing.Union around for runtime simplicity, introspection and runtime typing `isinstance()` uses. By then, 3.9 should be EOL, so library authors shouldn't need to worry supporting that. 4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
What do y'all 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: guido@python.org
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ 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: p.f.moore@gmail.com
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: ethan@ethanhs.me
TOOWTDI suggests that we should deprecate Optional[T] in favor of T|None, even if not everybody likes the latter. On Wed, Dec 15, 2021 at 8:44 AM Ethan Smith <ethan@ethanhs.me> wrote:
This seems reasonable, but I have a couple of suggestions/questions:
Would this also apply to subscripting Optional?
I might also suggest we emit a PendingDeprecationWarning on 3.12 when the docs change is made.
As for where to put this timeline, an informational PEP would be fitting, or it could simply go on typing.readthedocs.io
Ethan
On Wed, Dec 15, 2021 at 8:21 AM Paul Moore <p.f.moore@gmail.com> wrote:
+1 from me on this timeline, FWIW. And IMO I agree it would be good to document timelines somewhere. Some sort of "Typing feature timelines" PEP might be the best answer, similar to the release schedule PEPs for Python releases.
Paul
On Wed, 15 Dec 2021 at 15:52, Guido van Rossum <guido@python.org> wrote:
Yeah, sounds about right. Not sure where to put something like that --
nobody will remember that we decided on this timeline by the time 3.15 goes out, unless it's immortalized in a PEP. Maybe we should have a PEP with timelines for various typing features that are now in the core -- PEP 585, PEP 646 and PEP 677 come to mind.
On Wed, Dec 15, 2021 at 7:33 AM Ken Jin <kenjin4096@gmail.com> wrote:
Alright, I propose the following timeline:
1. Python 3.10 added | for Union. 2. Python 3.12 will mark subscripting typing.Union as deprecated in
docs.
3. Python >=3.15 will emit deprecation warning specifically for square-bracket form of typing.Union[]. But keep typing.Union around for runtime simplicity, introspection and runtime typing `isinstance()` uses. By then, 3.9 should be EOL, so library authors shouldn't need to worry supporting that. 4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
What do y'all 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: guido@python.org
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ 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: p.f.moore@gmail.com
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: ethan@ethanhs.me
-- --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 might be alone with this opinion, but I like `typing.Union` in some cases. It feels better to write long multiline cases like this: ``` Alias = Union[ one, two, three, ] ``` Than this: ``` Alias = ( one | two | three ) ``` Some languages even allow to write `| one` to match other indentation: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/discrimina... I would love to keep both! Maybe some others feel the same :) P.S. I originally sent this letter a day ago to Ken Jin only, because I misclicked. Thanks, Ken Jin, for letting me know! ср, 15 дек. 2021 г. в 19:54, Guido van Rossum <guido@python.org>:
TOOWTDI suggests that we should deprecate Optional[T] in favor of T|None, even if not everybody likes the latter.
On Wed, Dec 15, 2021 at 8:44 AM Ethan Smith <ethan@ethanhs.me> wrote:
This seems reasonable, but I have a couple of suggestions/questions:
Would this also apply to subscripting Optional?
I might also suggest we emit a PendingDeprecationWarning on 3.12 when the docs change is made.
As for where to put this timeline, an informational PEP would be fitting, or it could simply go on typing.readthedocs.io
Ethan
On Wed, Dec 15, 2021 at 8:21 AM Paul Moore <p.f.moore@gmail.com> wrote:
+1 from me on this timeline, FWIW. And IMO I agree it would be good to document timelines somewhere. Some sort of "Typing feature timelines" PEP might be the best answer, similar to the release schedule PEPs for Python releases.
Paul
On Wed, 15 Dec 2021 at 15:52, Guido van Rossum <guido@python.org> wrote:
Yeah, sounds about right. Not sure where to put something like that --
nobody will remember that we decided on this timeline by the time 3.15 goes out, unless it's immortalized in a PEP. Maybe we should have a PEP with timelines for various typing features that are now in the core -- PEP 585, PEP 646 and PEP 677 come to mind.
On Wed, Dec 15, 2021 at 7:33 AM Ken Jin <kenjin4096@gmail.com> wrote:
Alright, I propose the following timeline:
1. Python 3.10 added | for Union. 2. Python 3.12 will mark subscripting typing.Union as deprecated in
docs.
3. Python >=3.15 will emit deprecation warning specifically for square-bracket form of typing.Union[]. But keep typing.Union around for runtime simplicity, introspection and runtime typing `isinstance()` uses. By then, 3.9 should be EOL, so library authors shouldn't need to worry supporting that. 4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
What do y'all 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: guido@python.org
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ 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: p.f.moore@gmail.com
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: ethan@ethanhs.me
-- --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: n.a.sobolev@gmail.com
Same unpopular opinion as Никита: `Union` can actually be better when there are more than two types. `Optional` can be better when there are other special operators. (Somewhat off-topic since PEP 677 is a draft PEP, but still about Union vs `|`. Commenting just in case it is useful and in case you have solutions.) I discovered with the new callable syntax (PEP 677) that a naive usage of `|` can be confusing. 1. We can't naively union a callable type with another type: ``` union_of_callables: (int) -> str | (bool) -> str # Syntax error! union_of_callable2: ((int) -> str) | ((bool) -> str) # Needs extra parens. Not intuitive or user-friendly. union_of_callables3: Union[(int) -> str, (bool) -> str, (list[int]) -> str] # Simpler and can be easily split into multiple lines, as Никита mentioned. ``` Likewise, `int | (str) -> bool` is a syntax error. 2. Another huge gotcha is with Optional callables if we naively use `<new syntax> | None`: ``` old: Optional[Callable[[int], str]] with_pipe: Callable[[int], str] | None naive_translation_to_new_syntax: (int) -> str | None # WRONG! The return type ends up being (str | None). naive_attempt_to_fix_above_error: None | (int) -> str # Syntax error! intended: ((int) -> str) | None # Unintuitive, unfriendly. unambiguous_and_simple: Optional[(int) -> str] ``` Same goes for `(int) -> str | bool`, etc. The `| bool` gets treated as part of the return type. Such Optional callable types occur very often (around a quarter of all Callables in typeshed). I don't have a good solution to this. We may just have to live with it. ------------- Parser experts: do you know of a way to solve these syntax problems? I don't mean to suggest that we *have* to keep `Union` and `Optional` around :) But, right now, there are definitely cases where they are clearly better than the `|` syntax. PS: Tests for PEP 677: https://github.com/stroxler/cpython/blob/callable-type-syntax--shorthand/Lib... On Thu, Dec 16, 2021 at 7:10 AM Никита Соболев <n.a.sobolev@gmail.com> wrote:
I might be alone with this opinion, but I like `typing.Union` in some cases.
It feels better to write long multiline cases like this:
``` Alias = Union[ one, two, three, ] ```
Than this:
``` Alias = ( one | two | three ) ```
Some languages even allow to write `| one` to match other indentation: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/discrimina...
I would love to keep both! Maybe some others feel the same :)
P.S. I originally sent this letter a day ago to Ken Jin only, because I misclicked. Thanks, Ken Jin, for letting me know!
ср, 15 дек. 2021 г. в 19:54, Guido van Rossum <guido@python.org>:
TOOWTDI suggests that we should deprecate Optional[T] in favor of T|None, even if not everybody likes the latter.
On Wed, Dec 15, 2021 at 8:44 AM Ethan Smith <ethan@ethanhs.me> wrote:
This seems reasonable, but I have a couple of suggestions/questions:
Would this also apply to subscripting Optional?
I might also suggest we emit a PendingDeprecationWarning on 3.12 when the docs change is made.
As for where to put this timeline, an informational PEP would be fitting, or it could simply go on typing.readthedocs.io
Ethan
On Wed, Dec 15, 2021 at 8:21 AM Paul Moore <p.f.moore@gmail.com> wrote:
+1 from me on this timeline, FWIW. And IMO I agree it would be good to document timelines somewhere. Some sort of "Typing feature timelines" PEP might be the best answer, similar to the release schedule PEPs for Python releases.
Paul
On Wed, 15 Dec 2021 at 15:52, Guido van Rossum <guido@python.org> wrote:
Yeah, sounds about right. Not sure where to put something like that
-- nobody will remember that we decided on this timeline by the time 3.15 goes out, unless it's immortalized in a PEP. Maybe we should have a PEP with timelines for various typing features that are now in the core -- PEP 585, PEP 646 and PEP 677 come to mind.
On Wed, Dec 15, 2021 at 7:33 AM Ken Jin <kenjin4096@gmail.com> wrote:
Alright, I propose the following timeline:
1. Python 3.10 added | for Union. 2. Python 3.12 will mark subscripting typing.Union as deprecated in
docs.
3. Python >=3.15 will emit deprecation warning specifically for square-bracket form of typing.Union[]. But keep typing.Union around for runtime simplicity, introspection and runtime typing `isinstance()` uses. By then, 3.9 should be EOL, so library authors shouldn't need to worry supporting that. 4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
What do y'all 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: guido@python.org
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ 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: p.f.moore@gmail.com
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: ethan@ethanhs.me
-- --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: n.a.sobolev@gmail.com
_______________________________________________ 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: gohanpra@gmail.com
-- S Pradeep Kumar
El jue, 16 dic 2021 a las 10:30, S Pradeep Kumar (<gohanpra@gmail.com>) escribió:
Same unpopular opinion as Никита: `Union` can actually be better when there are more than two types. `Optional` can be better when there are other special operators.
(Somewhat off-topic since PEP 677 is a draft PEP, but still about Union vs `|`. Commenting just in case it is useful and in case you have solutions.)
I discovered with the new callable syntax (PEP 677) that a naive usage of `|` can be confusing.
1. We can't naively union a callable type with another type:
``` union_of_callables: (int) -> str | (bool) -> str # Syntax error!
union_of_callable2: ((int) -> str) | ((bool) -> str) # Needs extra parens. Not intuitive or user-friendly.
union_of_callables3: Union[(int) -> str, (bool) -> str, (list[int]) -> str] # Simpler and can be easily split into multiple lines, as Никита mentioned. ```
Likewise, `int | (str) -> bool` is a syntax error.
I feel like this should be legal. Is there a strong reason to disallow it?
Interestingly, TypeScript also disallows this and has a specific error message for this case: - Function type notation must be parenthesized when used in a union type.
Yes, TypeScript has the same issue. It's a rare case (I've hit it only a handful of times in the last 5+ years), there's a good error message provided, and the workaround (adding extra parens) is straightforward and obvious to most programmers as the way to solve operator precedence issues. So it's not a big problem. -Eric
I think there's a pretty good reason to disallow it. We definitely want `|` to bind tighter than `->` because using union and optional types in the return position will be very common. If we do that, then the obvious grammar rules make `|` unions of un-parenthesized callable types illegal as an artifact of PEG grammar. It's probably possible to special-case it but I think making the precedence of `|` versus `->` order-dependent would be very questionable. Plus, since the `None` is conventionally a suffix in `X | None` types, it wouldn't help that much anyway. I think TypeScript is doing the right thing here. We can definitely use invalid_ grammar rules to customize our error messages, much as Eric says TypeScript does
Correction: Pradeep pointed out that it's not actually true, among existing typeshed annotations, that a union or optional in return position is more common than an optional callable. I still don't see it as very viable to have `->` bind tighter though, because that would be inconsistent with function signature syntax, and probably a surprise coming from other languages - in every one I've looked at, `->` consistently binds less tightly.
On Thu, Dec 16, 2021 at 10:30 AM S Pradeep Kumar <gohanpra@gmail.com> wrote:
Same unpopular opinion as Никита: `Union` can actually be better when there are more than two types.
I'm not convinced this is all that unpopular an opinion (and it's one I also share.) And if we're judging on popularity, I suspect that breaking existing code with a deprecation, even a relatively trivial one, is likely to be far more unpopular.
`Optional` can be better when there are other special operators.
I prefer `Optional` flat out. I find it more readable in general, even in the simple cases, and it's certainly far more explicit about the intent.
Am 17.12.21 um 05:08 schrieb Andrew Beyer:
`Optional` can be better when there are other special operators. I prefer `Optional` flat out. I find it more readable in general, even in the simple cases, and it's certainly far more explicit about the intent.
Experience show that Optional is problematic, though, due to its name. Many new people coming to typing mix up optional arguments and arguments with an Optional type. The earlier we get rid of Optional the better. - Sebastian
+1 On Wed, 2021-12-15 at 15:33 +0000, Ken Jin wrote:
Alright, I propose the following timeline:
1. Python 3.10 added | for Union. 2. Python 3.12 will mark subscripting typing.Union as deprecated in docs. 3. Python >=3.15 will emit deprecation warning specifically for square-bracket form of typing.Union[]. But keep typing.Union around for runtime simplicity, introspection and runtime typing `isinstance()` uses. By then, 3.9 should be EOL, so library authors shouldn't need to worry supporting that. 4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
What do y'all 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: pbryan@anode.ca
The timeline LGTM!
On 15 Dec 2021, at 15:33, Ken Jin <kenjin4096@gmail.com> wrote:
Alright, I propose the following timeline:
1. Python 3.10 added | for Union. 2. Python 3.12 will mark subscripting typing.Union as deprecated in docs. 3. Python >=3.15 will emit deprecation warning specifically for square-bracket form of typing.Union[]. But keep typing.Union around for runtime simplicity, introspection and runtime typing `isinstance()` uses. By then, 3.9 should be EOL, so library authors shouldn't need to worry supporting that. 4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
What do y'all 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: alex.waygood@gmail.com
On Wed, Dec 15, 2021 at 03:33:06PM -0000, Ken Jin wrote:
4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
I'm sorry, I've come in late to this discussion and I don't understand why we're removing the Union[] syntax. Isn't that just gratuitous breakage of working code? It seems especially gratuitous since the Union type itself is not going to be removed. I've gone back to the start of the thread https://mail.python.org/archives/list/typing-sig@python.org/thread/TW5M6XDN7... where Paul asked the question "Should typing.Union be deprecated?", and from that point on the conversation seems to have assumed that the answer is "Yes" without anyone giving any arguments for why forcing this code churn on typing users is a good idea. Given that we're decided that the Union type has to remain, is supporting square brackets such a burden that we should remove it? Over in the Python-Ideas and Python-Dev mailing lists, and the bug tracker, the philosophy seems to be that *code stability* is paramount, and that features once added should be kept for backwards-compatibility even if they have been superceded by a newer, better feature. For the most part, with few exceptions, we can run Python 3.0 code in 3.10 unchanged. Shouldn't this apply to typing now? It has been five full releases and six years since the typing module was introduced, and there is no note in the documentation that the API is provisional or unstable. That's not to say that features cannot be removed, but there should be a good reason given, and "we prefer the | syntax" is not, IMO, good enough. If there are any better reasons for the removal, they aren't obvious to me. Have I missed something? -- Steve
TOOWTDI. On Thu, Dec 16, 2021 at 18:39 Steven D'Aprano <steve@pearwood.info> wrote:
On Wed, Dec 15, 2021 at 03:33:06PM -0000, Ken Jin wrote:
4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
I'm sorry, I've come in late to this discussion and I don't understand why we're removing the Union[] syntax. Isn't that just gratuitous breakage of working code?
It seems especially gratuitous since the Union type itself is not going to be removed.
I've gone back to the start of the thread
https://mail.python.org/archives/list/typing-sig@python.org/thread/TW5M6XDN7...
where Paul asked the question "Should typing.Union be deprecated?", and from that point on the conversation seems to have assumed that the answer is "Yes" without anyone giving any arguments for why forcing this code churn on typing users is a good idea.
Given that we're decided that the Union type has to remain, is supporting square brackets such a burden that we should remove it?
Over in the Python-Ideas and Python-Dev mailing lists, and the bug tracker, the philosophy seems to be that *code stability* is paramount, and that features once added should be kept for backwards-compatibility even if they have been superceded by a newer, better feature. For the most part, with few exceptions, we can run Python 3.0 code in 3.10 unchanged.
Shouldn't this apply to typing now? It has been five full releases and six years since the typing module was introduced, and there is no note in the documentation that the API is provisional or unstable.
That's not to say that features cannot be removed, but there should be a good reason given, and "we prefer the | syntax" is not, IMO, good enough. If there are any better reasons for the removal, they aren't obvious to me.
Have I missed something?
-- Steve _______________________________________________ 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 (mobile)
On Fri, 17 Dec 2021 at 02:39, Steven D'Aprano <steve@pearwood.info> wrote:
On Wed, Dec 15, 2021 at 03:33:06PM -0000, Ken Jin wrote:
4. Python >=3.17 will remove typing.Union[] square bracket usage altogether. Again, we're keeping the typing.Union type itself.
I'm sorry, I've come in late to this discussion and I don't understand why we're removing the Union[] syntax. Isn't that just gratuitous breakage of working code?
This is after more than five releases of Python, so it's well within any backward compatibility policy we have. So it's hardly "gratuitous breakage" at this point.
It seems especially gratuitous since the Union type itself is not going to be removed.
I've gone back to the start of the thread
https://mail.python.org/archives/list/typing-sig@python.org/thread/TW5M6XDN7...
where Paul asked the question "Should typing.Union be deprecated?", and from that point on the conversation seems to have assumed that the answer is "Yes" without anyone giving any arguments for why forcing this code churn on typing users is a good idea.
However, I do agree that there seems to be a general attitude that breaking changes are acceptable, to a far larger extent than the widet Python development community would accept.
Given that we're decided that the Union type has to remain, is supporting square brackets such a burden that we should remove it?
Over in the Python-Ideas and Python-Dev mailing lists, and the bug tracker, the philosophy seems to be that *code stability* is paramount, and that features once added should be kept for backwards-compatibility even if they have been superceded by a newer, better feature. For the most part, with few exceptions, we can run Python 3.0 code in 3.10 unchanged.
Shouldn't this apply to typing now? It has been five full releases and six years since the typing module was introduced, and there is no note in the documentation that the API is provisional or unstable.
I agree. A lot of typing features seem to be developed in isolation from the mainstream of Python development discussion, and with a significantly different mindset around backward compatibility. By the time proposals are presented on python-dev, they feel like a "fait accompli" and it's hard to push back. Given that type annotations are becoming far more prevalent in "average" Python code, maybe it's time for more of the discussions to be held in the broader python-dev and python-ideas lists?
That's not to say that features cannot be removed, but there should be a good reason given, and "we prefer the | syntax" is not, IMO, good enough. If there are any better reasons for the removal, they aren't obvious to me.
I'm not even sure that it's true that the broader "we" do prefer the | syntax. Has that been tested outside of the typing SIG? And people here have started pointing out that Union[] is more readable with complex types, so I'm not even sure support is universal within the typing community. On Fri, 17 Dec 2021 at 03:00, Guido van Rossum <guido@python.org> wrote:
TOOWTDI.
While I don't expect to get very far arguing the Zen with Guido, I don't particularly think this applies here. In fact, I'd argue that there are cases where the | syntax is *less* obvious, and doesn't express intent as well. This is (to my mind, at least) very clear with Optional, where Optional[int] says "you can provide an int, or miss this out", but int | None says "you can provide an int or the value None". When None is merely a sentinel, representing "use the default", Optional[int] expresses the intent far better, and hence is more "obvious" to me¹. The case for Union is weaker here, admittedly, although I do still think there are times when expressing something as "a union of two types" is closer to the intent than "type A or type B". But even if A|B is considered more obvious than Union[A,B], I still think "being able to correctly express your intent, even if the implementation is the same in either case" is a good argument for retaining Optional. Paul ¹ Disclaimer: I'm not Dutch ;-)
However, I do agree that there seems to be a general attitude that breaking changes are acceptable, to a far larger extent than the widet Python development community would accept. When was there ever a breaking change in typing? Even during its
I agree. A lot of typing features seem to be developed in isolation from the mainstream of Python development discussion, and with a significantly different mindset around backward compatibility. By the time proposals are presented on python-dev, they feel like a "fait accompli" and it's hard to push back. Typing features are developed on a public PSF mailing list and in a
Am 17.12.21 um 10:47 schrieb Paul Moore: provisional phase (up to Python 3.5), I don't remember any breaking changes, and this is the first time I remember a breaking change being discussed. public GitHub repository belonging to the python organization. Everybody is welcome to participate. You can hardly place blame on the typing community for "developing in isolation".
This is (to my mind, at least) very clear with Optional, where Optional[int] says "you can provide an int, or miss this out", but int | None says "you can provide an int or the value None". When None is merely a sentinel, representing "use the default", Optional[int] expresses the intent far better, and hence is more "obvious" to me¹.
But "Optional" does *not* mean that you can "miss this out". (" = ..." means that in arguments like in rest of Python.) It means "you can provide an int or the value None". This is a common mistake and a good demonstration why "Optional" should be deprecated. - Sebastian
On Fri, 17 Dec 2021 at 11:32, Sebastian Rittau <srittau@rittau.biz> wrote:
Am 17.12.21 um 10:47 schrieb Paul Moore:
This is (to my mind, at least) very clear with Optional, where Optional[int] says "you can provide an int, or miss this out", but int | None says "you can provide an int or the value None". When None is merely a sentinel, representing "use the default", Optional[int] expresses the intent far better, and hence is more "obvious" to me¹.
But "Optional" does *not* mean that you can "miss this out". (" = ..." means that in arguments like in rest of Python.) It means "you can provide an int or the value None". This is a common mistake and a good demonstration why "Optional" should be deprecated.
So how do I annotate the following function to say that callers can only pass an int, or omit the argument? def my_fn(a=None): if a is None: a = <some complex calculation that I don't want to do in the function header> In this case, my *intention* is that the user should only ever pass an integer as a value for a. The use of None is a technical detail, not a part of the declared API. I might later choose to replace None with an opaque sentinel, and I want the type hints to express that by saying that a is an optional integer, but *not* that None is a valid value, so that callers which pass an explicit None get flagged. (Yes, I accept that maybe this is bad API design. But I'd rather not get sidetracked on that point - I *can* argue that there are cases where it might be reasonable, but it's not the point here). I understand that the *implementation* of Optional[int] is identical to int|None. But my point is that the *intent* is different, and being able to express intent, even if it's not (currently...) possible to actually check the difference doesn't alter that. Remember that I'm responding to the idea that int|None is the "one obvious way" to do this - but for me, it's *not* obvious because it expresses the wrong intention. It's similar to the fact that Python has a += 1 and a = a + 1. The former expresses the intention "increment" whereas the latter expresses the intention to set a to a new value based on an expression. Which I use depends on what I intend to convey to the human reader - even though the computer doesn't care about the difference. Paul
Am 17.12.21 um 13:50 schrieb Paul Moore:
On Fri, 17 Dec 2021 at 11:32, Sebastian Rittau <srittau@rittau.biz> wrote:
But "Optional" does *not* mean that you can "miss this out". (" = ..." means that in arguments like in rest of Python.) It means "you can provide an int or the value None". This is a common mistake and a good demonstration why "Optional" should be deprecated.
So how do I annotate the following function to say that callers can only pass an int, or omit the argument?
def my_fn(a=None): if a is None: a = <some complex calculation that I don't want to do in the function header>
def my_fn(a: int | None = None): ... The intention that the argument is optional is expressed by the "=" operator. None is a valid type here and the annotation above makes this explicit. The following are completely legal calls: f(None) f(some_dict.get("abc")) Using "Optional" to mark an argument could mean that the argument is optional and accepts None, but it can (and is) also used for non-optional arguments. On the other hand, there are optional arguments that can't be marked with "Optional", because they don't accept None. And finally there are optional arguments that accept None, but where None is not the default. typing.Optional and optional arguments are completely orthogonal concepts. - Sebastian
On Fri, 17 Dec 2021 at 13:04, Sebastian Rittau <srittau@rittau.biz> wrote:
The intention that the argument is optional is expressed by the "=" operator. None is a valid type here and the annotation above makes this explicit. The following are completely legal calls:
f(None) f(some_dict.get("abc"))
I'm not going to waste everyone's time debating ths, TBH, but that's precisely the sort of usage I'd prefer it if the type system flagged as incorrect. I get that this isn't what Optional actually does, but at least with Optional there's the possibility that in the future it *could*, whereas there's no such possibility with int | None. I'd love to hear what other Python users think about this, but I don't think many of the "usual suspects" from python-ideas/python-dev hang out here. Anyway, I've said my piece, I'll drop out of this conversation now. Paul
I don’t think any such intent was intentional. It’s probably a reference to option types found in functional languages like Haskell (although it doesn’t function like an option type). Something I haven’t seen brought up is how one would create a union programmatically without Union. Would you call type.__or__ on types recursively? Or do we consider such runtime uses to be outside the scope of typing? Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, December 17th, 2021 at 14:50, Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, 17 Dec 2021 at 11:32, Sebastian Rittau srittau@rittau.biz wrote:
Am 17.12.21 um 10:47 schrieb Paul Moore:
This is (to my mind, at least) very clear with
Optional, where Optional[int] says "you can provide an int, or miss
this out", but int | None says "you can provide an int or the value
None". When None is merely a sentinel, representing "use the default",
Optional[int] expresses the intent far better, and hence is more
"obvious" to me¹.
But "Optional" does not mean that you can "miss this out". (" = ..."
means that in arguments like in rest of Python.) It means "you can
provide an int or the value None". This is a common mistake and a good
demonstration why "Optional" should be deprecated.
So how do I annotate the following function to say that callers can
only pass an int, or omit the argument?
def my_fn(a=None):
if a is None:
a = <some complex calculation that I don't want to do in
the function header>
In this case, my intention is that the user should only ever pass an
integer as a value for a. The use of None is a technical detail, not a
part of the declared API. I might later choose to replace None with an
opaque sentinel, and I want the type hints to express that by saying
that a is an optional integer, but not that None is a valid value,
so that callers which pass an explicit None get flagged. (Yes, I
accept that maybe this is bad API design. But I'd rather not get
sidetracked on that point - I can argue that there are cases where
it might be reasonable, but it's not the point here).
I understand that the implementation of Optional[int] is identical
to int|None. But my point is that the intent is different, and being
able to express intent, even if it's not (currently...) possible to
actually check the difference doesn't alter that. Remember that I'm
responding to the idea that int|None is the "one obvious way" to do
this - but for me, it's not obvious because it expresses the wrong
intention.
It's similar to the fact that Python has a += 1 and a = a + 1. The
former expresses the intention "increment" whereas the latter
expresses the intention to set a to a new value based on an
expression. Which I use depends on what I intend to convey to the
human reader - even though the computer doesn't care about the
difference.
Paul
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: layday@protonmail.com
On Fri, 2021-12-17 at 13:17 +0000, layday via Typing-sig wrote:
Something I haven’t seen brought up is how one would create a union programmatically without Union. Would you call type.__or__ on types recursively? Or do we consider such runtime uses to be outside the scope of typing?
x = str y = int x |= y x str | int
On Fri, Dec 17, 2021 at 01:48 Paul Moore <p.f.moore@gmail.com> wrote:
Given that type annotations are becoming far more prevalent in "average" Python code, maybe it's time for more of the discussions to be held in the broader python-dev and python-ideas lists?
I’d be happy if that could happen. So far, unfortunately, the Python-dev discussion of typing always seems to run into unproductive anti-typing rants by people who are not using them but nevertheless have an opinion on them. (And let’s leave Python-ideas out of it. That list has become too toxic.) -- --Guido (mobile)
I would like to keep Union and Optional as (maybe) discouraged but definitely not deprecated. We are experimenting with using modern `int|None` type hints on my job for server-side code where we can upgrade supported Python versions easily. On the other hand, I would keep old-good syntax as an *option* unless end-of-life for all Python versions that don't support implicit type unions. Offtopic. When Guido introduced type hints in 2014, I was very skeptical regarding the whole idea -- but wrote no negative opinion in public space. I thought: "Maybe This Guy knows and feels something better than me?" Later I started to use typing in simple projects and libraries. Switched FOSS libraries to declare type hints. Apparently I'm using 'mypy --strict' everywhere at my job and core FOSS libs under my direct control. I hope people who don't feel typing is useful will step over their objections and love *optional* types as I do now. On Fri, Dec 17, 2021 at 6:36 PM Guido van Rossum <guido@python.org> wrote:
On Fri, Dec 17, 2021 at 01:48 Paul Moore <p.f.moore@gmail.com> wrote:
Given that type annotations are becoming far more prevalent in "average" Python code, maybe it's time for more of the discussions to be held in the broader python-dev and python-ideas lists?
I’d be happy if that could happen. So far, unfortunately, the Python-dev discussion of typing always seems to run into unproductive anti-typing rants by people who are not using them but nevertheless have an opinion on them.
(And let’s leave Python-ideas out of it. That list has become too toxic.)
-- --Guido (mobile) _______________________________________________ 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: andrew.svetlov@gmail.com
-- Thanks, Andrew Svetlov
@All, For the record, I don't feel particularly strongly towards either typing.Union or `|` (at the very least, not enough to debate for either). We have 3 years to come to a decision, so lots of time to decide :). One useful takeaway: keeping track of typing deprecations is hard. I plan to draft up a typing features deprecation timeline PEP for other stuff in typing that are *already* deprecated. Like PEP 585 analogues, typing.io, typing.re etc.. It should help everyone keep track of timelines. I will definitely leave out typing.Union for now until some sort of decision is made. I also feel that a PEP is justified since typing has now become a big part of the language in many large libraries. Thanks for the feedback everyone! Anyways, like what @Andrew mentioned, we could probably stick a huge notice in the typing.Union docs saying `|` is preferred for readability in most cases, and not deprecate it for now. @ Steven
where Paul asked the question "Should typing.Union be deprecated?", and from that point on the conversation seems to have assumed that the answer is "Yes" without anyone giving any arguments ...
I proposed a timeline to gauge sentiment. We could have everyone discuss design philosophy, but I really doubt we will come to any kind of consensus soon :). I'm not going try force everyone to like `|`. From what I've read, `typing.Union` does have valid use cases which I empathize with. Also, the opinion that `|` looks better is legitimate. When you have complex types, they sometimes have horrendously long (sometimes even nested when expanded fully) typing.Union[...] hints when hovering over things in the IDE. Similarly, when auto-generating function signatures with complex type hints in sphinx, the hints are nigh unreadable. Now it's still horrendously long, but significantly more readable with `|`. That was PEP 604's goal anyways -- to reduce verbosity.
It seems especially gratuitous since the Union type itself is not going to be removed.
That's a choice borne out of practicality instead of philosophy, I proposed not removing it so that runtime type validators don't break overnight. I'd argue that this should be an easy upgrade for users, something like https://github.com/asottile/pyupgrade should be able to automatically do it. This isn't like the Python 2 -> 3 transition where bytes, strings, and all sorts of other things caused huge headaches. FYI, PEP 484 is still provisional, so type hints and their syntax (and how type checkers interpreter them) are seemingly still provisional. However I admit that typing.py itself hasn't been provisional since 3.7.x.
On Sat, 18 Dec 2021 at 02:54, Ken Jin <kenjin4096@gmail.com> wrote:
FYI, PEP 484 is still provisional, so type hints and their syntax (and how type checkers interpreter them) are seemingly still provisional. However I admit that typing.py itself hasn't been provisional since 3.7.x.
It's been 7 years since PEP 484 was accepted. Isn't it about time to take the "Provisional" label off? Particularly if it's still viewed by anyone as a legitimate reason to de-emphasise backward compatibility. Paul
Hi Paul, to clarify, I didn't mean to insinuate that we can break backwards compatibility in typing.py, and I apologize if it seemed that way. I was replying to Steven's claim that none of typing is marked as 'Provisional'. Maybe I shouldn't have been such a pedant ;-). Like I stated above, typing.py (the module itself) is non-provisional. A few of us tried to change PEP 484 to "Final", but we realized the PEP was too loaded. Please see our discussion here https://github.com/python/peps/pull/1942. I'll try my best to summarize (adapted/paraphrased from Jelle's response, mixed with mine, thanks for his insight!): PEP 484 is a bit special. Apart from specifying typing.py's behavior, it's also a specification for what all type checkers should do. There are no other documents specifying the behavior of type checkers as extensively as PEP 484, (the typing docs in CPython don't cut it). The problem here is that if we discover some wart or edge case in PEP 484's type checker behavior (and we still do every year!), we need to update it. Marking it as "Final" would mean we can no longer change PEP 484 to fix things in this manner. Some of us proposed to decouple the type checker specification from PEP 484, but that's a huge undertaking.
On Sat, 18 Dec 2021 at 12:14, Ken Jin <kenjin4096@gmail.com> wrote:
Hi Paul, to clarify, I didn't mean to insinuate that we can break backwards compatibility in typing.py, and I apologize if it seemed that way. I was replying to Steven's claim that none of typing is marked as 'Provisional'. Maybe I shouldn't have been such a pedant ;-). Like I stated above, typing.py (the module itself) is non-provisional.
No apology needed, I'm all in favour of pedantry :-) But to be serious, people (like myself) who are outsiders will not be aware of the nuances, and will see the PEP as "Provisional" and make inferences based on that. Which probably isn't what you want. We have the same issue in packaging, where we *also* use the PEP system for purposes outside of its original intent. We've been hit by *precisely* this issue, as PEP 517 (one of the packaging interface specs) was for a long time left as "Provisional", and people outside of the packaging community took that as meaning it "wasn't ready", which delayed adoption of important new features. It wasn't a disaster, but it was definitely something we should have avoided, by being more careful to mark the PEP as "Final".
A few of us tried to change PEP 484 to "Final", but we realized the PEP was too loaded. Please see our discussion here https://github.com/python/peps/pull/1942. I'll try my best to summarize (adapted/paraphrased from Jelle's response, mixed with mine, thanks for his insight!):
The comment "one reason PEP 484 is a bit special is that for a lot of things it's the only specification" from that thread is particularly interesting, as we had precisely the same issue with PEP 517 (it's *still* the only documentation of the particular interface it defines), and we had to be careful with clarifications and extensions (we basically approved the changes as a "PEP update" and included them in a "Summary of changes" section. It's not precisely in line with the standard process, but it worked well enough in this case.
PEP 484 is a bit special. Apart from specifying typing.py's behavior, it's also a specification for what all type checkers should do. There are no other documents specifying the behavior of type checkers as extensively as PEP 484, (the typing docs in CPython don't cut it). The problem here is that if we discover some wart or edge case in PEP 484's type checker behavior (and we still do every year!), we need to update it. Marking it as "Final" would mean we can no longer change PEP 484 to fix things in this manner.
Yeah, that's very similar to packaging interoperability specs. I'd strongly recommend adding at least a "Summary of Changes" section to PEP 484, so people can easily see the evolution, and so that it's more visible if the level of change gets too high (repeated small changes often look far less of an issue than the cumulative result actually is).
Some of us proposed to decouple the type checker specification from PEP 484, but that's a huge undertaking.
Yeah, big reworks of documentation like that are good in theory, but not actually practical. All of this sounds very like the sorts of things packaging has encountered. Our solutions aren't by any means perfect, and there's lots of differences which mean what we do might not suit the typing community's needs, but there's a lot of overlap, and I'm sure we could learn from each other. Paul
I believe that the provisional status for PEP 484 is a mistake. We shouldn't change anything it specifies. The only updates that *might* be added at this point would be clarifications of existing intent, where PEP 484 is trying to specify something but the wording has confused some folks. There's a better mid-point between Provisional and Final: Accepted. That shouldn't be a problem (but to be sure you could ask the SC through its tracker). On Sat, Dec 18, 2021 at 2:44 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Sat, 18 Dec 2021 at 02:54, Ken Jin <kenjin4096@gmail.com> wrote:
FYI, PEP 484 is still provisional, so type hints and their syntax (and how type checkers interpreter them) are seemingly still provisional. However I admit that typing.py itself hasn't been provisional since 3.7.x.
It's been 7 years since PEP 484 was accepted. Isn't it about time to take the "Provisional" label off? Particularly if it's still viewed by anyone as a legitimate reason to de-emphasise backward compatibility.
-- --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...>
PR to CPython stating that `|` is preferred over `Union`: https://github.com/python/cpython/pull/30222 I would appreciate your feedback! сб, 18 дек. 2021 г. в 22:00, Guido van Rossum <guido@python.org>:
I believe that the provisional status for PEP 484 is a mistake. We shouldn't change anything it specifies. The only updates that *might* be added at this point would be clarifications of existing intent, where PEP 484 is trying to specify something but the wording has confused some folks.
There's a better mid-point between Provisional and Final: Accepted. That shouldn't be a problem (but to be sure you could ask the SC through its tracker).
On Sat, Dec 18, 2021 at 2:44 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Sat, 18 Dec 2021 at 02:54, Ken Jin <kenjin4096@gmail.com> wrote:
FYI, PEP 484 is still provisional, so type hints and their syntax (and how type checkers interpreter them) are seemingly still provisional. However I admit that typing.py itself hasn't been provisional since 3.7.x.
It's been 7 years since PEP 484 was accepted. Isn't it about time to take the "Provisional" label off? Particularly if it's still viewed by anyone as a legitimate reason to de-emphasise backward compatibility.
-- --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: n.a.sobolev@gmail.com
participants (16)
-
Alex Waygood -
Andrew Beyer -
Andrew Svetlov -
Eric Traut -
Ethan Smith -
Guido van Rossum -
Jelle Zijlstra -
Ken Jin -
layday -
Paul Bryan -
Paul Moore -
S Pradeep Kumar -
Sebastian Rittau -
Steven D'Aprano -
Steven Troxler -
Никита Соболев