[Edu-sig] python versus __python__

[Scott David Daniels]

Arthur wrote:
> My studies on the subject of subclassing the complex type have been quickly 
> abandoned - it becoming clear that the fact the .real and .imag are read-only 
> defeats the ideas I had for it.
Ahh: complex is (as are bool, int, long, string, and unicode) immutable.
Changing such types to be mutable is "nasty" -- reuse of an immutable is
done by referring to the same object, while reuse of an immutable needs
a copy.  If you do make one of these mutable, be sure to eliminate the
hash function, or you won't be able to have it a key in a dictionary.
Typically immutables are considered "identical" if they have identical
state.  Conceptually there should be no way to tell the difference
between two distinct but equal immutables and the same immutable used
twice.  In fact, you can just check if id(one) == id(other), but that
is "cheating" -- the "no way to tell" avoids precisely this trick.

By the way, before you get too involved in playing with this stuff,
there is a nasty surprise waiting to bite you.  When you are comparing
ids, be sure to compare ids of named things, not expressions.  You might
be surprised to learn: id(math.log(math.pi)) == id(math.log(math.e))!
It is fun to try to figure out why.  I'll post the answer tomorrow if
nobody gets it by then.

> But as these dead-end explorations usually do, got me thinking about things
> not previously confronted.  Like the simple question of what is "float"
> fundamentally,  a function - as in float(1) - or a numeric type.  And by
> subclassing "float", is one subclassing a function or a type. 
 > Is just some shadowing of a name going on in the netherworld, or are
 > the function and type more intimately related in that realm?

If you define a class named PyGeoTriangle, you create new instances with
PyGeoTriangle(<some args>).  Same with types (especially as we head into
the brave new world of "new-style objects").  The changes in Python are
heading towards a unification of types and classes, but that cannot
fully happen until Python 3.0 (at least).  Why not? -- old-style classes
and new-style classes behave differently under the covers.  So
eventually (and in many cases now), a type name is just a predefined
new-style class name.

New-style classes and standard types can be made to behave quite the
same, but old-style classes cannot.  Unfortunately, some basic parts
of Python (Exception comes to mind) use old-style classes.  Code that
people have written to run with Exception, living in some dark lab in
northern New Jersey (for example), would break if Exception were a
new-style class.  We cannot make the change except when we declare an
"incompatible change".  The reason for making the change to new-style
classes throughout is to simplify Python's design (and the model the
user must have in his head).

> Us non C programmers look forward to PyPy for the view of the netherworld it will
> give us.  In truth I expect PyPy to bring a new burst of creative energy to the
> Python world, just by opening up the possibility of lower level exploration to 
> a wider group of folks.
> 
> As the answer to most of the "why Python" questions that we all try to answer
> on some technical level, in the end - IMO - boil done to largely that, the creative
> energy surrounding it.
> 
> Perhaps that understanding should provoke me into whining less about the moving
> target that Python seems sometimes to be.  Perhaps Guido understands either consciously or 
> intuitively that less openness to change - with all the downsides of such change -
> would subvert that essential energy aura in which Python persists.

--Scott David Daniels
Scott.Daniels at Acm.Org