[PEAK] DeprecationWarning under python 2.6

P.J. Eby 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
>def foo():
>     pass
>@before(foo, "True")
>def bar():
>     pass
>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.

Any suggestions?

More information about the PEAK mailing list