On 09/18/2010 06:56 PM, Seebs wrote:
On 2010-09-18, Steven D'Aprano<st...@remove-this-cybersource.com.au> wrote:
On Fri, 17 Sep 2010 16:01:54 -0400, Andreas Waldenburger wrote:
On Thu, 16 Sep 2010 16:20:33 -0400 AK<andrei....@gmail.com> wrote:
I also like this construct that works, I think, since 2.6:
code = dir[int(num):] if side == 'l' else dir[:-1*int(num)]
I wonder when this construct will finally start to look good.
It looks good to me. It follows a common English idiom:
"What are you doing tonight?"
"I'll be going to the movies, if I finish work early, otherwise I'll stay
home and watch a DVD."
I hate that idiom in English, too. If you're going to give me a forking
conditional, I want to know about it early.
Basically, I can handle
do x if y
pretty well, but
do x if y else z
always breaks my parser.
So in English, I might say "I'll go to the store if I have time", but
I'd rarely use "I'll go to the store if I have time, otherwise I'll send
the house elf"; instead, I'd say "If I have time, I'll go to the store,
otherwise I'll send the house elf."
-s
I actually find the shorter version slightly more readable than full
version. I think in English you'd say it in one sentence and that to me
feels like it should vaguely correspond to one line in code (perhaps
split over more than one line but that'd be due to long var names or
complex operations, not inherently).
The longer version may be like saying "I'll go to the store. If I have
time. If I don't have time. I will send the house elf."
It's a bit more readable to me because I can tell at a glance that a
single variable gets assigned a value based on a condition. With a
longer version it looks like something more complicated it going on, and
the eye has to look at all four lines and jump to another ident level.
By the way, it also looks far more readable in an editor where if and
else would be highlighted vs. all in plain colour.
-ak
--
http://mail.python.org/mailman/listinfo/python-list
