From brian at zope.com  Mon Oct 27 22:28:58 2003
From: brian at zope.com (Brian Lloyd)
Date: Mon Oct 27 22:29:47 2003
Subject: [Python.NET List] Test message
Message-ID: <INENIOEOCHPHGHKLFLOLMEMBCCAA.brian@zope.com>

its aliiiiivvvvve....


Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716              
Zope Corporation   http://www.zope.com 


From david.powell at kcl.ac.uk  Tue Oct 28 11:02:49 2003
From: david.powell at kcl.ac.uk (david Powell)
Date: Tue Oct 28 11:24:50 2003
Subject: [Python.NET] Problem installing
Message-ID: <000001c39d6c$fbbfb6a0$6d244989@STR12B1>

First, thanks for a very exciting development.

 

I downloaded the files.  I can run the demo in your version of python but
not in my existing version of python 2.3.

I followed the instructions:-

 

    "Yes, at least on win32 systems. Just copy the files Python.Runtime.dll 

    and CLR.dll from the PythonNet directory to the root directory of your

    python installation."

 

I get the error

 

 

D:\Python23>python d:\pythonnet\pythonnet-1.0-beta1\demo\helloform.py

Traceback (most recent call last):

  File "d:\pythonnet\pythonnet-1.0-beta1\demo\helloform.py", line 12, in ?

    import CLR.System.Windows.Forms as WinForms

ImportError: No module named System.Windows.Forms

 

Any help very much appreciated.

 

David

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20031028/08c24fe3/attachment.html
From brian at zope.com  Tue Oct 28 11:48:36 2003
From: brian at zope.com (Brian Lloyd)
Date: Tue Oct 28 11:49:38 2003
Subject: [Python.NET] Problem installing
In-Reply-To: <000001c39d6c$fbbfb6a0$6d244989@STR12B1>
Message-ID: <INENIOEOCHPHGHKLFLOLKEMLCCAA.brian@zope.com>

> I downloaded the files.  I can run the demo in your version
> of python but not in my existing version of python 2.3.
>
> <snip>
>
> I get the error
>
>
> D:\Python23>python d:\pythonnet\pythonnet-1.0-beta1\demo\helloform.py
> Traceback (most recent call last):
>   File "d:\pythonnet\pythonnet-1.0-beta1\demo\helloform.py", line 12, in ?
>     import CLR.System.Windows.Forms as WinForms
> ImportError: No module named System.Windows.Forms
>
> Any help very much appreciated.

Ahhhh - this appears to be related to a particular frailty of the
import hook I use, and the fact that what happens the first time
you 'import CLR' is slightly different when you run using the
managed wrapper vs. the extension module.

I'll take a look at it - in the meantime you can just add an
'import CLR' line above the other imports in the demo scripts
to get around the problem.


Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716
Zope Corporation   http://www.zope.com
David


From amos at aracnet.com  Tue Oct 28 13:46:56 2003
From: amos at aracnet.com (Amos Latteier)
Date: Tue Oct 28 13:53:08 2003
Subject: [Python.NET] Problem installing
Message-ID: <5.1.1.6.0.20031028104401.00ad7e88@mail.aracnet.com>

david Powell wrote:
 >I downloaded the files. I can run the demo in your version of python but
 >not in my existing version of python 2.3.

That's to be expected. Your existing python 2.3 doesn't connect to dot net. 
That's what Brian's Python does.

-Amos


From brian at zope.com  Tue Oct 28 14:07:31 2003
From: brian at zope.com (Brian Lloyd)
Date: Tue Oct 28 14:08:44 2003
Subject: [Python.NET] Problem installing
In-Reply-To: <5.1.1.6.0.20031028104401.00ad7e88@mail.aracnet.com>
Message-ID: <INENIOEOCHPHGHKLFLOLCEMPCCAA.brian@zope.com>

> david Powell wrote:
>  >I downloaded the files. I can run the demo in your version of python but
>  >not in my existing version of python 2.3.
>
> That's to be expected. Your existing python 2.3 doesn't connect
> to dot net.
> That's what Brian's Python does.
>
> -Amos

Actually, you can connect your existing Python as of beta 1.

There is a subtle issue in that configuration though. We install an
import hook to lazily load CLR namespaces. This works fine if you run
via the managed wrapper, because the import hook is installed before
you actually try to import something.

