Kirby - >PS: since you've been studying subclassing primitive types using __new__, >maybe you could show us a user-defined floating point type that reports two >numbers equal if their absolute value difference is less than e. Anyone?
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. I guess I might have tried harder to see if one could override that behavior in a subclass, but my decision to move on is based on the fact that if what I like to think I am pursuing is simplicity, changing the fundamental behavior of a built-in, even if doable, would not seem to be a path to it. 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? 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. Art _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
