(PEP-308) Python's Conditional Selection Operators

[Stephen Horne]

On Sun, 16 Feb 2003 00:24:56 +0000, Gareth McCaughan
<Gareth.McCaughan at pobox.com> wrote:

>Stephen Horne wrote:
>
>>  On Fri, 14 Feb 2003 18:34:32 -0800, Erik Max Francis <max at alcyone.com>
>>  wrote:
>>  
>> > You say "standard versions" but there is no such thing in the realm of
>> > computer science.  Python's and/or operators behave just like Lisp's,
>> > for example, and Lisp has been around a very long time.
>>  
>>  But lisp has never been a defining standard for all programming
>>  languages. It is quirky and somewhat different from anything in
>>  programming that could be called a standard.
>
>On the contrary: Common Lisp was, for instance, the first object-oriented
>language to have an ANSI standard. :-) Yes, I know, you don't really
>mean "standard", you mean "average". Well, if it comes to that, Python
>isn't "standard" either. It's easy to write and easy to read, for instance;
>those characteristics aren't "standard", alas.

I still do upwards of 90% of my development in C++ (sadly) so that is
one statement I absolutely agree with.

Are you sure common lisp is object oriented? - It's a bit of a
surprise if it is. As I recall, the whole point of xlisp was to add
object oriented features to lisp.

>>                                               For example, it is often
>>  referred to as a functional language because it supports functions as
>>  first class objects even though it is clearly an imperative language
>>  in most ways with side effects all over the place - so it doesn't even
>>  fit with the standard expectations of a single class of programming
>>  language.
>
>Ah, yes, providing the facilities needed to program in functional
>style when appropriate as well as those needed to program in
>imperative style when appropriate. Terrible, that. Certainly
>non-standard. And, of course, a million miles away from anything
>in Python. It wouldn't do to think about such a language in
>connection with Python, would it?

It's one of the features I *like* about Python, in fact.

You seem to think I was attacking LISP, or the that I was attacking
the selective 'and' and 'or' operators. I was not. I was speaking up
for Terry after he was attacked for using the everyday meaning of the
word "standard", plus waffling on a bit because I couldn't sleep and
was bored.

>>  As for the syntax, it is best compared with forth and miranda - all
>>  three are obsessed with one syntactic construct (forth has postfix
>>  operators, miranda has prefix operators, lisp has Lots of
>>  Infuriatingly Stupid Paretheses. Important, yes. Powerful, yes.
>>  Standard (as in conventional), no.
>
>Ah, yes. We shouldn't consider the semantics of Lisp as any
>sort of precedent, because it uses unusual syntax. Yup, that
>sure makes a lot of sense.

What? - we don't need a precedent for adding selective 'and' and 'or'
as we already have them! And WHEN DID I CRITICISE LISPS SEMANTICS???

Erik criticised Terry's use of the word 'Standard' and cited LISP in a
way that implied LISP defined a standard others have to follow. I
wanted to point out that LISP is *not* a standard.

LISP is not famous for its readability or ease of use. It is famous
for being powerful and for setting precedents in terms of the
available facilities that have influenced many languages - and for
good reason - but that doesn't mean that the LISP syntax is the best
possible model or a definitive standard to follow.

When LISP was invented, the complexity of computer language parsing
was a major concern when developing a language. It was worthwhile
having a awkward (for humans) syntax if that meant the parsing was
easier. Today, the most important thing is whether human readers can
'parse' the language.

But I would never argue that LISPs *semantic* features were a bad
precendent. And I never did. Python has the selective 'and' and 'or'
operators, and I would never suggest taking them out. I've used the
and/or idiom just like many other people, and I really don't want my
code to break. However, when they are used to mimic a conditional
expression, they simply aren't readable. They made sense in LISP, but
in readability and reliability terms they can certainly be improved
upon in Python.

The fact that LISP fits neither the 'standard' form of imperative nor
functional languages is just that - a simple fact. Not a judgement.
This thread has already seen one person reading value judgements in
where none exist - why did it need another?

>>  The standard for boolean logic operators (even if it is just a de
>>  facto standard) is that they operate on boolean parameters and return
>>  boolean results. There are exceptions, and some have been around a
>>  long time, but age in itself does not make something standard.
>
>That's what happens in statically typed languages like C++ and Pascal
>and Fortran. It has to. It's "standard" only in so far as static typing
>is "standard".

Precisely - and at present, statically typed languages still dominate
in most non-internet-related roles.

> Python, as you may have noticed, is not a statically
>typed language.

As I said elsewhere in the thread...

: However, statically typed languages don't reign in the way they once
: did. As dynamically typed languages become more popular, and as (I
: hope) functional languages get more and more recognition outside of
: academia, it will be interesting to see if the current de facto
: standard gets replaced.


> So, what's "standard" in other dynamically typed
>languages? Let's take a representative sample. (By the way, I mean
>that; the examples weren't chosen to produce the results I want.
>Before I checked, I thought Smalltalk's boolean operations were
>unlike Python's and I had no idea which way JavaScript's went. I
>chose the first four dynamically typed languages that occurred to
>me.)
>
>  - In most of the Lisp family, <and> and <or> behave as they do
>    in Python.