If you use the new CLR.dll with your existing Python, the act of
importing CLR causes the import hook to be installed. This is also
fine, as long as you do:

  import CLR # installs the hook
  from CLR.System import Something

The problem is when you do just:

  from CLR.System import Something

In this case, the standard Python importer is in control at the
time CLR is imported, so though the hook is installed, this first
import will fail if it tries to import sub-names.

I have a hack in mind that will fix it if need be - ideally I'll
have time to change the current import hook to the new blessed
way of hacking import in 2.3, which may also be a way to fix it.


Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716
Zope Corporation   http://www.zope.com



From david.powell at kcl.ac.uk  Wed Oct 29 04:53:00 2003
From: david.powell at kcl.ac.uk (david Powell)
Date: Wed Oct 29 05:03:41 2003
Subject: [Python.NET] Dragging the window
Message-ID: <000001c39e02$7e3128e0$6d244989@STR12B1>

When I drag the window of the demo applications I get a trail of Windows.
That is to say the area exposed by moving the window is not being repainted.
I have seen the same problem with wxPython.  Any comments?

 

David

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20031029/9b9bfd91/attachment.html
From felix_mcallister at hotmail.com  Wed Oct 29 07:36:56 2003
From: felix_mcallister at hotmail.com (Felix McAllister)
Date: Wed Oct 29 07:36:59 2003
Subject: [Python.NET] Do assemblies need to be placed into the GAC
Message-ID: <Law10-F53xivGHBoxS600002e62@hotmail.com>

Hi,

I'd like to use PythonNet to script some .NET assemblies we have. Must I 
place these into the GAC? I've tried to put the python script into the same 
directory as the assembly DLL but this doesn't work:

C:\dev\python\PythonNetTest\bin\Debug>python
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
>>>import CLR.PythonNetTest
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named PythonNetTest
>>>import CLR.PythonNetTest.MyTest
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named PythonNetTest
>>>


TIA,

Felix.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


From brian at zope.com  Wed Oct 29 09:30:34 2003
From: brian at zope.com (Brian Lloyd)
Date: Wed Oct 29 09:32:25 2003
Subject: [Python.NET] Do assemblies need to be placed into the GAC
In-Reply-To: <Law10-F53xivGHBoxS600002e62@hotmail.com>
Message-ID: <INENIOEOCHPHGHKLFLOLOENDCCAA.brian@zope.com>

> I'd like to use PythonNet to script some .NET assemblies we have. Must I 
> place these into the GAC? I've tried to put the python script 
> into the same 
> directory as the assembly DLL but this doesn't work:

Hi Felix - 

Right now to import an assembly it either needs to be in the GAC 
or in the "application directory" or a subdirectory thereof.

When running python, the application directory is the directory 
where python.exe lives, not the place where the script you are 
running lives.

One of the things I want to do for the final is see if there is 
a way to have the assembly loader use the python path (sys.path) 
when looking for assemblies.


Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716              
Zope Corporation   http://www.zope.com 



From brian at zope.com  Wed Oct 29 09:42:30 2003
From: brian at zope.com (Brian Lloyd)
Date: Wed Oct 29 09:43:45 2003
Subject: [Python.NET] Dragging the window
In-Reply-To: <000001c39e02$7e3128e0$6d244989@STR12B1>
Message-ID: <INENIOEOCHPHGHKLFLOLGENECCAA.brian@zope.com>

> When I drag the window of the demo applications I get a trail of 
> Windows.  That is to say the area exposed by moving the window is 
> not being repainted.  I have seen the same problem with wxPython.  
> Any comments?
> 
> David

Interesting - what OS are you running? I don't see this on XP 
with CLR v1.1.

It could also a bug in the app, though I cribbed much of it from 
existing C# example code and don't see anything obvious.

If anyone else is seeing this behavior, let us know - maybe we 
can find some common thread to explain it...


Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716             
Zope Corporation   http://www.zope.com


From felix_mcallister at hotmail.com  Wed Oct 29 10:00:56 2003
From: felix_mcallister at hotmail.com (Felix McAllister)
Date: Wed Oct 29 10:01:01 2003
Subject: [Python.NET] Do assemblies need to be placed into the GAC
Message-ID: <Law10-F42HyQOcgtRab0001fd4a@hotmail.com>

