Christian Tismer wrote:
> Dear community,
>
> there has been some favor of my silly/simple a then b else c proposal.
>
> Please let me elaborate a little on this, with respect
> to the existing "and" and "or operators.
>
> "and" and "or" are two-headed beasts:
> At first glance, they pretend to be logical operators.
> At second inspection, they do this logic by promoting
> one of their operands.
>
> This is not obviously bad, and it is consistant with the logic.
>
> Due to the presence of a real boolean type, we
> should ask ourselves if "and" and "or" shouldn't be
> deprecated in their current meaning, towards being
> "boolean only"?
You are forgetting a detail here: "and" as well as "or"
are not implemented as operators. "&" and "|" are the
boolean operators and these do return boolean values.
Note that you can't do "true" | "false" and then get "true"
as result. What you get is a TypeError.
"and" and "or" are control structures which test for
truth values and then branch accordingly, leaving
the true result on the stack.
Constructs misusing "and" and "or" for the sake of
inlining if-then-else should be reserved for those
who know what they're doing (and can live with the
consequences). Everybody else should really stick to
the explicit:
# value = x ? a : b
if x:
value = a
else:
value = b
This is clean, shows exactly what you're doing and doesn't
hide the flow of control from the reader: value = a is only
executed in case x is found true. In that case the value = b
branch is never entered into. As a result, side-effects
in the value = b branch do not take effect.
--
The tendency to let inling features creep into the language
makes me a little nervous. The simplicity of Python is
losing big with each new way to put more information
on one line. This can be compared to lossy compression
of an image: you can still grasp the general picture, but
the details become unsharp and distored.
Complexity should be reserved to what you write, not
how you write it.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Feb 14 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 46 days left
EuroPython 2003, Charleroi, Belgium: 130 days left
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4