[PEAK] DeprecationWarning under python 2.6
pje at telecommunity.com
Tue Jun 23 20:07:50 EDT 2009
At 02:08 PM 6/23/2009 -0700, Kyle VanderBeek wrote:
>A great deal of PEAK-Rules will cause DeprecationWarnings to be
>issued. As a maintainer of several related and dependent Fedora
>packages, I need to get this fixed. Even a trivial use such as this
>will cause problems:
>from peak.rules import before
>This results in:
>DeprecationWarning: object.__new__() takes no parameters
>Essentially, object() in 2.6 shouldn't get any parameters to its
>__new__ special method, and that's exactly what BitmapIndex is doing.
>Does anyone have a patch to fix this? I'm working on fully
>understanding peak.rules, so I haven't quite wrapped my head around
>the right fix yet.
The place to fix this would be in DecoratorTools or AddOns,
actually. I suppose DecoratorTools' classy.__new__ or AddOns'
AddOn.__new__ could check if its superclass __new__ is object
__new__, and if so terminate the __new__ upcalling.
(Not that it's your problem, but making __new__ *not* take arbitrary
parameters is a design flaw of 2.6, since it makes it impossible to
write an inheritance-agnostic mixin where __new__ is concerned.)
I'm not entirely sure what to do about this myself because this could
potentially either introduce a significant performance hit, or create
bugs in other packages, if somebody has a __new__ that comes *after*
AddOn in the method resolution order.
Consider this class:
class MyAddOn(AddOn, MyOtherClass):
def __new__(cls, ...)
# do stuff, then...
return super(MyAddOn, cls).__new__(cls, ...)
If 'MyOtherClass.__new__' uses those arguments, then a change to
AddOn.__new__ that drops the arguments unconditionally is now a
problem. Conversely, having AddOn check for object.__new__-ness will
induce needless overhead for this case.
More information about the PEAK