undefined | Better HN

0 pointsthaumasiotes6y ago0 comments

Read it "if y" - that's what's being tested.

The walrus simultaneously names the value being tested so you can refer to it within the condition; it's sort of the inverse of Perl code using $_. So instead of

    if (do_something()) {
        act_on($_);
    }

you have

    if placeholder := do_something():
        act_on(placeholder)

But when reading aloud, however you'd read the perl will flow as more natural english. "If the string contains z, do something with it".

If you really want to read the Python as it's written, it corresponds to the second of these sentences:

- If the substring from 3 to 5 is "fg", crash.

- If variable_name, the substring from 3 to 5, is "fg", crash.

0 comments

txcwpalpha6y ago

>Read it "if y" - that's what's being tested.

Once way to test if this works is to take the code, read it aloud, and then use the read-aloud version to rewrite the code. If you don't have a high degree of certainty that you end up with the same code, something has failed along the way.

In this case, if I take "if x:= y()" and read it aloud as "if y", I think the vast majority of people would translate that to code as "if y():", which isn't the same thing.

thaumasiotesOP6y ago

You will end up with the same code under two conditions:

1. You read more than one line of code.

2. Executing the code in the conditional more than once doesn't matter.

If you meet those two assumptions, then the reading I suggested will transform this

    if x := y():
        act_on(x)

into this

    if y():
        act_on(y())

which is, in fact, the same thing.

txcwpalpha6y ago

That second point is quite an assumption to make. If it's okay to end up with the second one of your examples (without the ":=" operator), why did we need to add the walrus opeprator at all?

And if you're referring to this statement from your original comment:

> If variable_name, the substring from 3 to 5, is "fg", crash.

I don't find this to be a clear statement at all. If I read this aloud to any of my programming students, I doubt any of them would be able to decipher it into any code, let alone the code string which you've suggested.

1 more reply

shakna6y ago

There's absolutely no guarantee that two calls to y result in the same value.

Even if y isn't mutating itself, it may be calling from a database updated from another thread.

You end up storing the value. The walrus simplifies the code.

j / k navigate · click thread line to collapse

0 comments

txcwpalpha6y ago

>Read it "if y" - that's what's being tested.

In this case, if I take "if x:= y()" and read it aloud as "if y", I think the vast majority of people would translate that to code as "if y():", which isn't the same thing.

thaumasiotesOP6y ago

You will end up with the same code under two conditions:

1. You read more than one line of code.

2. Executing the code in the conditional more than once doesn't matter.

If you meet those two assumptions, then the reading I suggested will transform this

    if x := y():
        act_on(x)

into this

    if y():
        act_on(y())

which is, in fact, the same thing.

txcwpalpha6y ago

That second point is quite an assumption to make. If it's okay to end up with the second one of your examples (without the ":=" operator), why did we need to add the walrus opeprator at all?

And if you're referring to this statement from your original comment:

> If variable_name, the substring from 3 to 5, is "fg", crash.

1 more reply

shakna6y ago

There's absolutely no guarantee that two calls to y result in the same value.

Even if y isn't mutating itself, it may be calling from a database updated from another thread.

You end up storing the value. The walrus simplifies the code.

j / k navigate · click thread line to collapse