Re: DeprecationWarning under python 2.6

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 <[email protected]> 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 <[email protected]> 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-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]> 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?
> > >
> > >
> >
> >
> >
> > --
> >
> >
> >
> > [email protected]
> >  Some people have a way with words, while others... erm... thingy.
> >
> >
>
>
>
> --
> [email protected]
>   Some people have a way with words, while others... erm... thingy.
>
>
> _______________________________________________
>  PEAK mailing list
>  [email protected]
>  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