On Saturday, Nov 30, 2002, at 16:07 Europe/Amsterdam, Just van Rossum
> I needed to subclass NSObject and was a little confused that it
> doesn't by
> default behave more like a Python object. I wrote a __new__ method in
> subclass that does this:
> def __new__(cls, *args, **kwargs):
> return cls.alloc().init()
Cute. I knew this works, but didn't add this to PyObjC at the time
because I didn't put much effort into thinking about the usefullness of
this. On the one hand this does make Objective-C classes more like
Python classes, but on the other hand this introduces API differences
w.r.t. the Objective-C classes.
All in all I'm slightly in favor of adding an __new__ that does
'cls.alloc().init()' (but without optional and keyword arguments). It
might even be usefull to add more specialized versions of new for some
classes (e.g. to add keyword arguments that allow us to call a more
usefull version of init).
> Bug/Feature request:
> When an exception is raised in a method that is called by the objc
> runtime, only
> a very brief error is printed to Console.app. Can this be changed so
> it does
> PyErr_Print(), which prints a complete Python traceback? Oh, and
> _after_ the
> brief error is printed, the program usually crashes hard:
> 2002-11-30 15:31:22.990 python2.3 An uncaught exception was
> 2002-11-30 15:31:22.991 python2.3 No attribute allow
> 2002-11-30 15:31:22.992 python2.3 *** Uncaught exception:
> <OC_PythonException> No attribute allow
> Nov 30 15:27:25 python last message repeated 13 times
I'll look into this. What I'm currently thinking of:
1) objc.setVerbose(newValue) -> None
newValue is a boolean. If newValue is true the PyObjC runtime is
this includes calling PyErr_Print when translating from Python to
2) The exception raised when converting from Python to Objective-C
should always include the file+line where the exception was raised.
BTW. 'objc.setVerbose' should IMHO be a property ('objc.verbose = 1'
instead of 'objc.setVerbose(1)'), but I'm pretty sure that it is
impossible to add properties to a module without subclassing
types.ModuleType. This is too bad because module-properties would be a
neat way to proxy global variables in Objective-C frameworks.