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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
