[PEAK] DeprecationWarning under python 2.6

[Kyle VanderBeek]

Actually, I found this to be the more correct way to smash arguments before
continuing on in the "super" sequence up to object:

    def __new__(cls, *args):
        # Work around for python 2.6 DeprecationWarning
        return super(AddOn, cls).__new__(cls)

Can anyone apply this change to the AddOn object and test to make sure
things you're doing don't break?  All the tests run by "python setup.py
test" pass currently.  I'll likely apply this patch to Fedora's packaged
version soon.

On Wed, Jul 8, 2009 at 2:13 PM, Kyle VanderBeek <kylev at kylev.com> wrote:

> 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.
>
>


-- 
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/20090714/502dc9f6/attachment.html