[PEAK] DeprecationWarning under python 2.6

[Kyle VanderBeek]

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.

On Tue, Jul 14, 2009 at 3:31 PM, Sergey Schetinin <maluke at gmail.com> wrote:

> I think it would be better to apply that patch to PEAK-Rules -- create
> a new AddOn subclass with that __new__ method and use it as a
> baseclass for the classes that cause the warning.
>
> Most AddOn subclasses in other packages don't redefine __new__ and
> don't need the fix.
>
> On 2009-07-15, Kyle VanderBeek <kylev at kylev.com> wrote:
> > 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.
> >
> >
> > _______________________________________________
> >  PEAK mailing list
> >  PEAK at eby-sarna.com
> >  http://www.eby-sarna.com/mailman/listinfo/peak
> >
>
>
> --
> Best Regards,
> Sergey Schetinin
>
> http://s3bk.com/ -- S3 Backup
> http://word-to-html.com/ -- Word to HTML Converter
>



-- 
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/e058f753/attachment-0001.html