On Nov 10, 2:08 pm, Robert Latest <boblat...@yahoo.com> wrote:
(..snip..)
> Also it's not the "if" that is (if at all) redundant here but the assignment.
Not exactly. The assignment happens only once just as the boolean
check of "if <value>" happens once. The redundancy is in validating
the existence of a truthful value contained in a variable after
assignment of a value to that same variable. It's like putting on your
tennis shoes and then asking yourself 'am i wearing tennis shoes?'. Of
course we all know *why* we must verify the existence of value
afterward and the shoe analogy doesn't translate 1:1 to programming.
It's more like...
shoes = grab_a_pair_of_shoes_or_none_and_apply_to_feet()
if shoes:
shoes.this()
shoes.that()
Now did we find a pair of shoes or did we fail because the lights were
out and all we accomplished was to toil around in the closet for half
an hour bumping our head before finally giving up and returning empty
handed?
Just thinking out loud here...what if variable assignments could
return a value... hmmm? Not to them selfs of course but to a caller,
like an if statement...
if a=openfile:
# do something with a
(if(a.__eq__(openfile)))
Python would need to stuff the value of openfile into "a", then add
the variable "a" to the proper namespace, then evaluate if "a" is
True. This would read more naturally than even my first postulation. I
bet it would confuse the crap out of noobies though!
So basically with the new syntax what your saying is this:
if the value of this expression bools to False, toss it away because i
don't need it, else assign the value to a local variable and run the
block. Basically your encaspulating an if..else block in one line of
code.
--
http://mail.python.org/mailman/listinfo/python-list
