Thanks a lot Noufal, I was just missing overloading object (i got remind of this after checking your mail only) class in mine. Thanks for the info in such detail.
Nitin K On Wed, Apr 6, 2011 at 6:41 PM, Noufal Ibrahim <nou...@gmail.com> wrote: > > You're opening up can of worms here but I'll try to sort it out since > I'm feeling messed up anyway. > > First : Old style and new style classes > --------------------------------------- > "class X:" in Python 2.x creates an old style class[1] > > These classes were distinct from builtin "type"s. All such classes were > of type "classobj" and instances would be of type "instance". > > "class X(object):" in Python 2.x creates a new style class[1] > > for which the class is of type 'type' which is ultimately the root of > for all the builtin types as well. Instances would have the class as > their type. So if you do > > x = X() > > and then ask for the type of X, you'd get "class X" for new style and > "instance" for old style. > > With Python 3, the old style class was dropped and no longer > supported. A plain class declaration would create a new style class. > > In your example, the 2.x variant is using an old style class and the 3.x > one a new style class. Replacing your 2.x definition with > > class x(object): > > will create a new style class that will work in the same way as with > Python 3. > > Second : The __new__ and __init__ methods > ----------------------------------------- > > The __new__ method is an allocator. It "creates" the object. The > __init__ method is an "initialiser" and might not always be called > (e.g. while depickling). It will initialise the object created. > > Python semantics[2] state that if your __new__ method returns an object > of a type different from the class it's allocating, the __init__ method > will not be called. That's what's happening in your situation. > > Now, why is this not happening for old style classes? Well, I need to > dig into the source to confirm this but one of the things that was added > when they moved to new style classes (after 2.1 I think) is hooks that > allow overriding of the allocation process. This made metaclasses and > all that possible. This is not the case with old style classes where the > allocator was not even exposed. > > > >>> class F: > ... def __new__(cls): > ... print "Hello" > ... return 5 > ... > >>> F() > <__main__.F instance at 0x7fa759a4e908> > >>> > > > will not even print the "Hello" since there was no __new__. > > Thirdly : What are you trying to do? > ------------------------------------ > > Why do you want to create a class that doesn't create itself when > called? I'm not chastising you but most situations where this kind of > thing is done are interesting and I'm curious to know more. > > > On Wed, Apr 06 2011, Nitin Kumar wrote: > > > Hi All, > > > > I am looking for a return value when an object is created. > > but can see different behavior in different python version. > > > > Python 3 gives > >>>> class x: > > def __new__(self): > > return 5 > > > >>>> x() > > 5 > > > > > > Python 2.6.5 gives > >>>> class x: > > def __new__(self): > > return 5 > > > >>>> x() > > <__main__.x instance at 0x017CFD00> > > > > I need to use 2.6 only, so how to achieve the same functionality as in > > python 3. > > > Footnotes: > [1] http://docs.python.org/release/2.5.2/ref/node33.html > > [2] http://docs.python.org/reference/datamodel.html#object.__new__ > > -- > _______________________________________________ > BangPypers mailing list > BangPypers@python.org > http://mail.python.org/mailman/listinfo/bangpypers > -- Nitin K _______________________________________________ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
