its a good point you make. if its not _technically_ immutable, why use
__new__ when __init__ would work just as fine? well, if it should be
treated as immutable, then we should do what we can to follow that,
even in internal code that knows otherwise. Besides, maybe down the
road, protections will be added to disallow assignment to _int, and
the author thought to future proof it. In any case, the author can
only know, perhaps. ask if you really feel the need to know.
On Sun, Aug 3, 2008 at 2:32 PM, Ethan Furman <ethan@stonelea f.uswrote:
--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
__new__ when __init__ would work just as fine? well, if it should be
treated as immutable, then we should do what we can to follow that,
even in internal code that knows otherwise. Besides, maybe down the
road, protections will be added to disallow assignment to _int, and
the author thought to future proof it. In any case, the author can
only know, perhaps. ask if you really feel the need to know.
On Sun, Aug 3, 2008 at 2:32 PM, Ethan Furman <ethan@stonelea f.uswrote:
Emile van Sebille wrote:
>
Good point. What I'm curious about, though, is the comment in the code
about making the Decimal instance immutable. I was unable to find docs on
that issue.
>
~Ethan~
--
>
>>
>Ethan Furman wrote:
>>
>Python considers names that start with a leading underscore as internal or
>private, and that abuse is the burden of the abuser...
>>
>Is bytecodehacks still around? That was serious abuse :)
>>
>Emile
>Ethan Furman wrote:
>>>
>> --d25._int = (1, 5)
>> --d25._int = (1, 5)
>Python considers names that start with a leading underscore as internal or
>private, and that abuse is the burden of the abuser...
>>
>Is bytecodehacks still around? That was serious abuse :)
>>
>Emile
Good point. What I'm curious about, though, is the comment in the code
about making the Decimal instance immutable. I was unable to find docs on
that issue.
>
~Ethan~
--
>
--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
