[PEAK] DeprecationWarning under python 2.6

[Kyle VanderBeek]

I think just about the only answer for this would be to define a __new__ in
AddOn.  I agree the deprecation makes things odd and it annoys me.

def __new__(cls, *args):
    return object.__new__(cls)

Does that look like something reasonable that would work?  I've seen it in a
couple other packages, but don't have time to test it at the moment.

On Tue, Jun 23, 2009 at 5:07 PM, P.J. Eby <pje at telecommunity.com> wrote:

> 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:
>>
>>
>> /usr/local/py26/lib/python2.6/site-packages/PEAK_Rules-0.5a1.dev_r2582-py2.6.egg/peak/rules/indexing.py:220:
>> 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?
>
>


-- 
kylev at kylev.com
 Some people have a way with words, while others... erm... thingy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eby-sarna.com/pipermail/peak/attachments/20090708/0001d3e3/attachment.html