(PEP-308) Python's Conditional Selection Operators

Gareth McCaughan Gareth.McCaughan at pobox.com
Sun Feb 16 13:42:52 EST 2003


[Warning: most of this is about Lisp rather than about Python. Perhaps
we should take it to e-mail.]

Stephen Horne wrote:

> >>  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.

Common Lisp is object oriented. More precisely: it allows you to
program in OO style; like C++ and Python, it's a multiparadigm
language and doesn't *force* OO on those who don't want it.

Early versions of Common Lisp didn't include CLOS (the Common Lisp
Object System). XLisp is a subset of early CL, plus an object system
(not CLOS).

> >>                                               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.

I'm pleased to hear it. :-)

> 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.

I didn't think you were attacking Lisp. I thought you were saying
silly things about it. Such as, for instance, that the statement
"Python's conditional operations are non-standard because they don't
always return booleans" isn't weakened by the fact that Lisp's
corresponding operations don't always return booleans either
because Lisp isn't "standard".

> >>  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???

I'm not sure where "adding" comes in. Terry Reedy said that Python's
<and> and <or> are "not the standard versions". Erik objected to the
term "standard versions" and observed that "Python's and/or operators
behave just like Lisp's, for example, and Lisp has been around a very
long time". That's what you replied to by saying how non-standard Lisp
is. The "precedent" here is the precedent for having Pythonic and/or
in the first place; not for adding them now since, as you say, we already
have them.

> 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.

Erik's article did not imply that Lisp defines a standard others
have to follow. I cannot imagine why you think it did. He explicitly
said that there's "no such thing" as "the standard versions", and
I'd have thought the "for example" was a dead giveaway that he wasn't
claiming that everyone has to do what Lisp does.

> 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.

But no one was proposing, in the least, that Python should follow
Lisp syntax here.

> 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.

Actually, that's not particularly why Lisp syntax is the way it is,
and (rightly or wrongly) many Lisp programmers consider Lisp's
eccentric syntax one of its greatest strengths because it makes
Lisp's macro system, certainly one of its greatest strengths,
possible. But this is a digression within a digression. :-)

> 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.

I don't understand. No one uses anything remotely like the and/or
idiom in Lisp, because it has "proper" conditional expressions.
What exactly are you saying "made sense in Lisp, but ... can be
improved upon in Python"? Not the "selective 'and' and 'or'"
themselves, since you say you'd never suggest taking them out.
Not the and/or trick used to mimic a conditional operator in
Python, since it doesn't make the slightest sense in Lisp. But
what, then?

> 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?

Using the word "standard" is itself a value judgement.

> >>  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.

I'm not sure what counts as a non-internet-related role, nor why
what dominates in such roles is particularly relevant.

> > 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.

Yes, it does. I honestly have no idea why this is supposed to be
relevant. ... A sudden thought occurs to me. You didn't think,
did you, that Erik was saying that Lisp uses "C and x or y" to
do conditionals? I'm quite sure he wasn't, but if by some chance
he was then he was completely wrong.

> >  - 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).

Yes, it does. Again, what's the relevance? Did you think I was
arguing in favour of "C and x or y", or against adding a conditional
operator to Python? As it happens, both Erik and I are in favour
of adding one.

> >  - 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).

I'm saying that Smalltalk's boolean operators are like Python's
in the sense that's relevant here.

<pedant>No, Smalltalk methods are called methods. Messages correspond
to method names, or to what Common Lisp calls "generic functions".
When you send an instance of Foo the #bar message, it responds by
executing the Foo>>bar method.</pedant>

> That's hardly relevant, though.

That's right, it's not.

[SNIP: Stephen's observation that Smalltalk and JavaScript both
have proper conditional expressions]

> > 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.

Sure. I don't know what I said that makes you think I'd disagree
with that, but I certainly don't. Python should have conditional
expressions, and "C and x or y" is an ugly workaround for their
absence.

> 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.

I wasn't worrying about it.

> 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.

Whatever lack of readability Lisp suffers is due to factors that
have nothing whatever to do with this thread. No one's been proposing
to structure Python programs with nested parentheses instead of
nested indentation.

Actually, that's not *quite* true. One thing that makes Lisp hard
to read, especially for newcomers, is its tendency to use
positional information to distinguish between the different
parts of a form. Thus, you say (if C x y) instead of (if C then x else y),
(dolist (i items) stuff) instead of (dolist (for i in items) do stuff),
and so on. That may have been a bad decision in Lisp; it would certainly
be bad to copy it anywhere in Python. Which is why I think, for instance,
that proposals like "if C: (x,y)" are bad.

> 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.

It is common to see judgement in others' words, and pure
objective fact in one's own. :-) The way it looks to me is:
Terry made a value judgement (objecting to Python's and/or
because they're "not the standard versions"); Erik disputed
the notion of "standard" being used by Terry and observed
that in any case there's precedent for them, citing Lisp as
*one* example; you said "but Lisp is non-standard and
unreadable and unintuitive", with -- I thought, at least --
some implication that following anything Lisp has done is
likely to be dangerous. Your description of Lisp used the
words "quirky", "doesn't even fit", "obsessed", "infuriatingly
stupid". Are you quite sure you were only interested in
providing the objective facts? :-)

--
Gareth McCaughan  Gareth.McCaughan at pobox.com
.sig under construc




More information about the Python-list mailing list