Brian,

Thanks for that. We don't currently put our assemblies into the GAC because 
our ASP.NET app can (theoretically) support multiple versions on the one 
server machine. Each version lives in a separate sub-directory that then 
contains a 'bin' directory for the assembly DLLs.

Although you *can* put multiple versions of the same component into the GAC 
(as long as the AssemblyVersion number is different), how would Python.NET 
distinguish these?

Felix.

>From: "Brian Lloyd" <brian@zope.com>
>To: "Felix McAllister" <felix_mcallister@hotmail.com>,   
><pythondotnet@python.org>
>Subject: RE: [Python.NET] Do assemblies need to be placed into the GAC
>Date: Wed, 29 Oct 2003 09:30:34 -0500
>
> > I'd like to use PythonNet to script some .NET assemblies we have. Must I
> > place these into the GAC? I've tried to put the python script
> > into the same
> > directory as the assembly DLL but this doesn't work:
>
>Hi Felix -
>
>Right now to import an assembly it either needs to be in the GAC
>or in the "application directory" or a subdirectory thereof.
>
>When running python, the application directory is the directory
>where python.exe lives, not the place where the script you are
>running lives.
>
>One of the things I want to do for the final is see if there is
>a way to have the assembly loader use the python path (sys.path)
>when looking for assemblies.
>
>
>Brian Lloyd        brian@zope.com
>V.P. Engineering   540.361.1716
>Zope Corporation   http://www.zope.com
>
>

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus


From brian at zope.com  Wed Oct 29 10:38:51 2003
From: brian at zope.com (Brian Lloyd)
Date: Wed Oct 29 10:40:28 2003
Subject: [Python.NET] Do assemblies need to be placed into the GAC
In-Reply-To: <Law10-F42HyQOcgtRab0001fd4a@hotmail.com>
Message-ID: <INENIOEOCHPHGHKLFLOLGENFCCAA.brian@zope.com>

> Thanks for that. We don't currently put our assemblies into the 
> GAC because 
> our ASP.NET app can (theoretically) support multiple versions on the one 
> server machine. Each version lives in a separate sub-directory that then 
> contains a 'bin' directory for the assembly DLLs.
> 
> Although you *can* put multiple versions of the same component 
> into the GAC 
> (as long as the AssemblyVersion number is different), how would 
> Python.NET 
> distinguish these?

Right now it uses Assembly.LoadWithPartialName, which seems (the 
docs are vague on this) to load the most recent version of an 
assembly that it can find.

The ability to side-by-side load different versions of assemblies 
is one of the (relatively few) places where the matching of meta-models 
between Python and the CLR breaks down.

Because Python import is name-based and unaware of any concept of 
versioned modules, my goal has been for 'implicit assembly loading' 
(loading as a result of import) to do something consistent and 
reasonable (i.e. load most recent available based on name).

It is possible to load a specific version of an assembly - you would 
do something like:

  from CLR.System.Reflection import Assembly, AssemblyName

  name = AssemblyName(...) # set required version, etc.
  assembly = Assembly.Load(name)

  # now import namespaces from the loaded assembly


Things get a lot more complicated if you need to load more than one 
version of a particular assembly (or more likely, you have a dependency 
on some library the does so). In this case, the names you access via 
the CLR modules will always come from the first version of the 
assembly loaded (which will always win in the internals of the runtime).

That doesn't mean that you're hosed though - you just have to do 
more work to get the right versions of objects, a la:

  from CLR.System.Reflection import Assembly, AssemblyName
  from System import Activator

  name = AssemblyName(...) # get the right version
  assembly = Assembly.Load(name)
  type = assembly.GetType("QualifiedNameOf.TheTypeINeed")
  obj = Activator.CreateInstance(type)


Hope that helps somewhat. BTW, these are all great questions and 
I'm making notes to put these things in the faq / docs :^)


Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716              
Zope Corporation   http://www.zope.com


From Michael.Amrhein at t-online.de  Wed Oct 29 14:04:11 2003
From: Michael.Amrhein at t-online.de (Michael Amrhein)
Date: Wed Oct 29 14:04:43 2003
Subject: [Python.NET] System.NullReferenceException
Message-ID: <3FA00F2B.6010502@t-online.de>

