Bug 21172 - DeprecationWarning: object.__init__() takes no parameters
Summary: DeprecationWarning: object.__init__() takes no parameters
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: python (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Simon McVittie
QA Contact: John (J5) Palmieri
URL: http://git.collabora.co.uk/?p=user/sm...
Whiteboard:
Keywords: patch
: 22955 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-04-14 07:36 UTC by Rodney Dawes
Modified: 2010-02-18 10:26 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch to fix DeprecationWarning for object __init__ (499 bytes, patch)
2009-04-14 07:36 UTC, Rodney Dawes
Details | Splinter Review

Description Rodney Dawes 2009-04-14 07:36:38 UTC
Created attachment 24788 [details] [review]
Patch to fix DeprecationWarning for object __init__

In Python 2.6 object's __init__ no longer ignores extra parameters and emits the following warning, whenever the Connection class is instantiated in Python.

DeprecationWarning: object.__init__() takes no parameters

The attached patch fixes this.
Comment 1 Simon McVittie 2010-02-18 07:08:40 UTC
*** Bug 22955 has been marked as a duplicate of this bug. ***
Comment 2 Simon McVittie 2010-02-18 07:10:31 UTC
I don't think that's the right patch for this, but I've prepared another:

http://git.collabora.co.uk/?p=user/smcv/dbus-python-smcv.git;a=shortlog;h=refs/heads/2.6
Comment 3 David Laban 2010-02-18 08:20:42 UTC
(In reply to comment #2)
> I don't think that's the right patch for this, but I've prepared another:
> 
> http://git.collabora.co.uk/?p=user/smcv/dbus-python-smcv.git;a=shortlog;h=refs/heads/2.6
> 

I'm probably not the best person to be reviewing this, but...

The "Passing arbitrary args into an __init__ and getting them silently ignored" thing deprecated in 2.6 for a reason. If we at least warn about args/kwargs we don't understand then ++. I don't know the codebase enough to be able to quickly assert whether we do or not. If someone more knowledgeable than me can assert this then ship it.

If we don't warn about unknown args, then on a scale of "completely fine" to "as messed up as overriding __getattr__" I would give this a 5.
Comment 4 Huang Peng 2010-02-18 08:45:57 UTC
I am thinking maybe the server.c or Server.py has the same problem.
Comment 5 Simon McVittie 2010-02-18 08:56:49 UTC
Following discussion on IRC:

(In reply to comment #3)
> If we at least warn about args/kwargs we
> don't understand then ++.

These are an error in __new__; as such, __init__ doesn't need to check them again.
Comment 6 Simon McVittie 2010-02-18 08:59:40 UTC
(In reply to comment #4)
> I am thinking maybe the server.c or Server.py has the same problem.

Good thinking, but actually no: Server.__init__ doesn't chain up to _Server's tp_init (and hence object.__init__).

However, Server use will provoke the same warning whenever a Server instantiates a Connection (is that what you meant?)
Comment 7 Huang Peng 2010-02-18 09:11:52 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > I am thinking maybe the server.c or Server.py has the same problem.
> 
> Good thinking, but actually no: Server.__init__ doesn't chain up to _Server's
> tp_init (and hence object.__init__).
> 
> However, Server use will provoke the same warning whenever a Server
> instantiates a Connection (is that what you meant?)
> 

In commnet #2, you don't think removing __init__ in connection.py is a right solution, but the Server.py does not call __init__ too, and it avoids the same problem. I mean maybe it is better to avoid the same problem by same solution.
Comment 8 Simon McVittie 2010-02-18 10:26:10 UTC
Fixed in 0.83.1


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.