←back to thread

317 points est | 8 comments | | HN request time: 1.819s | source | bottom
Show context
gbfowler ◴[] No.17448582[source]
It is not syntactic sugar, "x := 10" is an assignment expression in contrast with "x = 10", which is a statement.

Hence the former can be used in contexts like "if x := 10: pass", which is the whole point of the PEP.

replies(2): >>17448624 #>>17448651 #
Aardwolf ◴[] No.17448624[source]
Why is it not syntactic sugar? It looks like convenience. You could argue everything above machine language is syntactic sugar.
replies(5): >>17448721 #>>17448736 #>>17448847 #>>17448880 #>>17448984 #
cup-of-tea ◴[] No.17448880[source]
Synactic sugar means the same thing can be achieved without the sugar. How could you achieve this without the new expression?
replies(1): >>17448901 #
est ◴[] No.17448901[source]
by writing extra lines?

I'd prefer more lines for readability reasons.

replies(2): >>17448929 #>>17449056 #
1. cup-of-tea ◴[] No.17448929[source]
How would you do this?

    if (match := re.match(r1, s)):
        o = match.group(1)
    elif (match := re.match(r2, s)):
        o = match.group(1)
replies(2): >>17449096 #>>17449827 #
2. PurpleRamen ◴[] No.17449096[source]

    match = re.match(r1, s)
    if match:
        o = match.group(1)
    else:
        match = re.match(r2, s)
        if match:
            o = match.group(1)
or a bit shorter:

    match = re.match(r1, s)
    if not match:
        match = re.match(r2, s)
    if match:
        o = match.group(1)
You could also just loop:

    for pattern in (r1, r2, ...):
        match = re.match(pattern, s)
        if match:
            o = match.group(1)
            break
    else:
        do_failure_handling()
But this goes a bit beyond the original question.
replies(1): >>17449950 #
3. est ◴[] No.17449827[source]
well, that looks easy.

    m = re.match(r1, s) or re.match(r2, s)
    o = m.group(1) if m else None
replies(1): >>17449896 #
4. cup-of-tea ◴[] No.17449896[source]
I made a mistake in my question. The arguments to group shouldn't have been the same. What I want to get at is when the two branches are completely different code.
replies(1): >>17454693 #
5. cup-of-tea ◴[] No.17449950[source]
I made a mistake in the question, it should have been:

    if (match := re.match(r1, s)):
        o = match.group(1)
        # plus some code here
    elif (match := re.match(r2, s)):
        o = match.group(2)
        # plus some other code here
In this case only your first solution works, I think. Leaving aside that having those deeply nested ifs is incredibly ugly, I find it hard to accept that something which completely changes the possible structure of the code is just "syntactic sugar".
replies(2): >>17450207 #>>17455182 #
6. PurpleRamen ◴[] No.17450207{3}[source]
It's the syntactic sugars job to beautify the ugly. And your example is also a bit unfair, because you also use another syntactic sugar, the elif, to make it more beautyful. It only falls back to the ugly solution because I can't sweeten sugar for a similar dish.

But the overall question is: when is the sugar just syntactical, and at what point does it become a complete new taste?

7. est ◴[] No.17454693{3}[source]
I think it's a case where PEP 572 tries to fix bad library design.

re.match shouldn't return None at all. I often write helper functions like:

    matcher = lambda r, s: getattr(re.match(r, s), 'group', lambda i: '')
    o = matcher(r1, s)(1) or matcher(r2, s)(3)
here matcher have a fixed, static return type, string.
8. Demiurge ◴[] No.17455182{3}[source]
Why is it incredibly ugly when it actually conveys the explicit logic of that which is happening? Can the logic be simplified? Are there any unnecessary characters? I don't see that. This is why I like Python, it's easy to read, and it is easy to refactor and see how you can improve the logic.