code review

[Roy Smith]

(Sadly, when I say "we" I mean
collectively. Many language designers, and programmers, don't have the
foggiest clue as to what makes a good clean design. Hence C++ and PHP.)

I'm not going to defend C++, but to be fair, a major driver of the design is that it had to be plug-compatible with C. From that you're stuck with the preprocessor and pointers. Much goes downhill when you start from there.

PHP, yeah, that's just charlie-foxtrot from start to finish.

 

[Chris Angelico]

Actually, no. Is True less than False, or is it greater? In boolean
algebra, the question has no answer. It is only an implementation detail
of Python that chooses False < True.

Maybe in boolean algebra, but in code, it's handy to have sortable
bools. In SQL, for instance, I can use a boolean in an ORDER BY,
perhaps followed by another criterion, and it's effectively sorting by
"1 if some_boolean else 0" or in C notation "some_boolean ? 0 : 1"

ChrisA

 

[rusi]

Maybe in boolean algebra, but in code, it's handy to have sortable
bools. In SQL, for instance, I can use a boolean in an ORDER BY,
perhaps followed by another criterion, and it's effectively sorting by
"1 if some_boolean else 0" or in C notation "some_boolean ? 0 : 1"

ChrisA

Actually a boolean algebra is a lattice with some additional
properties
A lattice is a poset (partially ordered set) with suprema and infimas
And so there is one natural order relation on any boolean algebra
which may be defined as
a ≤ b iff a ⋀ b = a

tl;dr version: In a boolean algebra, False is bottom and True is top

 

[Dennis Lee Bieber]

Actually, no. Is True less than False, or is it greater? In boolean
algebra, the question has no answer. It is only an implementation detail
of Python that chooses False < True.

And for the real fun... VMS F77 (if not the VAX/Alpha architecture
itself) basically used lsb making 1, 3, 5... True; and 0, 2, 4... False

 

[Terry Reedy]

From now on, for each operator I would have to remember wether it
is a supposedly comparison operator or not.

I believe the following rule is true: if a op b is True or False raises,
then op is a potentially chained comparison operation. They are (not)
equal (and (not) is), the 4 order comparisons, and (not) in. 'in' should
be the only surprise and most confusing.False

'and' and 'or' are not included because they do not always return a
bool, and indeed, they are not binary operators in the usual sense
because of short-circuiting.

 

[Ian Kelly]

I believe the following rule is true: if a op b is True or False raises,

I don't follow. Raises what?

then op is a potentially chained comparison operation. They are (not) equal
(and (not) is), the 4 order comparisons, and (not) in. 'in' should be the
only surprise and most confusing.
False

'and' and 'or' are not included because they do not always return a bool,
and indeed, they are not binary operators in the usual sense because of
short-circuiting.

The only one of those operators that can be said to always return a
bool is "is (not)". The others (apart from "and" and "or") all can be
overloaded to return anything you want (for example, sqlalchemy
overloads them to return expression objects that are later compiled
into SQL), and chaining still occurs regardless of the types they are
applied to.

 

[Terry Reedy]

Sorry, left out 'or' in 'or raises'

I don't follow. Raises what?

an Exception.

The only one of those operators that can be said to always return a
bool is "is (not)". The others (apart from "and" and "or") all can be
overloaded to return anything you want

OK, add 'by default, without over-rides ;-).
or 'for builtin classes'.

Python's flexibility makes it really hard to make any general statement.
In my book-in-progress, I am currently resorting to saying "In Python*,
...." whenever I know and remember that it is possibly to over-ride the
customary behavior described in '...'.

 

[Albert van der Horst]

Technically of course Python doesn't have assignment, it just binds names.

Albert raised the subject of Algol 68 which if I remember correctly used :=
for assignment and = to bind names (although unlike Python you couldn't
then re-bind the name to another object in the same scope).

Algol 68 is very particular about this indeed.
For instance they have a whole theory behind
real x;
x := 17.;

This is considered an abbreviation of
ref real x = loc real;
x:= 17;

So x is a reference bound to a freshly generated local real.
You see = and that means you can't ever break that relationship.
On the left side of a := it is required to have a ref something.
Because that generates a pretty clear context, you have considerable
leeway on the right side, that is cast into the something.

real x= 18.;
x := 15.;
is right out.

If you want to rebind something you need a ref which is really
a ref ref. Then you can only switch bindings between different
types. So it is totally different from Python.

I never thought about = in python to mean binding to set it
apart from the Pascal := , instead of being a c-ism.

Still my mathematical mind is bothered about the sequence
( legal in FORTRAN , C Python )
X = 1 <separator>
X = 2

Groetjes Albert

Groetjes Albert