Hi,
when unregistering an event handler I get an exection:

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
 >>> import CLR.System.Windows.Forms as wf
 >>> f=wf.Form()
 >>> f
<CLR.System.Windows.Forms.Form object at 0x008FE6D0>
 >>> def h(s,a): print s,a
...
 >>> f.Click += h
 >>> f.Click -= h

Unbehandelte Ausnahme: System.NullReferenceException: Der Objektverweis 
wurde nicht auf eine Objektinstanz festgelegt.
    at Python.Runtime.EventObject.RemoveEventHandler(IntPtr target, 
IntPtr handler)
    at Python.Runtime.EventBinding.nb_inplace_subtract(IntPtr ob, IntPtr 
arg)

The same happens when I try to call the event.

The demo apps run without any problem; i.e. Python event handlers are 
called correctly by the CLR. But trying to unregister the event handler 
in helloform.py:
...
     WinForms.MessageBox.Show("Please do not press this button again.")
     self.button.Click -= self.button_Click

causes the same exception as shown above.

Michael

P.S.: I run CLR v1.1 on Win XP


From brian at zope.com  Wed Oct 29 21:12:24 2003
From: brian at zope.com (Brian Lloyd)
Date: Wed Oct 29 21:13:46 2003
Subject: [Python.NET] System.NullReferenceException
In-Reply-To: <3FA00F2B.6010502@t-online.de>
Message-ID: <INENIOEOCHPHGHKLFLOLGENLCCAA.brian@zope.com>

> Hi,
> when unregistering an event handler I get an exection:
> 
> 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
>  >>> import CLR.System.Windows.Forms as wf
>  >>> f=wf.Form()
>  >>> f
> <CLR.System.Windows.Forms.Form object at 0x008FE6D0>
>  >>> def h(s,a): print s,a
> ...
>  >>> f.Click += h
>  >>> f.Click -= h

Ah - what a wonderful, horrible experience its been, learning all 
about these little nits of the CLR :)

This seems to be related to events that are implemented using 
internalcall magic. The correct 'official' reflection api one is 
supposed to use to ignore these details is totally broken in both 
CLR 1.0 & 1.1, and it seems that my workaround needs some more 
work ;^/

I've added a (currently failing) unit test to make sure it gets 
looked at.

Thanks!



Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716              
Zope Corporation   http://www.zope.com 



From F.Boonstra at inter.nl.net  Thu Oct 30 02:33:34 2003
From: F.Boonstra at inter.nl.net (Folkert Boonstra)
Date: Thu Oct 30 04:34:45 2003
Subject: [Python.NET] Do assemblies need to be placed into the GAC
In-Reply-To: <INENIOEOCHPHGHKLFLOLGENFCCAA.brian@zope.com>
References: <INENIOEOCHPHGHKLFLOLGENFCCAA.brian@zope.com>
Message-ID: <3FA0BECE.7020701@inter.nl.net>

Brian Lloyd wrote:

>>Thanks for that. We don't currently put our assemblies into the 
>>GAC because 
>>our ASP.NET app can (theoretically) support multiple versions on the one 
>>server machine. Each version lives in a separate sub-directory that then 
>>contains a 'bin' directory for the assembly DLLs.
>>
>>Although you *can* put multiple versions of the same component 
>>into the GAC 
>>(as long as the AssemblyVersion number is different), how would 
>>Python.NET 
>>distinguish these?
>>    
>>
>
>Right now it uses Assembly.LoadWithPartialName, which seems (the 
>docs are vague on this) to load the most recent version of an 
>assembly that it can find.
>
>The ability to side-by-side load different versions of assemblies 
>is one of the (relatively few) places where the matching of meta-models 
>between Python and the CLR breaks down.
>
>Because Python import is name-based and unaware of any concept of 
>versioned modules, my goal has been for 'implicit assembly loading' 
>(loading as a result of import) to do something consistent and 
>reasonable (i.e. load most recent available based on name).
>
>It is possible to load a specific version of an assembly - you would 
>do something like:
>
>  from CLR.System.Reflection import Assembly, AssemblyName
>
>  name = AssemblyName(...) # set required version, etc.
>  assembly = Assembly.Load(name)
>
>  # now import namespaces from the loaded assembly
>
>
>Things get a lot more complicated if you need to load more than one 
>version of a particular assembly (or more likely, you have a dependency 
>on some library the does so). In this case, the names you access via 
>the CLR modules will always come from the first version of the 
>assembly loaded (which will always win in the internals of the runtime).
>
>That doesn't mean that you're hosed though - you just have to do 
>more work to get the right versions of objects, a la:
>
>  from CLR.System.Reflection import Assembly, AssemblyName
>  from System import Activator
>
>  name = AssemblyName(...) # get the right version
>  assembly = Assembly.Load(name)
>  type = assembly.GetType("QualifiedNameOf.TheTypeINeed")
>  obj = Activator.CreateInstance(type)
>
>
>Hope that helps somewhat. BTW, these are all great questions and 
>I'm making notes to put these things in the faq / docs :^)
>
>
>Brian Lloyd        brian@zope.com
>V.P. Engineering   540.361.1716              
>Zope Corporation   http://www.zope.com
>
>
>_________________________________________________
>Python.NET mailing list - PythonDotNet@python.org
>http://mail.python.org/mailman/listinfo/pythondotnet
>  
>
Hi,

