There have been a number of comments in this thread, and some slight
variations in the idea.
I'm afraid that it all looks awkward to me, so far. I understand trying to
work out the smallest change that would allow the style, but it just feels
"bolted on" in a bad way.
I believe that if Python get
This is very cool, well thought-out, and solves an important problem. I
would have definitely benefited from Python having better pattern matching.
As an idealist though, if you're going to add pattern matching, why not
just do it completely? I agree that your proposal would be useful in some
> On Jan 2, 2020, at 18:34, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com>
> wrote:
>
> On 1/2/20 3:07 PM, Random832 wrote:
>> On Thu, Jan 2, 2020, at 13:22, Dan Sommers wrote:
>
>>> What about "if except" (any time I can eliminate a "not," that's a
>>> good thing):
>> ... is this meant to be
On 1/2/20 3:07 PM, Random832 wrote:
> On Thu, Jan 2, 2020, at 13:22, Dan Sommers wrote:
>> What about "if except" (any time I can eliminate a "not," that's a
>> good thing):
>
> ... is this meant to be for the doesn't-throw case or does-throw? ...
>>
>> if except x:
>> y
That would
On Thu, Jan 2, 2020, at 13:22, Dan Sommers wrote:
> What about "if except" (any time I can eliminate a "not," that's a good
> thing):
wait, is this meant to be for the doesn't-throw case or does-throw? how are we
eliminating the not?
> if except x:
> y
>
> which could even leave r
On 1/2/20 12:55 PM, Andrew Barnert via Python-ideas wrote:
> On Jan 2, 2020, at 06:32, Random832 wrote:
>> Mainly, you had mentioned you felt like "if try" had a 'smell' to it
>> but couldn't figure out what it is, and I was trying help identify
>> that, and... well, after thinking about it mor
On Jan 2, 2020, at 06:32, Random832 wrote:
>
> Mainly, you had mentioned you felt like "if try" had a 'smell' to it but
> couldn't figure out what it is, and I was trying help identify that, and...
> well, after thinking about it more, I realized - "if try" may not have many
> uses, but "if no
On Wed, Jan 1, 2020, at 21:49, Andrew Barnert wrote:
> On Jan 1, 2020, at 13:23, Random832 wrote:
> >
> > Neither of these constructs seems to be particularly useful outside the
> > other one,
>
> Yes, and you already quoted me as saying that.
I think I read "not proposing them separately" as
On Jan 1, 2020, at 13:23, Random832 wrote:
>
> Neither of these constructs seems to be particularly useful outside the other
> one,
Yes, and you already quoted me as saying that.
> which suggests to me they should not be orthogonal in the way you have
> proposed. Is there a good reason for wa
> On Jan 1, 2020, at 08:32, Guido van Rossum wrote:
>
> Here's a proposal for JavaScript that seems to be going through
> standardization: https://github.com/tc39/proposal-pattern-matching
The JS solution is interesting, but I’m not sure how well it works for a
different language. Python is c
On Jan 1, 2020, at 07:03, Steven D'Aprano wrote:
>
> On Tue, Dec 31, 2019 at 02:28:26PM -0800, Andrew Barnert via Python-ideas
> wrote:
>
>>if try 0, y, z := vec:
>># do yz plane stuff
>>elif try x, 0, z := vec:
>># do xz plane stuff
>>elif try x, y, 0 := vec:
>>
>> On Jan 1, 2020, at 04:21, Steven D'Aprano wrote:
>>
>> On Tue, Dec 31, 2019 at 05:18:59PM -0800, Andrew Barnert via Python-ideas
>> wrote:
>>
>> Some languages use special syntax to mark either values or targets:
>> let x, K, let z = vec
>> x, @K, z = vec
>> But the simplest solution is t
On Dec 31, 2019, at 21:35, Guido van Rossum wrote:
>
> There were match proposals in the past — have you looked those up? Maybe they
> solve your problem without that syntax — or maybe they would benefit from it.
Most of the existing proposals require a lot more syntax—a new form using two
or
On Tue, Dec 31, 2019, at 22:18, Andrew Barnert via Python-ideas wrote:
> I’m just feeling out whether either one is so horrible that any larger
> proposal (which I don’t have in anywhere near ready-to-share form yet)
> would have to be rejected on that basis. (Which I think is a serious
> possib
Here's a proposal for JavaScript that seems to be going through
standardization: https://github.com/tc39/proposal-pattern-matching
Here's the end of an older python-ideas thread:
https://mail.python.org/archives/search?mlist=python-ideas%40python.org&q=pattern+matching+reprise
On Tue, Dec 3
On 1/1/20 10:02 AM, Steven D'Aprano wrote:
# Fail() is a function that raises an exception;
# __ is a special predefined Pattern that always matches.
result = match(vec, # object to match
Pattern(0, 'y', 'z'), handle_yz,
Pattern('x', 0, 'z'), handle
On Tue, Dec 31, 2019 at 02:28:26PM -0800, Andrew Barnert via Python-ideas wrote:
> if try 0, y, z := vec:
> # do yz plane stuff
> elif try x, 0, z := vec:
> # do xz plane stuff
> elif try x, y, 0 := vec:
> # do xy plane stuff
> elif x, y, z := vec:
>
On Tue, Dec 31, 2019 at 05:18:59PM -0800, Andrew Barnert via Python-ideas wrote:
> Some languages use special syntax to mark either values or targets:
>
> let x, K, let z = vec
> x, @K, z = vec
>
> But the simplest solution is to nothing: you have to stick it in an
> expression that isn
>
>
> class MatchType(type):
> def __eq__(self, other):
> return self == type(other)
>
> Or I even want to match:
>
> type[int], y < 42, z = vec
>
> Well, I can’t think of a language where you can actually match that way.
> That doesn’t necessarily mean we should disallo
There were match proposals in the past — have you looked those up? Maybe
they solve your problem without that syntax — or maybe they would benefit
from it.
On Tue, Dec 31, 2019 at 19:20 Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> Let me make this bit a little clearer:
>
>
Let me make this bit a little clearer:
> On Dec 31, 2019, at 17:54, David Mertz wrote:
>
> So your syntax gets me maybe 20% of what I'd want to do if we had pattern
> matching.
I’m not proposing either of these changes in its own, because I don’t have any
use for either one on its own. (Or fo
On Dec 31, 2019, at 17:54, David Mertz wrote:
>
>
>> On Tue, Dec 31, 2019 at 8:23 PM Andrew Barnert via Python-ideas
>> wrote:
>
>> > K = 42
>> > x, K, z = vec
>> Yes. I’m surveying the way other languages deal with this to try to figure
>> out what might fit best for Python.
>> Some langua
On Tue, Dec 31, 2019 at 8:23 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> > K = 42
> > x, K, z = vec
> Yes. I’m surveying the way other languages deal with this to try to figure
> out what might fit best for Python.
> Some languages use special syntax to mark either value
On Dec 31, 2019, at 15:52, Greg Ewing wrote:
>
> On 1/01/20 11:28 am, Andrew Barnert via Python-ideas wrote:
>
>> The first is to extend unpacking assignment to target-or-expression lists.
>> Like this:
>>x, 0, z = vec
>> But
>> it doesn’t bind anything to the second element; instead, it c
On 1/01/20 11:28 am, Andrew Barnert via Python-ideas wrote:
The first is to extend unpacking assignment to target-or-expression lists. Like
this:
x, 0, z = vec
But
it doesn’t bind anything to the second element; instead, it checks if
that element is 0, and, if not, raises a ValueError.
On Dec 31, 2019, at 14:58, Soni L. wrote:
>
>
>> On 2019-12-31 7:28 p.m., Andrew Barnert via Python-ideas wrote:
>>
>> The second is an “if try” statement, which tries an expression and runs the
>> body if that doesn’t raise (instead of if it’s truthy), but jumps to the
>> next elif/else/stat
On 2019-12-31 7:28 p.m., Andrew Barnert via Python-ideas wrote:
Every so often, someone suggests that Python should have a pattern matching
case statement like Scala, C#, Swift, Haskell, etc. Or they just suggest that
“Python needs algebraic data types” but end up concluding that the biggest
To make things a little more concrete (still without actually defining the
library or searching for better motivating examples), here’s a slightly
rewritten example from the Scala tutorial:
def showNotification(notification: Notification) = {
notification match {
case Ema
28 matches
Mail list logo
