Const and the Zen of the Pythonista

[Dennis E. Hamilton]

> Am I finally getting it or have I merely become a language-lawyer
overnight?

Yes.

Or maybe not.

(I couldn't help it.)

Nice analysis.

It doesn't work for me though.  When I write a const, for me I am *telling*
**you** that I will never change the value associated with that symbol, and
you can count on it.  It gives you something that is difficult to determine
by analysis.  It gives it to the future **me** when I review my own code
too.  Having the language processor hold me to my promise helps me not lie
to myself and that is ***really*** valuable to me.  (I also hide things in
plain site, regularly, sometimes daily, and not just my eyeglasses.)
  If we had a language that was value oriented (whether or not
strongly-typed), then I could say things like

  let a =  ...,
      b = ...,
	c = ...
   in f(a,b,c)

and all would be well, even with a pretty elaborate f-thingy, even with
assignment (so long as let-clause and where-clause stuff makes equivalents
of const's).  In a statement language with Python's rules, const is the
closest thing I have to being able to provide that clear
fixed-definition-in-scope-by-value-right-here sort of thing.

-- orcmid

PS: I would really love this.  I don't know that it is in the spirit of
Python with regard to side effect tolerance, though.  I would in particular
like the option to arrange that it is *not* OK for someone to stick a new
member into an object of mine that has nothing to do with the invariants I
provided when I defined the object.  Fortunately, I can simply refrain from
that behavior, but I don't like the idea of any object being a potential
baggage carrier for what might be some pretty weird stuff and that,
apparently, one can hack into the (Python) implementation of any object one
can access. -- dh.