Without knowing too much about the PythonDotNet environment (yet) I have 
just a general observation.
Shouldn't the versioning knowledge be kept out of the source code? Totally!?
When the containers/assemblies are instantiated the actual binding to a 
specific version should take place.
Isn't there functionality in the assemblies to deal with that?

regards,
Folkert




From Michael.Amrhein at t-online.de  Thu Oct 30 17:48:39 2003
From: Michael.Amrhein at t-online.de (Michael Amrhein)
Date: Thu Oct 30 17:49:04 2003
Subject: [Python.NET] Subclassing CLR types
Message-ID: <3FA19547.40604@t-online.de>

Hi,
subclassing CLR types does work as long as you hold a reference to the 
instance of the subclass in Python. But when you pass a subclassed 
object to a CLR object and retrieve this object later through a method 
of the CLR object you don't get an instance of the subclass but an 
instance of the CLR base class the subclass was derived from:

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.Windows.Forms import Control
 >>> c=Control("This is a Control.")
 >>> class myControl(Control):
...     def dummy(self):
...             return self.Text
...
 >>> m=myControl(c, "This is a myControl.")
 >>> m.Parent
<CLR.System.Windows.Forms.Control object at 0x008F6F70>
 >>> m.Parent.Text
u'This is a Control.'
 >>> c.Contains(m)
True
 >>> m.dummy()
u'This is a myControl.'
 >>> c.Controls[0] == m
True

[Every thing ok, so far, but ...]

 >>> c.Controls[0].dummy()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'Control' object has no attribute 'dummy'

[Because ...]

 >>> type(c.Controls[0])
<class 'CLR.System.Windows.Forms.Control'>

This is weird because it means that when I get back an instance of a 
subclass from some CLR method I don't know the correct type and can not 
act on it properly.

I don't know if there's an easy way to come around this problem but to 
me subclassing of CLR types seemes pretty useless without a solution for it.

If there is some kind of unique reference from the Python wrapper 
instances to the CLR instances a starting point for a solution may be to 
base all wrappers on a base type which keeps a mapping of referenced CLR 
instances to wrapper instances.

Something like this (all not tested yet!!!):

class CLRObj(object):

     from weakref import WeakValueDictionary

     __objMap = WeakValueDictionary()

     def __new__(cls, ref):
         try:
             obj = clrObj.__objMap[ref]
         except KeyError:
             obj = object.__new__(cls)
             obj._ref = ref
             clrObj.__objMap[ref] = obj
         return obj

     def __del__(self):
         self._ref.Dispose()

class <wrapper>(CLRObj):

     def __new__(cls, ...):
         ref = <create base CLR type>
         return CLRObj.__new__(cls, ref)

... and when receiving a CLR instance turn it into the corresponding 
wrapper instance by

obj = CLRObj(clrObj)

This will not work if you receive some kind of CLR object which was 
created internally by some CLR method and not through a wrapper. But you 
will get all object you created through the wrappers back as instances 
of the correct type.

If I'm galloping in the wrong direction please give me a short stop 
signal. If not ... lets figure out the probably missing details.

Michael


