[PEAK] DeprecationWarning under python 2.6
kylev at kylev.com
Wed Jul 8 17:13:42 EDT 2009
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):
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():
>> @before(foo, "True")
>> def bar():
>> 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__
> (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...
More information about the PEAK