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.<br><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">def __new__(cls, *args):</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">    return object.__new__(cls)</span><br><br>Does that look like something reasonable that would work?  I&#39;ve seen it in a couple other packages, but don&#39;t have time to test it at the moment.<br>
<br><div class="gmail_quote">On Tue, Jun 23, 2009 at 5:07 PM, P.J. Eby <span dir="ltr">&lt;<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">At 02:08 PM 6/23/2009 -0700, Kyle VanderBeek wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A great deal of PEAK-Rules will cause DeprecationWarnings to be<br>
issued.  As a maintainer of several related and dependent Fedora<br>
packages, I need to get this fixed.  Even a trivial use such as this<br>
will cause problems:<br>
<br>
from peak.rules import before<br>
<br>
def foo():<br>
    pass<br>
<br>
@before(foo, &quot;True&quot;)<br>
def bar():<br>
    pass<br>
<br>
This results in:<br>
<br>
/usr/local/py26/lib/python2.6/site-packages/PEAK_Rules-0.5a1.dev_r2582-py2.6.egg/peak/rules/indexing.py:220:<br>
DeprecationWarning: object.__new__() takes no parameters<br>
<br>
Essentially, object() in 2.6 shouldn&#39;t get any parameters to its<br>
__new__ special method, and that&#39;s exactly what BitmapIndex is doing.<br>
Does anyone have a patch to fix this?  I&#39;m working on fully<br>
understanding peak.rules, so I haven&#39;t quite wrapped my head around<br>
the right fix yet.<br>
</blockquote>
<br></div></div>
The place to fix this would be in DecoratorTools or AddOns, actually.  I suppose DecoratorTools&#39; classy.__new__ or AddOns&#39; AddOn.__new__ could check if its superclass __new__ is object __new__, and if so terminate the __new__ upcalling.<br>

<br>
(Not that it&#39;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.)<br>
<br>
I&#39;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.<br>

<br>
Consider this class:<br>
<br>
   class MyAddOn(AddOn, MyOtherClass):<br>
        def __new__(cls, ...)<br>
            # do stuff, then...<br>
            return super(MyAddOn, cls).__new__(cls, ...)<br>
<br>
If &#39;MyOtherClass.__new__&#39; 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.<br>

<br>
Any suggestions?<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br><a href="mailto:kylev@kylev.com">kylev@kylev.com</a><br>  Some people have a way with words, while others... erm... thingy.<br><br>