Yet scheme seems to have an '(if <cond> <true-value> <false-value>)'
function provided as standard.

>  - In Perl, <&&>/<and> and <||>/<or> behave as <and> and <or> do
>    in Python.

Yet Perl (according to an old reference guide I have) provides a
C-like '<condition> ? <true-value> : <false-value>' conditional
expression (odd as I saw '<true-value> if <condition> else
<false-value>' referred to a Perlish earlier, but either syntax makes
the point).

>  - In Smalltalk, <and> and <or> are methods on boolean objects.
>    They behave as much like Python's <and> and <or> as they could
>    given the fundamental differences in the languages; in
>    particular, they short-circuit and they may return a result
>    of any type.

Not quite sure what you're saying there, other than that Smalltalk
methods are called messages, but that's hardly relevant, or that (if I
understand '<and>' and '<or>' correctly) it's possible to override
operator behaviour (rather like defining __and__ in Python).

That's hardly relevant, though.

If you evaluate (true & 'x') in Smalltalk you'll get 'x' - identical
to Python. But on the other hand, guess what happens when you evaluate
((1 == 1) ifTrue: [5] ifFalse: [6]) - yes, Smalltalk has an explicit
conditional expression too.

>  - In JavaScript, <&&> and <||> behave as <and> and <or> do in
>    Python.

And <condition> ? <true-value> : <false-value> behaves as any C
programmer expects.

>I think it's clear what's "standard" in this domain.

Quite right - selective 'and' and 'or' are consistently provided in
dynamically typed languages. But a far more readable conditional
expression is also consistently provided and preferred in cases where
it is applicable. Which means that standard *usage* in dynamically
typed languages is to use conditional expressions for selection and
boolean operators as pure boolean operators.

At the moment, statically typed languages are losing their claim to
being any kind of standard - maybe selective 'and' and 'or' will
become the norm as dynamically typed languages gain ground. In a sense
(given the number of languages that already support them) that is
almost certain to be true.

I happen to believe that selective 'and' and 'or' are historic
hangers-on - a solution to a problem that is better solved another
way. That is one judgement that I own up to. But even if 99.999% of
the people here agree with me (obviously not true) you needn't worry
about that judgement as no-one is proposing to remove the selective
behaviour of 'and' and 'or' from Python.

LISP is an important and powerful language, but not a readable or
intuitive one. That is another opinion of mine which could be seen as
judgemental, though I doubt many people would seriously disagree with
it.

Beyond that, what I wrote was at least intended to be pure objective
fact. I was, after all, countering what I saw as an unjustified
reading-in of judgement where none existed.

-- 
steve at ninereeds dot fsnet dot co dot uk