Arthur wrote:
> Scott David Daniels wrote:
> ...
> Getting one's arms around all the practical implications of these issues
> related to mutable, immutable - understanding when one should want to
> retain object identity, and when one should want to break it, the full
> implications of these d
> Here's the problem:
> Your notion of equality is not transitive. That's tough -- it
> invalidates the assumptions of the float type (and all basic types).
> Also, you didn't tweak hash, so a dictionary with these things in them
> would not find entries that turn out to be equal.
>
> --Scott
Kirby Urner wrote:
>>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?
>>
>
Fuzzy redone a breath:
class
> 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?
>
Like this I guess:
>>> class Fuzzy(float):
Scott David Daniels wrote:
>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, stri
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 type
Arthur wrote:
> Arthur wrote:
>
>> 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 wi
Arthur wrote:
>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.
>
>
So I g
