horos11 wrote:
Carl,
Thanks for the info, but a couple of points:
1. it wasn't meant to be production code, simply a way to teach
python.
2. this should either be a compile time or a runtime error.
'Actions at a distance' like this are deadly both to productivity and
to correctness - not only is this a runtime error, it is a *silent*
runtime error. Any other language I know would catch this, whether it
be lua, java, or perl.
Saying that 'whoa, this coding error should be handled by naming
convention' may be the only practical way of getting around this
limitation, but it is a limitation nonetheless, and a pretty big one.
Ed
The bug in your code that we're discussing is caused because you rebound
a global attribute to a new value, and lost the original object.. Your
complaint is that when the global name happens to reference a class, and
the new value doesn't, you think the compiler should give an error.
If you would call this a limitation of Python, and think it should be
"fixed," then you clearly do not understand the language or its
philosophy. I can't compare to either lua or perl, but Java is a vastly
different language from Python, and this type of thing is at the heart
of the difference. In Java you must declare the types of everything at
compile time (except they had to make a big hole for collections), and
the compiler is therefore told much about the possible behavior of each
variable.
In Python you declare nothing, and much of the power of the language
comes from the fact that every construct is a first-class object.
Function definitions are fancy literal values for function objects,
class declarations are just one of the ways of making a factory
function, and classes themselves are instances of metaclasses. You can
declare new objects that mimic existing ones without having to define a
new class that derives from the old class (duck-typing). And you can
frequently reuse the runtime semantics intended for one purpose to
accomplish something very different.
Python also deliberately doesn't have a notion of "constant"
declaration, nor "private." It doesn't have the notion of a library (or
class) building a "sealed" implementation which cannot be customized.
What Python offers for many of these is some conventions. Names
starting with leading underscores are "private" by convention. Names
all uppercase are "constant." Names starting with an uppercase letter
are classes. But rather than trying to make a language definition of
each of these terms, it's just a convention, observed among the
consenting adults (?) cooperating in the codebase.
I'm not saying (here) whether Python is better or worse than the
languages which are strongly typed at compile time, but just that it's a
deliberate set of design decisions. And special-casing one or two of
the more obscure danger spots is not in keeping with the Python
philosophy. Further, I don't see that you did anything that the runtime
should disallow. You assigned a new value to the 'state' attribute.
And when you tried to call it, it called the __str__() method of that
object.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
