It seems silly to me to create duplicate code in PEAK-Rules when we can fix it in one place for any/all subclasses of AddOn. When you say "most", it is implied that there may be someone out there who has an AddOn that also redefines __new__ (just as BitmapIndex does). This fix should work for all of those classes.<br>
<br><div class="gmail_quote">On Tue, Jul 14, 2009 at 3:31 PM, Sergey Schetinin <span dir="ltr"><<a href="mailto:maluke@gmail.com">maluke@gmail.com</a>></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;">
I think it would be better to apply that patch to PEAK-Rules -- create<br>
a new AddOn subclass with that __new__ method and use it as a<br>
baseclass for the classes that cause the warning.<br>
<br>
Most AddOn subclasses in other packages don't redefine __new__ and<br>
don't need the fix.<br>
<div><div></div><div class="h5"><br>
On 2009-07-15, Kyle VanderBeek <<a href="mailto:kylev@kylev.com">kylev@kylev.com</a>> wrote:<br>
> Actually, I found this to be the more correct way to smash arguments before<br>
> continuing on in the "super" sequence up to object:<br>
><br>
> def __new__(cls, *args):<br>
> # Work around for python 2.6 DeprecationWarning<br>
> return super(AddOn, cls).__new__(cls)<br>
><br>
> Can anyone apply this change to the AddOn object and test to make sure<br>
> things you're doing don't break? All the tests run by "python setup.py<br>
> test" pass currently. I'll likely apply this patch to Fedora's packaged<br>
> version soon.<br>
><br>
><br>
> On Wed, Jul 8, 2009 at 2:13 PM, Kyle VanderBeek <<a href="mailto:kylev@kylev.com">kylev@kylev.com</a>> wrote:<br>
> > I think just about the only answer for this would be to define a __new__<br>
> in AddOn. I agree the deprecation makes things odd and it annoys me.<br>
> ><br>
> > def __new__(cls, *args):<br>
> > return object.__new__(cls)<br>
> ><br>
> > Does that look like something reasonable that would work? I've seen it in<br>
> a couple other packages, but don't have time to test it at the moment.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Tue, Jun 23, 2009 at 5:07 PM, P.J. Eby <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>
> ><br>
> > ><br>
> > ><br>
> > ><br>
> > > At 02:08 PM 6/23/2009 -0700, Kyle VanderBeek wrote:<br>
> > ><br>
> > > > 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, "True")<br>
> > > > def bar():<br>
> > > > pass<br>
> > > ><br>
> > > > This results in:<br>
> > > ><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't get any parameters to its<br>
> > > > __new__ special method, and that's exactly what BitmapIndex is doing.<br>
> > > > Does anyone have a patch to fix this? I'm working on fully<br>
> > > > understanding peak.rules, so I haven't quite wrapped my head around<br>
> > > > the right fix yet.<br>
> > > ><br>
> > ><br>
> > > The place to fix this would be in DecoratorTools or AddOns, actually. I<br>
> suppose DecoratorTools' classy.__new__ or AddOns' AddOn.__new__ could check<br>
> if its superclass __new__ is object __new__, and if so terminate the __new__<br>
> upcalling.<br>
> > ><br>
> > > (Not that it's your problem, but making __new__ *not* take arbitrary<br>
> parameters is a design flaw of 2.6, since it makes it impossible to write an<br>
> inheritance-agnostic mixin where __new__ is concerned.)<br>
> > ><br>
> > > I'm not entirely sure what to do about this myself because this could<br>
> potentially either introduce a significant performance hit, or create bugs<br>
> in other packages, if somebody has a __new__ that comes *after* AddOn in the<br>
> 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 'MyOtherClass.__new__' uses those arguments, then a change to<br>
> AddOn.__new__ that drops the arguments unconditionally is now a problem.<br>
> Conversely, having AddOn check for object.__new__-ness will induce needless<br>
> overhead for this case.<br>
> > ><br>
> > > Any suggestions?<br>
> > ><br>
> > ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> ><br>
> ><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>
> ><br>
><br>
><br>
><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>
><br>
</div></div>> _______________________________________________<br>
> PEAK mailing list<br>
> <a href="mailto:PEAK@eby-sarna.com">PEAK@eby-sarna.com</a><br>
> <a href="http://www.eby-sarna.com/mailman/listinfo/peak" target="_blank">http://www.eby-sarna.com/mailman/listinfo/peak</a><br>
><br>
<font color="#888888"><br>
<br>
--<br>
Best Regards,<br>
Sergey Schetinin<br>
<br>
<a href="http://s3bk.com/" target="_blank">http://s3bk.com/</a> -- S3 Backup<br>
<a href="http://word-to-html.com/" target="_blank">http://word-to-html.com/</a> -- Word to HTML Converter<br>
</font></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>