[Tutor] user overloaded

[Steven D'Aprano]

On Wed, Nov 28, 2018 at 12:56:32PM -0500, Avi Gross wrote:

> try ...
> except ValueError, e:
> ...
> 
> You now need to do this format:
> 
> try ...
> except ValueError as e:
> ...
> 
> Why the change?

Because the first form was a trap and a bug magnet:

try:
    block
except TypeError, ValueError, KeyError:
    print "surprise! this will not catch key errors!"



[...]
> Back to your topic. "=" as a symbol has been used over the years in many
> ways.  In normal mathematics, it is mostly seen as a comparison operator as
> in tan(x) = sin(x)/cos(x)

That's not a comparison, that's an identity. The tangent function is (or 
at least can be) defined as sine divided by cosine.


> Many programming languages used it instead to sort of mean MAKE EQUALS.

That's usually called "assignment" or "binding".


> x = x + 5
> 
> is an example where it makes no mathematical sense. How can a number be
> equal to itself when 5 is added? 

There is no solution there in the normal real number system, but there 
are forms of arithmetic where it does, e.g. "clock arithmetic". If your 
clock only has values 0 through 4, then adding 5 to any x will give you 
x back again.

Although normally we write "congruent" rather than "equals" for clock 
arithmetic: 

    x ≡ x + 5 (mod 5)


In any case, just because there is no solution doesn't mean that the 
question makes no sense:

x = x*5

makes perfect sense and has solution 0. Likewise:

x = x**2 + k

makes perfect sense too, and can have zero, one or two solutions 
depending on the value of k.



> The meaning clearly is something like x
> gets assigned a value by evaluating the current value of x and adding 5 to
> that. When done, the old value of x is gone and it has a new value.
> 
> For this reason, some languages like PASCAL used := so the above became 
> 
> x := x + 5
> 
> Yes, same symbol we are discussing and NOT what Python intends.

Actually, it is precisely what Python intends, except for two minor 
differences:

1. in Pascal, := assignment is a statement, not an expression, 
   while in Python it will be an expresion;

2. Python will discourage people from using the := expression
   form as a de facto statement, where = will do.


[...]
> And there are forms of equality that some languages need to distinguish.
> What does it mean if two (unordered) sets are equal? Must they be two
> reference to the same set or is it shorthand for them being strict subsets
> of each other in both directions? You can come up with additional
> abstractions like whether a list is a shallow or deep copy of another and
> how it effects your ideas about them being equal. You may want a way to say
> things are approximately equal. In math, something like ~= is used. Python
> has an operator called "is" that can be a variant on equality.

The "is" operator is in no way, shape or form an equality test. It is an 
*identity* test, which returns True if and only if the two operands are 
the same object.

Equality does not imply identity:

py> x = []
py> (x == []) and (x is not [])
True


nor does identity imply equality:

py> NAN = float(NAN)
py> (NAN is NAN) and (NAN != NAN)
True

Anyone using "is" when then test for equality is programming in a state 
of sin.


> Consider the concept of OR. Some languages spell it out when used in a
> Boolean context. 
> 
> a or b
> 
> But python does something new with this. In some contexts the above
> effectively becomes an IF.

This is called a "short-circuiting boolean operator", and it was old, 
old old when Python started using it 25+ years ago. I believe Lisp was 
the first to introduce them, in the 1950s.

https://en.wikipedia.org/wiki/Short-circuit_evaluation



-- 
Steve