Hi all - For the intrepid, I've checked in a number of fixes to things that have come up on the list: - Events refactored, -= now works for internalcalls, events are no longer directly callable (use OnSomeEvent(...) instead) - Implicit assembly loading now uses the PYTHONPATH to find assemblies. This means you can just add to sys.path to use an assembly that doesn't live in appbase or the GAC - Fixed a dumb bug in constructor handling that could cause you to get an 'IntPtr.Zero' instance rather than an exception in some cases when instantiating an object (this was the root of Michael's Point subclassing problem) If any of these are holding you up, you can get the fixes from CVS. I'm going to try to make a b2 tonight if the baby holds off for one more day :) Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
- Fixed a dumb bug in constructor handling that could cause you to get an 'IntPtr.Zero' instance rather than an exception in some cases when instantiating an object (this was the root of Michael's Point subclassing problem) ... Hi Brian,
Brian Lloyd wrote: ... the bug in constructor handling is fixed: (running beta 2) Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import CLR from CLR.System.Drawing import Point class P(Point): ... def __repr__(self): ... return 'P(%s,%s)' % (self.X, self.Y) ... p=P() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: no constructor matches given arguments
But there is still some strange behavior:
p=P(0,0) p.__repr__() 'P(0,0)'
Fine, but ...
repr(p) '<CLR.P object at 0x008ED930>'
Why? Michael
But there is still some strange behavior:
p=P(0,0) p.__repr__() 'P(0,0)'
Fine, but ...
repr(p) '<CLR.P object at 0x008ED930>'
Why?
Michael
The short answer is that there is still some work to do in type generation for subclasses of reflected types. The long answer :) is that right now the "magic" methods (__something__) that are related to C "slots" in the Python type object aren't dispatched correctly. There is a _lot_ of code in the C runtime to fixup these slots correctly, but it isn't exposed in a very convenient way and I'm trying to work out the exact right dance to trick the runtime into doing it for me rather than having to reimplement it. This is one of the next things on my list, so hopefully b3 will resolve it. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
participants (2)
-
Brian Lloyd -
Michael.Amrhein＠t-online.de