[Python-ideas] Re: PEP Idea: native f-string support as a match pattern

2022-08-23 Thread Lucas Wiman
On Sat, Aug 13, 2022 at 10:23 AM Tushar Sadhwani < tushar.sadhwani...@gmail.com> wrote: > Stephen J. Turnbull wrote: > > I think this is a pretty unconvincing example. While people seem to > > love to hate on regular expressions, it's hard to see how that beats > > def unquote(string: str) -> str

[Python-ideas] Re: PEP Idea: native f-string support as a match pattern

2022-08-13 Thread Tushar Sadhwani
Stephen J. Turnbull wrote: > I think this is a pretty unconvincing example. While people seem to > love to hate on regular expressions, it's hard to see how that beats > def unquote(string: str) -> str: > m = re.match(r"^(?:"(.*)"|'(.*)'|(?Pvalue3))$", string) RegEx feels overkill for thi

[Python-ideas] Re: PEP Idea: Better return type annotation syntax

2022-01-16 Thread Tushar Sadhwani
Jelle Zijlstra wrote: > > I like this too. A practical issue is that list[(a, b)] and list[a, b] look > the same to the compiler, but they would mean very different things. It's > not obvious how to fix this in a backward-compatible way. > > I think it looks much cleaner, and if there isn't any dra

[Python-ideas] Re: PEP Idea: Better return type annotation syntax

2022-01-06 Thread Jelle Zijlstra
On Thu, Jan 6, 2022 at 10:44 PM Tushar Sadhwani < tushar.sadhwani...@gmail.com> wrote: > With the recent submission of [PEP 677][1], I was reminded of an idea I > had with function annotation syntax since the very beginning: > > why not let me write: > > ```python > def f() -> tuple[int, str]: >

[Python-ideas] Re: PEP Idea: Matching Exceptions with 3.10's Structural Pattern Matching Syntax

2022-01-03 Thread elvis kahoro
Thanks for the feedback everyone. I've only encountered the use case once, like you've mentioned it's probably not worth the effort given that it's such a small problem space. Thanks again! On Tue, Jan 4, 2022, 00:18 Steven D'Aprano wrote: > On Mon, Jan 03, 2022 at 11:31:30PM -0500, elvis kah

[Python-ideas] Re: PEP Idea: Matching Exceptions with 3.10's Structural Pattern Matching Syntax

2022-01-03 Thread Steven D'Aprano
On Mon, Jan 03, 2022 at 11:31:30PM -0500, elvis kahoro wrote: > I was hoping there could be some syntax to extend pattern matching to > handle exceptions such that we could handle patterns with multiple types of > exceptions like so: > > match *this_raises_an_exception*, *this_raises_another_exce

[Python-ideas] Re: PEP Idea: Matching Exceptions with 3.10's Structural Pattern Matching Syntax

2022-01-03 Thread Chris Angelico
On Tue, Jan 4, 2022 at 3:32 PM elvis kahoro wrote: >> >> Reading between the lines, I *think* that you want the match statement >> to catch the exception that you get when the attribute lookup fails, am >> I right? > > Yes! > > I was hoping there could be some syntax to extend pattern matching to

[Python-ideas] Re: PEP Idea: Matching Exceptions with 3.10's Structural Pattern Matching Syntax

2022-01-03 Thread elvis kahoro
> > Reading between the lines, I *think* that you want the match statement > to catch the exception that you get when the attribute lookup fails, am > I right? Yes! I was hoping there could be some syntax to extend pattern matching to handle exceptions such that we could handle patterns with mult

[Python-ideas] Re: PEP Idea: Matching Exceptions with 3.10's Structural Pattern Matching Syntax

2022-01-03 Thread Stephen J. Turnbull
Steven D'Aprano writes: > I propose: > > match expression: > except exceptions: > block > # regular cases follow after the except block I probably would rarely use this syntax (preferring the explicit temporary, and possibly encapsulating the exception handl

[Python-ideas] Re: PEP Idea: Matching Exceptions with 3.10's Structural Pattern Matching Syntax

2022-01-03 Thread Steven D'Aprano
Hi Elvis, On Sat, Jan 01, 2022 at 12:59:32AM -0500, elvis kahoro wrote: > The functionality that I'm thinking about is: > > match (named_tuple_object.*missing_attribute*, a_random_string): > case *AttributeError*, "Catching an attribute error": > print("Catches as attribute error")

[Python-ideas] Re: PEP idea

2021-08-15 Thread Guido van Rossum
That's proposed in PEP 645 (https://www.python.org/dev/peps/pep-0645/). Personally I think it's not necessary, we should just write MyType | None. (Yes, this is directly from TypeScript.) On Sun, Aug 15, 2021 at 6:10 AM Will Bradley wrote: > Hi all, > > As of 3.10 (PEP 604) we've gotten syntacti

[Python-ideas] Re: PEP idea

2021-08-15 Thread Thomas Grainger
You can use `T | None` ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/arch

[Python-ideas] Re: PEP idea

2021-08-15 Thread Thomas Grainger
Any has the same number of characters as All ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https:

[Python-ideas] Re: PEP idea

2021-08-15 Thread James Oldfield
Kathiri Sent: 15 August 2021 19:29 To: Joren Hammudoglu Cc: python-ideas@python.org Subject: [Python-ideas] Re: PEP idea +1 I like it, anything to get rid of Optional[type] is good. If we can replace Callable[[type1], type2] with (type1) -> type2 and typing.Any with just soft keyword “

[Python-ideas] Re: PEP idea

2021-08-15 Thread Abdulla Al Kathiri
+1 I like it, anything to get rid of Optional[type] is good. If we can replace Callable[[type1], type2] with (type1) -> type2 and typing.Any with just soft keyword “All”, type annotations will be fun! Sent from my iPhone > On 15 Aug 2021, at 8:41 PM, Joren Hammudoglu wrote: > >  > See https:

[Python-ideas] Re: PEP idea

2021-08-15 Thread Joren Hammudoglu
See https://www.python.org/dev/peps/pep-0645/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https