[Python-Dev] Re: PEP 677 (Callable Type Syntax): Rejection notice.
Hello! Thanks for the decision, the points raised mostly make sense to me. However, I find myself and a few others are a little confused by point 2. I can read it as saying the following perhaps slightly contradictory things: "It's good that PEP 677 is conservative and sticks to things Callable can do" "PEP 677 isn't necessary, since Callable can do everything currently proposed" "PEP 677 could be a slippery slope for further syntax expansions that can do things Callable cannot" Would the case for new syntax have been stronger if it was proposing something Callable couldn't do? E.g., is the concern something like "The cost of new syntax is best paid by expanding the realm of what is expressible. While we see how PEP 677 could lead to such expansion in the future, the merits of future expansion are currently uncertain and the current proposal is too costly discussed on its own merits"? Or is the concern forward compatibility in the eventuality of further syntax expansions? PEP 677 did discuss "extended syntax", which the proposed syntax would be forward compatible with. https://www.python.org/dev/peps/pep-0677/#extended-syntax-supporting-named-and-optional-arguments Or something else entirely! Would appreciate any clarity :-) Thank you! On Wed, 9 Feb 2022 at 19:45, Gregory P. Smith wrote: > Thank you PEP authors for producing a very well written and laid out PEP. > That made it easy to understand the proposal, rationale, and alternatives > considered. We agree that the existing typing.Callable syntax, while > capable, is less than ideal for humans. That said, we deliberated last week > and ultimately decided to reject PEP-677 Callable Type Syntax. > > Why? Several considerations led us here: > > 1. We feel we need to be cautious when introducing new syntax. Our new > parser presents understandably exciting opportunities but we don’t want its > existence to mean we add new syntax easily. A feature for use only in a > fraction of type annotations, not something every Python user uses, did not > feel like a strong enough reason to justify the complexity needed to parse > this new syntax and provide meaningful error messages. Not only code > complexity, humans are also parsers that must look forwards and backwards. > > 2. While the current Callable[x, y] syntax is not loved, it does work. > This PEP isn’t enabling authors to express anything they cannot already. > The PEP explicitly chose be conservative and not allow more syntax to > express features going beyond what Callable supports. We applaud that > decision, starting simple is good. But we can imagine a future where the > syntax would desire to be expanded upon. > > 3. In line with past SC guidance, we acknowledge challenges when syntax > desires do not align between typing and Python itself. Each time we add > syntax solely for typing it shifts us further in the direction of typing > being its own mini-language so we aim to tread lightly in what gets added > here. Adopting PEP 677 would lock us into its syntax forever, potentially > preventing other future syntax directions. > > 4. We did not like the visual and cognitive consequence of multiple `->` > tokens in a def. Especially when code is not formatted nicely. Though we > admit the correlation between Python typing and formatter users is high. > > ## Recommendation for future syntax enhancements: > > When proposing a syntax change, low complexity is better. While not always > possible, it’s ideal if it could still be described using our old <=3.8 > parser. It is important to have in mind that adding syntax that only our > modern PEG parser can handle could lead to greater cognitive load and > external tooling implementation costs. > > This should not be read as a ban on PEG-only syntax, we just think it > should be used for broadly applicable features or else be relatively > unintrusive. > > Thanks, > The 3.11 Python Steering Council > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/NHCLHCU2XCWTBGF732WESMN42YYVKOXB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MCCF22SMV5VZGGQLYVIV7KECT7KH3F2W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] RFC on PEP 680 -- tomllib: Support for Parsing TOML in the Standard Library
Hello all, Link to the PEP: https://www.python.org/dev/peps/pep-0680/ Please redirect discussion to: https://discuss.python.org/t/13040 PEP 680 proposes adding the tomllib module to the standard library for parsing TOML <https://toml.io>. The main motivation is to address bootstrapping problems with pyproject.toml based builds. Thank you to everyone who has already left comments, suggestions and reacts on the Discuss thread! We welcome any further suggestions before submitting to the Steering Council :-) Thanks, Shantanu Jain Taneli Hukkinen ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BVWOZUY4M7B5WNOJCAAMS6VXWAQ6NA6R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
@Paul > ... missing resource is a central set of typing documentation that includes examples, FAQs and best practices as well as reference materials Like Sebastian, I agree, and this is something we're making progress on. > ... easy way of testing that the stubs are correct mypy ships with a tool called stubtest. It's what typeshed uses to validate itself against CPython. I recently wrote up documentation for it, see here: https://mypy.readthedocs.io/en/latest/stubtest.html > A lot of the frustration I see being expressed here (including my own) seems to come from the fact that it's so difficult to actually take that sort of "I can ignore it if I don't use it" Thanks for not staying quiet and helping us make typing better. In particular, I think one takeaway from this thread is that a lot of our documentation is focussed on "how to get started with typing my code", and not much addressed at library authors with limited time to deal with typing questions (like "what is a PEP 561" and "if my type hints are incomplete does that cause problems for my users") On Thu, 2 Dec 2021 at 15:34, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > I assume you accidentally pressed Send prematurely. > Still, maybe you have inadvertently listed everything that is agreed about > typing PEPs. 😂 > Rob Cliffe > > On 02/12/2021 23:20, Christopher Barker wrote: > > > >for library authors. > >> Providing high quality stubs and the best user experience is not easy. >> But I believe that referring people to typeshed can help. > > > This is actually very helpful. It provides an answer for open source > projects for which do users want typing. > > One can say to the users that want type stubs for the library that they > are encouraged to contribute those stubs to type shed themselves and once > they have been tested and vetted they can be included in the project. > > it’s not unlike any other feature request. The developer of an open source > project is under no obligation to provide any feature asked for, but a > well-managed project will encourage useful contributions from users. > > -CHB > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to > python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/ASO2PUTECTOB25HC7DURFOGOHOUQOCD5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/7AF22G3S23S67FAHH7BI4XUNHWOU4YXT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RMLBTCYXRWO2EW3XF57422VZHM3EPPJM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python history: origin of the arrow annotation
Haskell and the MLs are older than I am and use "->" to mark their function
types (their functions are curried, but it clearly counts). Given the
overall influence functional languages have had on modern typing, their
influence making itself felt here would be unsurprising.
On Sat, 6 Mar 2021 at 07:47, Antoine Pitrou wrote:
> On Fri, 5 Mar 2021 16:45:25 -0800
> Guido van Rossum wrote:
>
> > Good question. I don't think anyone has ever asked this before... Given
> the
> > variants you propose, I'd say that the 3-character ones would be more
> > effort to type without real benefits, and `=>` would at the time (and
> > perhaps still :-) be seen as too close to `>=`.
> >
> > Could it be that there were already other languages using `->` for return
> > types? I do know that we needed something there -- from the start I was a
> > fan of `x: int` because it's the same as Pascal (the language I used most
> > intensely in college), and if it had been syntactically possible I would
> > have used 'def f(): int' for the return type as well, but the LL(1)
> parser
> > in use in 1999-2000 would interpret that as a very short function body.
> >
> > It's also possible that it comes from the `->` operator in C, which would
> > be the only "ASCII art arrow" that I was familiar with at the time.
>
> Note that nowadays you can use `->` to denote function return types in
> C++ (that was not the case in 1999, though).
> It's also the only allowed style for anonymous functions ("lambdas"):
> https://en.cppreference.com/w/cpp/language/function
> https://en.cppreference.com/w/cpp/language/lambda
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/K75WNUFDLY55FMYY5UID7EEEXWGNJZY3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ULU6EOEKPR7RQQ7VEHICIG6WBKBJ3KOI/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
Caveats: - Any expression (unless you allow reference to variables previously bound by the match statement) can just be aliased (as long as you don’t need short circuiting), so it’s not a critical feature. Constant value patterns are the most easily replaceable by if/elif part of PEP 622. - I’m sure the PEP authors have a better understanding than I of what use cases come up in practice; the fact that they didn’t address this is maybe revealing. - A discussion of allowing expressions in constant value patterns is a slight digression from alternative syntax for constant value patterns and I don’t want to go too deep down the rabbit hole and lose sight of the original question. I think it could be very reasonable to want to use dictionary lookups, especially since a lot of older code / libraries use dicts for enum-like use cases. And arithmetic expressions (outside of powers of 2 and 10): ``` match unit_value: case %(7 * 24 * 60 * 60): return “week” ... ``` And function calls: ``` match hsv_color: case %(hsv(“black”)): ... case %(hsv(“cyan”)): ... case (_, 0, _): return “some sort of grey” match git_bisect_action: case %(config.get_old_term()): ... case %(config.get_new_term()): ... match conn: case %(get_current_conn()): ... case Connection(host, port): ... ``` The caveats above apply, and even if you find the above examples compelling, this would probably fall in the 10 bucket of 90/10 usage. But if our syntax for constant value patterns made it natural / easy to support, it’s something to consider, either now or later a la PEP 614. On Sat, 4 Jul 2020 at 19:15, Chris Angelico wrote: > On Sun, Jul 5, 2020 at 12:03 PM Shantanu Jain > wrote: > > - Finally, I did mention increasing the scope of constant value patterns > to accommodate expressions (as opposed to just dotted names). If we were to > do this, it’s a reason to prefer some syntaxes for constant value patterns > over others. > > > > I'm kinda theoretically in favour of expressions, but only the sort > that logically "feel" like constants. Unary minus and the addition of > real and imaginary parts are already supported, so what's still of > value? IMO exponentiation of 2 is usually better spelled in hex > (instead of 2**10, use 0x400, unless there's good reason), and since > you can have underscores to break up an integer, that handles powers > of 10 as well. What notations would you want to use? > > ChrisA > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/T24W2FZ6UY36CI2GP4LKGBSLSHBYH4K3/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YFGOGWIKXWT3REL335WOR4ZTQMJC7SXL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
Apologies if I misunderstand anything, but my suggestion was just an
alternative to the dot syntax for constant value patterns (which along with
literal patterns are how PEP 622’s proposes to to cover the “more flexible
switch” use case).
This syntax is more verbose than PEP 622’s dot syntax for identifying
constant value patterns, but that’s the intention. A number of messages in
the thread point out that the difference between `case FOO: …` and `case
.FOO: …` is very easy to miss.
There are a couple other proposals for how to identify constant value
patterns (and proposals for having constant value patterns be the default
and capture patterns be the ones explicitly demarcated).
The one suggested the most is `case $FOO: …`. This is less verbose than my
suggestion, but a) it requires introducing a new symbol to Python, b) it
doesn’t correspond to any existing Python syntax, whereas syntax that’s
reminiscent of format strings might build on a shared substitution metaphor
in users’ minds.
The last two lines of my suggestion were just pointing out another
potential reason to prefer this bikeshed over dot syntax (and others
proposed at
https://github.com/python/peps/blob/master/pep-0622.rst#alternatives-for-constant-value-pattern
): if we wanted to extend constant value patterns to match constant
expressions (as opposed to just dotted names), having syntax that uses
delimiters might be more readable than a dot or dollar prefix — at least to
me it’s easier to parse a delimited region to see what part of a pattern
would be matched against literally.
tldr;
- My suggestion was explicitly just bikeshedding syntax for constant value
patterns (the “slightly more flexible switch” part of PEP 622).
- The relative verbosity as compared to dot prefix syntax is meant as a
feature, since it’s very easy to miss the dot
- If you’re a proponent of dot syntax, you won’t see any value in this
suggestion. Given that dot syntax seemed to come up in the thread a fair
amount, and that the PEP calls it the “trickiest item”, I thought it might
be worth suggesting some other options.
- Finally, I did mention increasing the scope of constant value patterns to
accommodate expressions (as opposed to just dotted names). If we were to do
this, it’s a reason to prefer some syntaxes for constant value patterns
over others.
On Sat, 4 Jul 2020 at 16:51, Emily Bowman wrote:
> I don't see how this extrapolates to arbitrary, extended match
> expressions? You're proposing a slightly more flexible switch, which match
> is only intended to be as the most basic case. Even if you purely swapped
> it out with any the various proposals for identifying a constant vs a
> target, it's still far more verbose than any of them.
>
> On Sat, Jul 4, 2020 at 4:31 PM Shantanu Jain
> wrote:
>
>> Thank you for this PEP! Pattern matching is really exciting.
>>
>> As the PEP mentions and the thread evidences, the current dot syntax for
>> the “constant value pattern” is a tricky point. Given this, I thought I’d
>> throw another suggestion into the bikeshed.
>>
>> Use percent placeholder to indicate lookup (or even eval) semantics for a
>> given name. For example:
>> ```
>> FOO = 1
>> value = 0
>>
>> match value:
>> case %(FOO): # This would not be matched
>> ...
>> case BAR:# This would be matched
>> ...
>> ```
>> I like this syntax because it’s reminiscent of named substitution in
>> percent formatted strings. It suggests a substitution / placeholder
>> metaphor that is quite fitting. It has the benefit of not introducing a new
>> symbol into Python and being explicit and hard to miss, including in nested
>> contexts.
>>
>> Note, it seems like it would also be technically possible to use curly
>> braces (the more idiomatic means of named substitution in Python 3):
>> ```
>> case {FOO}: …
>> ```
>> The main downside of this is that it could look like some sort of
>> singleton “set pattern” (note that the PEP only supports “sequence
>> patterns” and “mapping patterns”).
>> (But set patterns maybe don’t quite make sense + if your set pattern had
>> multiple elements you’d still get a SyntaxError. For other examples where
>> something in Python looks like a set literal but isn’t, refer to `{}` and
>> f-strings, so it’s maybe not the biggest stretch)
>>
>> Both of these suggestions could also allow us more flexibility for
>> constant value patterns, since currently there isn't a good way to match
>> against a constant expression. For example, we could extend this syntax to
>> allow us to express:
>> ```
>> case %(2 ** 10): ...
>> ```
>> ___
>> Python-Dev mailing list
[Python-Dev] Re: PEP 622: Structural Pattern Matching
Thank you for this PEP! Pattern matching is really exciting.
As the PEP mentions and the thread evidences, the current dot syntax for
the “constant value pattern” is a tricky point. Given this, I thought I’d
throw another suggestion into the bikeshed.
Use percent placeholder to indicate lookup (or even eval) semantics for a
given name. For example:
```
FOO = 1
value = 0
match value:
case %(FOO): # This would not be matched
...
case BAR:# This would be matched
...
```
I like this syntax because it’s reminiscent of named substitution in
percent formatted strings. It suggests a substitution / placeholder
metaphor that is quite fitting. It has the benefit of not introducing a new
symbol into Python and being explicit and hard to miss, including in nested
contexts.
Note, it seems like it would also be technically possible to use curly
braces (the more idiomatic means of named substitution in Python 3):
```
case {FOO}: …
```
The main downside of this is that it could look like some sort of singleton
“set pattern” (note that the PEP only supports “sequence patterns” and
“mapping patterns”).
(But set patterns maybe don’t quite make sense + if your set pattern had
multiple elements you’d still get a SyntaxError. For other examples where
something in Python looks like a set literal but isn’t, refer to `{}` and
f-strings, so it’s maybe not the biggest stretch)
Both of these suggestions could also allow us more flexibility for constant
value patterns, since currently there isn't a good way to match against a
constant expression. For example, we could extend this syntax to allow us
to express:
```
case %(2 ** 10): ...
# or
case {get_default()}: ...
```
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/Y4I4PO3VFRYAJUAW2JXA4IYVN7NZMTDQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
Thank you for this PEP! Pattern matching is really exciting.
As the PEP mentions and the thread evidences, the current dot syntax for
the “constant value pattern” is a tricky point. Given this, I thought I’d
throw another suggestion into the bikeshed.
Use percent placeholder to indicate lookup (or even eval) semantics for a
given name. For example:
```
FOO = 1
value = 0
match value:
case %(FOO): # This would not be matched
...
case BAR:# This would be matched
...
```
I like this syntax because it’s reminiscent of named substitution in
percent formatted strings. It suggests a substitution / placeholder
metaphor that is quite fitting. It has the benefit of not introducing a new
symbol into Python and being explicit and hard to miss, including in nested
contexts.
Note, it seems like it would also be technically possible to use curly
braces (the more idiomatic means of named substitution in Python 3):
```
case {FOO}: …
```
The main downside of this is that it could look like some sort of singleton
“set pattern” (note that the PEP only supports “sequence patterns” and
“mapping patterns”).
(But set patterns maybe don’t quite make sense + if your set pattern had
multiple elements you’d still get a SyntaxError. For other examples where
something in Python looks like a set literal but isn’t, refer to `{}` and
f-strings, so it’s maybe not the biggest stretch)
Both of these suggestions could also allow us more flexibility for constant
value patterns, since currently there isn't a good way to match against a
constant expression. For example, we could extend this syntax to allow us
to express:
```
case %(2 ** 10): ...
```
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/YQUCFREQ2P7NENOTPBE277I3BZ6DGXSR/
Code of Conduct: http://python.org/psf/codeofconduct/
