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 [EMAIL PROTECTED] _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
