Class Variable Question

[Alex Martelli]

"Douglas Alan" <nessus at mit.edu> wrote in message
news:lc3dbiou2u.fsf at gaffa.mit.edu...
> "Steve Holden" <sholden at holdenweb.com> writes:
>
> > That's correct. Python gives you "enough rope to shoot yourself in
> > the foot", and so does not offer the protection schemes associated
> > with statically-types languages like Java and C++. This increases
> > the flexibility of the language, at the (slight) risk of errors
> > which would not occur in Java or C++.
>
> Actually, there's no extra flexibility than if you used different
> syntaxes for variable initialization and variable assignment.

Of course there is -- if you did the latter, you would for example have
to use different syntax for the first pass through a loop than for further
ones.  You might choose to have THREE approaches: one that works
just as well for the first binding and for other re-bindings, one that
just works for the first binding, one that just works for re-bindings.

Funny enough, it's trivial to have that...:

def firstBind(object, attname, value):
    if hasattr(object, attname):
        raise AttributeError, attname
    return setattr(object, attname, value)

def reBind(object, attname, value):
    if not hasattr(object, attname):
        raise AttributeError, attname
    return setattr(object, attname, value)

and, of course, use setattr for the common case, where you do not
care whether it's the first binding or a further one.


Deciding which approach the assignment-statement is syntax sugar
for is not currently feasible (except for binding to attributes of
instances) -- you always get "setattr semantics" then.  It would take
incredibly little to make it feasible for most assignments -- just a
couple of bits on each dictionary object, optionally 'locking' it
against certain changes -- as dictionaries are what underlies most
assignments (local-variables being the exception, and rather an
issue for most such metaprogramming approaches).  Gotta work on
a patch for that one of these days (hmmm, better do a PEP first).

I draw the line at having two subtly different syntax-sugar forms
for two of the three kinds of binding (first-binding, re-binding,
any-binding) and I think that having _three_ subtly different
syntaxes is even worse.  We have that in our proprietary scripting
language (which is embedded in all of our applications), but I
consider that a _defect_ of the language, not a plus (it was
designed a long time ago, and compatibility means we can of
course never take such a 'feature' away:-) -- in many years of
experience, I've seen it confuse newbies (and occasionally old
hands, too) far more often than I have seen it used in arguably
profitable ways.  Having ONE kind of assignment (and function
call syntax for other, non-assignment kinds of manipulation)
seems far preferable.


> > There is magic you can do to restrict operations of this kind, but most
> > Python programmers are happy to accept the language as it is, since in
> > practise this doesn't appear to be a problem.
>
> In practice it is a *very* significant problem.  This is certainly one
> of the largest sources of bugs.  And it is, annoyingly enough, one of
> the few valid complaints that Perl devotees can make against Python.

Oh?  How many large Python applications have you written, that you
can so confidently assert this language characteristic is "one of the
largest sources of bugs" in said applications, against the unanimous
opinion of several of us who HAVE developed such apps...?

Extraordinary claims require extraordinary proof -- and, clearly, it
*is* a rather extraordinary claim for you to make, that you know
"one of the largest sources of bugs" in a language, better than
people more experienced in said language (and please don't think
that we ONLY know that language -- I still gain most of my daily
bread & champagne dealing with _other_ languages, e.g. by being
the official "C++ guru" for my employer!-).  I await with interest
your display of 'extraordinary proof' to match.  BTW, the only
controlled empirical experiment of language comparison of which
I'm aware doesn't match your unsupported assertions -- Ptyhon
(and, admittedly, Perl) shined in terms of both productivity AND
resulting-program solidity against other languages supporting
static compile-time checks (such as Java, in particular).


> > Look at it this way: you can spend the 60% time saving you will make
> > by programming in Python to make sure you have not made such errors!
>
> Why not be honest:  It's a wart on the language.

If you're deliberately trying to insult, you're choosing your
barbs pretty well -- here, implying dishonesty (a deliberate
lie) in the technical assertions of people you have (as far as
I know) never met.  We have professional reputations, you
know, and I consider you at the very least one of the rudest
louts to have recently darkened the face of this newsgroup.


Alex