From brian at zope.com  Thu Oct 30 19:55:02 2003
From: brian at zope.com (Brian Lloyd)
Date: Thu Oct 30 19:57:26 2003
Subject: [Python.NET] Subclassing CLR types
In-Reply-To: <3FA19547.40604@t-online.de>
Message-ID: <INENIOEOCHPHGHKLFLOLOEOKCCAA.brian@zope.com>

> Hi,
> subclassing CLR types does work as long as you hold a reference to the 
> instance of the subclass in Python. But when you pass a subclassed 
> object to a CLR object and retrieve this object later through a method 
> of the CLR object you don't get an instance of the subclass but an 
> instance of the CLR base class the subclass was derived from:
>
> <snip good stuff>
> 
> This will not work if you receive some kind of CLR object which was 
> created internally by some CLR method and not through a wrapper. But you 
> will get all object you created through the wrappers back as instances 
> of the correct type.
> 
> If I'm galloping in the wrong direction please give me a short stop 
> signal. If not ... lets figure out the probably missing details.
> 
> Michael

Hi Michael -

The implementation already does most of what you outlined internally 
using GCHandles - the part that's missing is the lookup to recognize 
a previously wrapped instance. I think that will be straightforward 
to add.

I'll turn your test case into a unit test and try to make sure b2 
solves it.

oooo - right before I sent this, I had a thought that I should 
probably bounce off of the list to see if anyone can see any holes 
in it.

Right now, the subclassing is "shallow" in that you get a subclass 
in Python, but on the managed side the object is of whatever class 
you based from.

I'd like for Python classes to be able to implement abstract .NET 
classes & interfaces at some point, and the way I was planning to 
do that is to generate a real managed subclass whenever you subclass 
a managed class. That will allow for Python implementation of virtuals, 
etc., but it also has the nice side effect that the internals can 
always recognize things subclassed in Python w/o big nasty handle 
mappings.

I can probably implement that basic 'real subclass per Python subclass' 
as easily as the handle mapper, so that might be the way to solve 
this (and take a step to better integration to boot).




Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716              
Zope Corporation   http://www.zope.com 


From Michael.Amrhein at t-online.de  Fri Oct 31 03:27:18 2003
From: Michael.Amrhein at t-online.de (Michael Amrhein)
Date: Fri Oct 31 03:27:54 2003
Subject: [Python.NET] Subclassing CLR types
In-Reply-To: <INENIOEOCHPHGHKLFLOLOEOKCCAA.brian@zope.com>
References: <INENIOEOCHPHGHKLFLOLOEOKCCAA.brian@zope.com>
Message-ID: <3FA21CE6.7050905@t-online.de>

Brian Lloyd wrote:
[snip]
> Right now, the subclassing is "shallow" in that you get a subclass 
> in Python, but on the managed side the object is of whatever class 
> you based from.
> 
> I'd like for Python classes to be able to implement abstract .NET 
> classes & interfaces at some point, and the way I was planning to 
> do that is to generate a real managed subclass whenever you subclass 
> a managed class. That will allow for Python implementation of virtuals, 
> etc., but it also has the nice side effect that the internals can 
> always recognize things subclassed in Python w/o big nasty handle 
> mappings.
> 
> I can probably implement that basic 'real subclass per Python subclass' 
> as easily as the handle mapper, so that might be the way to solve 
> this (and take a step to better integration to boot).
> 

Hi Brian,
that sounds very very good!
I'm eagerly waiting for beta 2 :-)
Michael


From Michael.Amrhein at t-online.de  Fri Oct 31 17:21:04 2003
From: Michael.Amrhein at t-online.de (Michael Amrhein)
Date: Fri Oct 31 17:21:57 2003
Subject: [Python.NET] Subclassing again
Message-ID: <3FA2E050.2030606@t-online.de>

Hi,
there seem to be some more issues with subclassing.
I just stumble over the following:

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()
 >>> p
<CLR.P object at 0x008EDA30>
 >>> repr(p)
'<CLR.P object at 0x008EDA30>'

P.__repr__ not called ?!?

 >>> p.X
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: Das Objekt stimmt mit dem Zieltyp nicht ?berein.
(saying: The object does not match the target type.)

Point methods can't be invoked on P instance ?!?

Any ideas?

Michael