Comment 24 for bug 893091
Revision history for this message
|
|
#24 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > What do you think about the change to subtyping from Long on both 2.x and 3.x
> > > which gets rid of any Int calls. It passes the test suite.
> >
> > I don't think that's a good idea on 2.x; changing the inheritance hierarchy is
> > an API break.
>
> In which case why am I bothering trying to support both version in one codebase
> if we can't unify them as much as possible? The old codebase hasn't been
> touched in some time. Why are we supporting internals such as abstract.c as
> part of the API guarantees. It just seems like a huge maintenance nightmare
> and both of us have shone that we have little time to maintain this codebase
> beyond basic bug fixing. I've always maintained that the only API guarantees
> we give are on the higher level Python bits.
After thinking about it a bit I can revert the Int class but it needs to be changed to use __dict__ for the signature so the code in other areas doesn't have to be branched. I understand the need for someone to be able to check the base type. In Python 3.x I will just alias the DBusInt base class to the DBusLong base class.