On Sun, Apr 15, 2018 at 6:58 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> On Sun, Apr 15, 2018 at 10:21:02PM +1000, Chris Angelico wrote:
>
>> I don't think we're ever going to unify everyone on an arbitrary
>> question of "expression first" or "name first". But to all the
>> "expression first" people, a question: what if the target is not just
>> a simple name?
>>
>> while (read_next_item() -> items[i + 1 -> i]) is not None:
>> print("%d/%d..." % (i, len(items)), end="\r")
>
> I don't see why it would make a difference. It doesn't to me.
>
>
>> Does this make sense? With the target coming first, it perfectly
>> parallels the existing form of assignment:
>
> Yes, except this isn't ordinary assignment-as-a-statement.
>
> I've been mulling over the question why I think the expression needs to
> come first here, whereas I'm satisfied with the target coming first for
> assignment statements, and I think I've finally got the words to explain
> it. It is not just long familiarity with maths and languages that put
> the variable first (although that's also part of it). It has to do with
> what we're looking for when we read code, specifically what is the
> primary piece of information we're initially looking for.
>
> In assignment STATEMENTS the primary piece of information is the target.
> Yes, of course the value assigned to the target is important, but often
> we don't care what the value is, at least not at first. We're hunting
> for a known target, and only when we find it do we care about the value
> it gets.
>
... [SNIP] ....
>
> It is appropriate for assignment statements and expressions to be
> written differently because they are used differently.
>
Wow. That feeling when you see someone giving reasonable
arguments but in the end comes up with such doubtful conclusions.
So you agree that in general you may need to spot values
and in other case function calls or expressions.
And that's it, its just depends.
So if you swap the order and in some _single_ particular
case you may notice tiny advantage, you conclude that
the whole case with expression assignment needs this order.
Lets just return to some of proposed examples
(I use "=" in both examples to be less biased here):
1.
if ( match = re.match("foo", S) ) == True:
print("match:", match)
2.
if ( re.match("foo", S) = match ) == True:
print("match:", match)
Now seriously, you may argue around those "pronounce"
theoretical bla bla, like "take the result and save it in a token".
But the variant 1. is just better, because _it is what it is in Python_.
So it is better not because it is better looking or whatever,
it is same sh** turned around. So just don't turn it around!
Here the 1st variant can be unwrapped to:
match = re.match("foo", S)
if match == True:
print("match:", match)
Do you see what I mean?
When I read code I don't have all those things
you describe in a millisecond :
- look at the pointy end of operator
- think, oh this shows to the right
- seems like I save the value there
- yep, that's the way I imply things to work
- stroking the belly
....
Instead I just parse visually some smaller parts
of code and it's just better if the assignment is in the same
order as everywhere.
Yes, in some single case one order can look better,
but in this case it's just not good to mix those.
Mikhail
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
