Re: [Pyobjc-dev] Headache over hacking an XML editor

[Just v. R. <ju...@le...>]

bb...@ma... wrote:

> >         self = cls.alloc()
> >         self.release()  # ownership transferred to the Python
wrapper
> >         return self
> 
> This code is lacking the call to the -init method -- problematic.

I was thinking of this pattern, which is not 100% Pythonic, yet 100%
better than having to do a release() "by hand":

  inst = ASubclassOfNSObject().init()

So basically "i = cls()" is equivalent to "i = cls.alloc();
i.release()".

> What about arguments to the constructor?  We can handle the no
> argument case transparently, but what about-- say-- NSView's
> -initWithFrame: designated initializer?

  aView = NSView().initWithFrame(...)

> Also, keep in mind that -init* methods return an object reference for
> a reason;  a number of intializers return a different instance than
> the one that was called for a number of [valid] reasons.

Solved above ;-)

> > This doesn't touch the alloc() semantics, yet provides a much more
> > Pythonic way to create instances. Heck, this will even call
> > __init__() for you! ;-)
> 
> But __init__() is not generally the designated intiailizer for ObjC
> classes-- even Python implemented subclasses of ObjC classes.
>
> When subclassing ObjC from Python, it makes more sense to follow the
> ObjC semantics than the Python semantics -- at least, it does to me.

Sure, but calling __init__ won't hurt either if you're writing an
NSObject subclass solely to be instantiated from Python. But I'm afraid
this behavior is implicit in the Python object protocol (since 2.2). I
_think_ it's this:

    inst = cls.__new__(cls, *args, **kwargs)
    if isinstance(inst, cls):
        inst.__init__(*args, **kwargs)

(I also think it's identical for tp_new/tp_init on the C side.)

Just