On May 3, 4:47 am, Keshav Kini wrote:
> If such conditions exist (necessitating the calling of the parent
> initializer at the end of the child initializer rather than at the
> beginning) then the parent types are pretty clearly "abstract base
> classes", in OOP terminology -- i.e. classes which c
Hi Julien
On 3 Mai, 16:02, Julien Puydt wrote:
> The parent class cannot expect anything if it's initialization code
> hasn't been called, can it?
Apparently both the string representation and the hash *are* available
before calling init:
sage: P_init = Parent(category=Rings())
sage: P_init
Le jeudi 03 mai, Simon King a écrit:
> On the other hand: One could argue that the parent class can
> expect that some basic tools (such as __hash__ and __repr__) already
> work when being called. Hence, before calling __init__ of the parent
> class, one is supposed to make sure that the "tool chai
Simon King writes:
> Hi Keshav,
>
> On 2012-05-03, Keshav Kini wrote:
>> Simon King writes:
>>> No idea. Clearly, unless there is a good reason, the init method of the
>>> base class should be called at some point. But I was not aware of a
>>> convention whether the base init should be called fi
Hi Keshav,
On 2012-05-03, Keshav Kini wrote:
> Simon King writes:
>> No idea. Clearly, unless there is a good reason, the init method of the
>> base class should be called at some point. But I was not aware of a
>> convention whether the base init should be called first or last or
>> whatever. D
Simon King writes:
> Hi Kwankyu,
>
> On 2012-05-03, Kwankyu Lee wrote:
>>> > As the "..Algebra.__init__" is expected to be
>>> > placed at the beginning of the initialization code
>>>
>>> Why? Is that a Python convention?
>>
>>
>> Isn't that a convention of objected-oriented programming?
>
> N
Hi Kwankyu,
On 2012-05-03, Kwankyu Lee wrote:
>> > As the "..Algebra.__init__" is expected to be
>> > placed at the beginning of the initialization code
>>
>> Why? Is that a Python convention?
>
>
> Isn't that a convention of objected-oriented programming?
No idea. Clearly, unless there is a
Hi Simon,
The result is that the hash is broken by default, since the string
> representation can be changed *after* creation of the object, which
> means that the hash value would change as well. There is a ticket fixing
> it, though.
>
> > I think the problem lies in that the hash is calcula
On 2012-05-03, Simon King wrote:
> Then, the third solution of your
> problem would be
> def __init__(self, i):
> CommutativeRing.__init__(self, i.base_ring(), category=False)
> self._ideal = i
> self._init_category_(CommutativeRings()) # or whatever is appropriate
Hi Kwankyu,
On 2012-05-03, Kwankyu Lee wrote:
> I am not against using the string representation to compute the hash, as
> the last resort.
The result is that the hash is broken by default, since the string
representation can be changed *after* creation of the object, which
means that the hash
Hi Simon,
Thank you for the explanation.
However, during the category initialisation, self is used as key in
> some cache. Hence, it is needed that its hash value is available. By
> default in sage.rings.ring.Ring, hash(self) is the self as
> hash(repr(self))
> (which I don't like, by the wa
Hi Kwankyu,
On 2012-05-03, Kwankyu Lee wrote:
> In Sage 5.0rc0, I observe a weird phenomenon. See the following code
> -
> But the following modified code results in an error. The difference is the
> addition of the method "_repr_".
> -
> from sage.rings.ring import CommutativeAlgebra
>
12 matches
Mail list logo
