two ideoms at one blow: line-reading and regexp-matching

Paul Rubin phr-n2002a at nightsong.com
Wed Feb 20 20:54:53 EST 2002


Gustavo Cordova <gcordova at hebmex.com> writes:
> Now *THIS*:
> >    while (m := re.match(pat,x)):  blah()
> Indeed, this is very readable. The ":=" asignment operator
> is used in Pascal, if I remember correctly; another language
> where you can't assign inside an expression.

OK.  It still blurs the statement/expression distinction, but now
there's no longer anything wrong with it?

> But it only feels contorted, to you. To me it feels quite
> natural:
> 
> 	1. Set up the loop conditions and variables.
> 	2. Do the loop.
> 	3. Exit the loop.

What you and I see as contorted are not necessarily the same.
The language should not impose a choice on either of us over
something like this.

> Yes, your ":=" suggestion is valid, and it removes the "=/=="
> readability / typo reason. But if it's not there, and if
> the people maintaining your code are going to get all huffy
> because it's "spelled out" instead of being in a compact
> form, then the problem is another, and not the language.

I'm saying the =/== objection is bogus because it can be fixed
easily with := or something similar.  With =/== fixed, is there
any remaining objection?

> Then again, maybe all the newbies used other languages
> which feature the assignment / expression duality. Also,
> this "limitation" (of not allowing assignments in expressions)
> is clearly expressed in the docs, which means that newbies
> nowadays are simply NOT reading the documentation before
> launching into new waters. That severely downgrades the
> quality of the questions they might pose, no?

That's silly.  If the language for some reason didn't recognize the
digit 3 (you could still say x=2+1 if you wanted to assign 3 to x) and
the restriction was documented, people would still ask why there was
no 3 in the language.  Saying the questioners should just read the
documentation is unproductive.  They come to the language with the
expectation that if you can say x=2 or x=4, then you should also be
able to say x=3.  If enough people keep asking the same question,
maybe the expectation is ok and it's the language (and documentation)
that need fixing.

> Just count how many times the "static vs dynamic typing" thread has
> reappeared, it just won't die. And it's always *another* newbie
> which comes in and asks the same question, instead of learning,
> slowly, breathing calmly, how to best use this shiny new tool.

That's a somewhat different situation which needs a deeper type of
answer.  

> I'm sure that it'll keep evolving, it needs to. But there's
> something inherently *nice* which comes into play when
> the code's all spelled out, doing the clearest thing
> possible, which just isn't there in Lisp, C, C++, etc.
> 
> Anyway, it's just my opinion. :-)

Yes, it's subjective--I personally prefer concise code, in that I
often prefer using an assignment or embedded conditional inside an
expression rather than using several statements, but I don't claim
it's objectively better than doing it the other way.  

More than anything else, readability is a matter of opening your mind
to other programmers through the code that you write, not really a
technical matter but almost a spiritual one.  The best programming
language is the one you're not even aware that you're using--your code
just naturally reflects your thoughts.  Python does a pretty good job
in most respects of not getting in the way of expressing what you're
thinking, but it has certain shortcomings, mostly from when it tries
to impose its own notions of readability on programmers who know what
they're doing.  



More information about the Python-list mailing list