creating class objects inside methods

[Dave Angel]

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