From myeates at jpl.nasa.gov  Wed May 10 01:25:34 2006
From: myeates at jpl.nasa.gov (Mathew Yeates)
Date: Tue, 09 May 2006 16:25:34 -0700
Subject: [Python.NET] Hello??
Message-ID: <446124EE.1060204@jpl.nasa.gov>

Anybody out there? Did this list die?

Mathew


From roman.yakovenko at gmail.com  Wed May 10 06:51:20 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 10 May 2006 07:51:20 +0300
Subject: [Python.NET] Hello??
In-Reply-To: <446124EE.1060204@jpl.nasa.gov>
References: <446124EE.1060204@jpl.nasa.gov>
Message-ID: <7465b6170605092151v7f773016ue56f9c8367c38558@mail.gmail.com>

On 5/10/06, Mathew Yeates <myeates at jpl.nasa.gov> wrote:
> Anybody out there?

Yes

> Did this list die?

No

> Mathew
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>


--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From tiago.matias at gmail.com  Wed May 10 22:54:55 2006
From: tiago.matias at gmail.com (Tiago Matias)
Date: Wed, 10 May 2006 21:54:55 +0100
Subject: [Python.NET] Problem passing parameters to a python function from C#
Message-ID: <26ba25660605101354q4daec141p4feaf7cba1fa9720@mail.gmail.com>

Hi all!

I'm trying to invoke a python function from a .NET application. The C# code
is this:

string templateFile = "Simple.tpl";
 PythonEngine.Initialize();

PyObject module = PythonEngine.ImportModule("Engine");
PyObject method = module.GetAttr("FillTemplate");
PyObject result = method.Invoke(PyObject.FromManagedObject(templateFile));

Console.WriteLine(result.ToString());

and the python module is simply:

from Cheetah.Template import Template

def FillTemplate(templateName):
        template = Template(file=templateName)

        return template


Now, the problem is the parameter. If I hardcode "Simple.tpl" in the
constructor everything works as expected. Also, if I change the python code
to "return templateName" I get "Simple.tpl" back in the C# code.

But, if I run the code above a PythonException is thrown....I've also tried
to place a try...except block around the code but it didn't caught any
exception... I suspect that I must be calling the PyObject.Invoke() function
with the wrong arguments...

Essentially the purpose of this is to generate C# code with the help of
cheetah templates. The ideia is to construct an object containing the
metadata and then pass it to cheetah to generate code.

But I can't seem to be able to pass a simple string!

Any help would be grealty appreciated! Btw, bear in mind that this is my
first attempt with python... so the question maybe stupid ;)


Thanks in advance!

Tiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20060510/24d833b2/attachment.htm 

From brian.d.lloyd at gmail.com  Fri May 12 15:08:58 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Fri, 12 May 2006 09:08:58 -0400
Subject: [Python.NET] Problem passing parameters to a python function
	from C#
In-Reply-To: <26ba25660605101354q4daec141p4feaf7cba1fa9720@mail.gmail.com>
References: <26ba25660605101354q4daec141p4feaf7cba1fa9720@mail.gmail.com>
Message-ID: <1c0b4a390605120608t3d1d2fafp5d502ed6c828eaa8@mail.gmail.com>

HI Tiago -

If I'm reading this right, I think the issue is that your method is
returning
a (Python) Template instance.

The PythonNet runtime can't convert arbitrary Python types to anything
that .NET can make sense of, so your method need to either return a
"primitive" Python type that maps to a primitive .NET type (string, int,
etc.), or a wrapped .NET object.

Try returning str(template), and I bet you'll get the string result on the
other side.

Hope this helps,

Brian

On 5/10/06, Tiago Matias <tiago.matias at gmail.com> wrote:
>
> Hi all!
>
> I'm trying to invoke a python function from a .NET application. The C#
> code is this:
>
> string templateFile = "Simple.tpl";
>  PythonEngine.Initialize();
>
> PyObject module = PythonEngine.ImportModule("Engine");
> PyObject method = module.GetAttr("FillTemplate");
> PyObject result = method.Invoke(PyObject.FromManagedObject(templateFile));
>
> Console.WriteLine(result.ToString());
>
> and the python module is simply:
>
> from Cheetah.Template import Template
>
> def FillTemplate(templateName):
>         template = Template(file=templateName)
>
>         return template
>
>
> Now, the problem is the parameter. If I hardcode "Simple.tpl" in the
> constructor everything works as expected. Also, if I change the python code
> to "return templateName" I get "Simple.tpl" back in the C# code.
>
> But, if I run the code above a PythonException is thrown....I've also
> tried to place a try...except block around the code but it didn't caught any
> exception... I suspect that I must be calling the PyObject.Invoke()
> function with the wrong arguments...
>
> Essentially the purpose of this is to generate C# code with the help of
> cheetah templates. The ideia is to construct an object containing the
> metadata and then pass it to cheetah to generate code.
>
> But I can't seem to be able to pass a simple string!
>
> Any help would be grealty appreciated! Btw, bear in mind that this is my
> first attempt with python... so the question maybe stupid ;)
>
>
> Thanks in advance!
>
> Tiago
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20060512/960146e8/attachment.htm 

From brian.d.lloyd at gmail.com  Fri May 12 15:12:02 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Fri, 12 May 2006 09:12:02 -0400
Subject: [Python.NET] Hello??
In-Reply-To: <7465b6170605092151v7f773016ue56f9c8367c38558@mail.gmail.com>
References: <446124EE.1060204@jpl.nasa.gov>
	<7465b6170605092151v7f773016ue56f9c8367c38558@mail.gmail.com>
Message-ID: <1c0b4a390605120612l1fbcc507mfcd4897320073ae@mail.gmail.com>

No, we're not dead yet ;) Probably suffering a little oxygen deprivation
from IronPython, I suspect.

I've been plugging away in svn on a 2.0 release, though things have
become busy the last couple of weeks at that pesky day job.

-Brian

On 5/10/06, Roman Yakovenko <roman.yakovenko at gmail.com> wrote:
>
> On 5/10/06, Mathew Yeates <myeates at jpl.nasa.gov> wrote:
> > Anybody out there?
>
> Yes
>
> > Did this list die?
>
> No
>
> > Mathew
> >
> > _________________________________________________
> > Python.NET mailing list - PythonDotNet at python.org
> > http://mail.python.org/mailman/listinfo/pythondotnet
> >
>
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20060512/6742e9bf/attachment.html 

From dinov at exchange.microsoft.com  Mon May 22 22:24:45 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 22 May 2006 13:24:45 -0700
Subject: [Python.NET] [IronPython] Naming and resolution of generic
	types (complete!)
In-Reply-To: <65531D426735784F854EE658938A585302798CCA@MI8NYCMAIL03.Mi8.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEAEC7917@df-foxhound-msg.exchange.corp.microsoft.com>

I apologize for the extreme delay on this reply...  This mail got stuck in our mailing list somewhere and didn't come out until today.

The way we've chosen to solve this is to go w/ the single type that allows you to disambiguate after the fact.  If you have System.IComparable (another good example is System.Nullable which has both generic & non-generic versions) we build one 'type' that allows you to disambiguate using __getitem__.

This is the same way you need to get a generic instantiation (e.g. if there were no IComparable conflicts you'd need to do IComparable[int] to get the specific instantiation) so it fits in nicely.  Otherwise the type is the non-generic version.

It would seem our str/repr of this type is pretty bad right now (showing you only the generic version) - we should make that more helpful (e.g. something like <type IComparable, IComparable[T]> maybe ?).

I guess the other remaining issue is how to get access to the generic type that isn't bound to a specific instantiation - currently this isn't much of a problem w/ IronPython as there's not much you can actually do w/ the open generic type, but we should probably solve it long term.

I've opened 2 bugs - the first one (str/repr of the type) should be easy to fix, but some thought probably needs to go into the open generic type issue.  We could make some __ __ method to do this, allow indexing by None, or something else - neither of those sounds particularly wonderful.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Brian Lloyd
Sent: Friday, March 31, 2006 12:43 PM
To: pythondotnet at python.org
Cc: users at lists.ironpython.com
Subject: [IronPython] Naming and resolution of generic types (complete!)


Hi all - I'm cross-posting this to the IP list as the subject seems to
be an open issue there too.

I'm working on generics support for Python for .NET, and there a couple
of thorny issues that could use some discussion regarding naming and
resolution of generic types.

In C# you can explicitly name a generic type, a la Dictionary<,>. That
syntax won't work in Python, of course. Looking at IP, it seems to allow
the apparent Python name to be the unmangled IL name so you can
naturally use the name.

The problem is that the mangled name is illegal as a python name, and
the unmangled name isn't guaranteed to be unique - you can potentially
have any number of generic types as well as a non-generic type with the
same base name in the same namespace:

namespace Spam {

    public class SpamCan {}
    public class SpamCan<T> {}
    public class SpamCan<T, V> {}
    ...
}

I imagine that maybe IP has enough information available at compile-time
to do the right thing for some common usage (binding and instantiating
the types), but the overloaded name can still be ambiguous. A real-life
example of this is System.IComparable - in IP, it doesn't seem possible
to get to the non-generic version of IComparable anymore (or at least it
was not obvious to me how to do it):

>>> import System
>>> System.IComparable
<type 'IComparable`1'>

It seems like we need to figure out some acceptable way of spelling
generic type names explicitly in Python (an equivalent to IComparable<>
in C#) that works within the existing syntax.

There don't appear to be a lot of great options :( It has to be a valid
Python name to work in an import statement, so that rules out strange
operator shenanigans akin to the [] hack used for generic type binding.

One would be to mimic the existing IL mangling in some way, a la:

>From System import IComparable   # the non-generic type
>From System import IComparable_1 # the 1-param generic

# or
from System import IComparable_T
from System.Collections.Generic import Dictionary_TT

These are all pretty gross, and still don't totally prevent hiding of
legit non-generic classes with those names (though it makes it less
likely that names will be hidden than the current approach).

I suppose another approach would be to continue to have only one type
end up with the simple name, but provide a way to disambiguate it after
the fact:

>>> import System
>>> System.IComparable
<type 'IComparable`1'>

>>> # abandon all hope, ye who enter here...
>>> NonGenericIComparable = System.IComparable<<0
>>> OneParamGenericIComparable = System.IComparable<<1
>>> TwoParamVersionIfThereWasOne = System.IComparable<<2

That feels to me like it violates Python Zen in several ways, though.

Thoughts?


-Brian

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

From Brian.Lloyd at revolution.com  Tue May 23 18:16:48 2006
From: Brian.Lloyd at revolution.com (Brian Lloyd)
Date: Tue, 23 May 2006 12:16:48 -0400
Subject: [Python.NET] [IronPython] Naming and resolution of generic
 types (complete!)
Message-ID: <65531D426735784F854EE658938A5853038FAB97@MI8NYCMAIL03.Mi8.com>

Thanks for the reply - luckily this is pretty much where I ended 
up as well ;)

One unlikely-but-technically-possible edge case I ran into was:

  - user imports assembly A that contains the generic type
'foo.bar.SomeType'
  - user creates instances of that type
  - then the user imports assembly B that contributes the non-generic
type 
    'SomeType' to the namespace 'foo.bar'

Maybe that's not a problem for the IP implementation, but thought I'd 
note it just in case. 

-Brian



> -----Original Message-----
> From: pythondotnet-bounces at python.org 
> [mailto:pythondotnet-bounces at python.org] On Behalf Of Dino Viehland
> Sent: Monday, May 22, 2006 4:25 PM
> To: Discussion of IronPython; pythondotnet at python.org
> Subject: Re: [Python.NET] [IronPython] Naming and resolution 
> of generic types (complete!)
> 
> I apologize for the extreme delay on this reply...  This mail 
> got stuck in our mailing list somewhere and didn't come out 
> until today.
> 
> The way we've chosen to solve this is to go w/ the single 
> type that allows you to disambiguate after the fact.  If you 
> have System.IComparable (another good example is 
> System.Nullable which has both generic & non-generic 
> versions) we build one 'type' that allows you to disambiguate 
> using __getitem__.
> 
> This is the same way you need to get a generic instantiation 
> (e.g. if there were no IComparable conflicts you'd need to do 
> IComparable[int] to get the specific instantiation) so it 
> fits in nicely.  Otherwise the type is the non-generic version.
> 
> It would seem our str/repr of this type is pretty bad right 
> now (showing you only the generic version) - we should make 
> that more helpful (e.g. something like <type IComparable, 
> IComparable[T]> maybe ?).
> 
> I guess the other remaining issue is how to get access to the 
> generic type that isn't bound to a specific instantiation - 
> currently this isn't much of a problem w/ IronPython as 
> there's not much you can actually do w/ the open generic 
> type, but we should probably solve it long term.
> 
> I've opened 2 bugs - the first one (str/repr of the type) 
> should be easy to fix, but some thought probably needs to go 
> into the open generic type issue.  We could make some __ __ 
> method to do this, allow indexing by None, or something else 
> - neither of those sounds particularly wonderful.
> 
> 
> Do you want to help develop Dynamic languages on CLR? 
> (http://members.microsoft.com/careers/search/details.aspx?JobI
> D=6D4754DE-11F0-45DF-8B78-DC1B43134038)
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Brian Lloyd
> Sent: Friday, March 31, 2006 12:43 PM
> To: pythondotnet at python.org
> Cc: users at lists.ironpython.com
> Subject: [IronPython] Naming and resolution of generic types 
> (complete!)
> 
> 
> Hi all - I'm cross-posting this to the IP list as the subject 
> seems to be an open issue there too.
> 
> I'm working on generics support for Python for .NET, and 
> there a couple of thorny issues that could use some 
> discussion regarding naming and resolution of generic types.
> 
> In C# you can explicitly name a generic type, a la 
> Dictionary<,>. That syntax won't work in Python, of course. 
> Looking at IP, it seems to allow the apparent Python name to 
> be the unmangled IL name so you can naturally use the name.
> 
> The problem is that the mangled name is illegal as a python 
> name, and the unmangled name isn't guaranteed to be unique - 
> you can potentially have any number of generic types as well 
> as a non-generic type with the same base name in the same namespace:
> 
> namespace Spam {
> 
>     public class SpamCan {}
>     public class SpamCan<T> {}
>     public class SpamCan<T, V> {}
>     ...
> }
> 
> I imagine that maybe IP has enough information available at 
> compile-time to do the right thing for some common usage 
> (binding and instantiating the types), but the overloaded 
> name can still be ambiguous. A real-life example of this is 
> System.IComparable - in IP, it doesn't seem possible to get 
> to the non-generic version of IComparable anymore (or at 
> least it was not obvious to me how to do it):
> 
> >>> import System
> >>> System.IComparable
> <type 'IComparable`1'>
> 
> It seems like we need to figure out some acceptable way of 
> spelling generic type names explicitly in Python (an 
> equivalent to IComparable<> in C#) that works within the 
> existing syntax.
> 
> There don't appear to be a lot of great options :( It has to 
> be a valid Python name to work in an import statement, so 
> that rules out strange operator shenanigans akin to the [] 
> hack used for generic type binding.
> 
> One would be to mimic the existing IL mangling in some way, a la:
> 
> >From System import IComparable   # the non-generic type
> >From System import IComparable_1 # the 1-param generic
> 
> # or
> from System import IComparable_T
> from System.Collections.Generic import Dictionary_TT
> 
> These are all pretty gross, and still don't totally prevent 
> hiding of legit non-generic classes with those names (though 
> it makes it less likely that names will be hidden than the 
> current approach).
> 
> I suppose another approach would be to continue to have only 
> one type end up with the simple name, but provide a way to 
> disambiguate it after the fact:
> 
> >>> import System
> >>> System.IComparable
> <type 'IComparable`1'>
> 
> >>> # abandon all hope, ye who enter here...
> >>> NonGenericIComparable = System.IComparable<<0 
> >>> OneParamGenericIComparable = System.IComparable<<1 
> >>> TwoParamVersionIfThereWasOne = System.IComparable<<2
> 
> That feels to me like it violates Python Zen in several ways, though.
> 
> Thoughts?
> 
> 
> -Brian
> 
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org 
> http://mail.python.org/mailman/listinfo/pythondotnet
> 
> 


From dinov at exchange.microsoft.com  Tue May 23 18:40:29 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 23 May 2006 09:40:29 -0700
Subject: [Python.NET] [IronPython] Naming and resolution of generic
 types (complete!)
In-Reply-To: <65531D426735784F854EE658938A5853038FAB97@MI8NYCMAIL03.Mi8.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEB7A154A@df-foxhound-msg.exchange.corp.microsoft.com>

We actually handle this, at least as best we can - when we do the import we check and see if we already have a type of that name, and if so, we'll go ahead and replace the existing type w/ the combined "collision" type.

But if both the types are non-generic then you have a case where we'll actually need to replace the type.  In that case there's nothing we can automagically do.  Instead we actually expose all of the namespaces in a type off of the assembly.  Therefore you can do:

import clr
system = clr.LoadAssemblyByPartialName('System')
system.System.IComparable

and this gives finer control over assemblies / namespaces where it's needed.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: Brian Lloyd [mailto:Brian.Lloyd at revolution.com]
Sent: Tuesday, May 23, 2006 9:17 AM
To: Dino Viehland; Discussion of IronPython; pythondotnet at python.org
Subject: RE: [Python.NET] [IronPython] Naming and resolution of generic types (complete!)

Thanks for the reply - luckily this is pretty much where I ended
up as well ;)

One unlikely-but-technically-possible edge case I ran into was:

  - user imports assembly A that contains the generic type
'foo.bar.SomeType'
  - user creates instances of that type
  - then the user imports assembly B that contributes the non-generic
type
    'SomeType' to the namespace 'foo.bar'

Maybe that's not a problem for the IP implementation, but thought I'd
note it just in case.

-Brian



> -----Original Message-----
> From: pythondotnet-bounces at python.org
> [mailto:pythondotnet-bounces at python.org] On Behalf Of Dino Viehland
> Sent: Monday, May 22, 2006 4:25 PM
> To: Discussion of IronPython; pythondotnet at python.org
> Subject: Re: [Python.NET] [IronPython] Naming and resolution
> of generic types (complete!)
>
> I apologize for the extreme delay on this reply...  This mail
> got stuck in our mailing list somewhere and didn't come out
> until today.
>
> The way we've chosen to solve this is to go w/ the single
> type that allows you to disambiguate after the fact.  If you
> have System.IComparable (another good example is
> System.Nullable which has both generic & non-generic
> versions) we build one 'type' that allows you to disambiguate
> using __getitem__.
>
> This is the same way you need to get a generic instantiation
> (e.g. if there were no IComparable conflicts you'd need to do
> IComparable[int] to get the specific instantiation) so it
> fits in nicely.  Otherwise the type is the non-generic version.
>
> It would seem our str/repr of this type is pretty bad right
> now (showing you only the generic version) - we should make
> that more helpful (e.g. something like <type IComparable,
> IComparable[T]> maybe ?).
>
> I guess the other remaining issue is how to get access to the
> generic type that isn't bound to a specific instantiation -
> currently this isn't much of a problem w/ IronPython as
> there's not much you can actually do w/ the open generic
> type, but we should probably solve it long term.
>
> I've opened 2 bugs - the first one (str/repr of the type)
> should be easy to fix, but some thought probably needs to go
> into the open generic type issue.  We could make some __ __
> method to do this, allow indexing by None, or something else
> - neither of those sounds particularly wonderful.
>
>
> Do you want to help develop Dynamic languages on CLR?
> (http://members.microsoft.com/careers/search/details.aspx?JobI
> D=6D4754DE-11F0-45DF-8B78-DC1B43134038)
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Brian Lloyd
> Sent: Friday, March 31, 2006 12:43 PM
> To: pythondotnet at python.org
> Cc: users at lists.ironpython.com
> Subject: [IronPython] Naming and resolution of generic types
> (complete!)
>
>
> Hi all - I'm cross-posting this to the IP list as the subject
> seems to be an open issue there too.
>
> I'm working on generics support for Python for .NET, and
> there a couple of thorny issues that could use some
> discussion regarding naming and resolution of generic types.
>
> In C# you can explicitly name a generic type, a la
> Dictionary<,>. That syntax won't work in Python, of course.
> Looking at IP, it seems to allow the apparent Python name to
> be the unmangled IL name so you can naturally use the name.
>
> The problem is that the mangled name is illegal as a python
> name, and the unmangled name isn't guaranteed to be unique -
> you can potentially have any number of generic types as well
> as a non-generic type with the same base name in the same namespace:
>
> namespace Spam {
>
>     public class SpamCan {}
>     public class SpamCan<T> {}
>     public class SpamCan<T, V> {}
>     ...
> }
>
> I imagine that maybe IP has enough information available at
> compile-time to do the right thing for some common usage
> (binding and instantiating the types), but the overloaded
> name can still be ambiguous. A real-life example of this is
> System.IComparable - in IP, it doesn't seem possible to get
> to the non-generic version of IComparable anymore (or at
> least it was not obvious to me how to do it):
>
> >>> import System
> >>> System.IComparable
> <type 'IComparable`1'>
>
> It seems like we need to figure out some acceptable way of
> spelling generic type names explicitly in Python (an
> equivalent to IComparable<> in C#) that works within the
> existing syntax.
>
> There don't appear to be a lot of great options :( It has to
> be a valid Python name to work in an import statement, so
> that rules out strange operator shenanigans akin to the []
> hack used for generic type binding.
>
> One would be to mimic the existing IL mangling in some way, a la:
>
> >From System import IComparable   # the non-generic type
> >From System import IComparable_1 # the 1-param generic
>
> # or
> from System import IComparable_T
> from System.Collections.Generic import Dictionary_TT
>
> These are all pretty gross, and still don't totally prevent
> hiding of legit non-generic classes with those names (though
> it makes it less likely that names will be hidden than the
> current approach).
>
> I suppose another approach would be to continue to have only
> one type end up with the simple name, but provide a way to
> disambiguate it after the fact:
>
> >>> import System
> >>> System.IComparable
> <type 'IComparable`1'>
>
> >>> # abandon all hope, ye who enter here...
> >>> NonGenericIComparable = System.IComparable<<0
> >>> OneParamGenericIComparable = System.IComparable<<1
> >>> TwoParamVersionIfThereWasOne = System.IComparable<<2
>
> That feels to me like it violates Python Zen in several ways, though.
>
> Thoughts?
>
>
> -Brian
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
>


From lalit.digari at st.com  Thu May 25 06:13:37 2006
From: lalit.digari at st.com (Lalit DIGARI)
Date: Thu, 25 May 2006 09:43:37 +0530
Subject: [Python.NET] Hanging the application in import
Message-ID: <010401c67fb1$991336b0$d50cc70a@dlh.st.com>

Hello All,
I have a module ex say a ,and in module b I m using clr and having code import clr, I m imorting mudule b into module a ,but application is hanging at the point where in moduel a there is import (something) but if I comented the line import clr then application passes through that hanging point any body having any clue to the problem.

Exmaple 

Module a
{
Import module b // hanging point
}

Module b
{
Import CLR //after commenting this line application do not hang
...
...
}

Regard's
Lalit


From markus.schumacher at gmx.de  Fri May 26 16:28:44 2006
From: markus.schumacher at gmx.de (Markus Schumacher)
Date: Fri, 26 May 2006 16:28:44 +0200
Subject: [Python.NET] Problems with subclasses...
Message-ID: <4477109C.5060802@gmx.de>

Hi list,

Sorry if this is posted twice, however I didn't see this message on the
list. Maybe the company mailserver hasn't delievered it :(

I got a problem here. I have the a class in .NET1.1 (Class A) with
the method public virtual void Do() for example.
Another .NET class (say Class B) has a collection of Class A and a
method DoAll() which iterates over all
Class A in B and calls the Do() Method.
So now comes the problem. In Python I have a class MyA derived from
.NET Class A and overrides the method Do().

Now I add some of my MyA class to the B class and execute DoAll() on
B. Surprisingly, only the Do() methods of A are called not the
PythonNet Do() in the MyA instances.

I would have expected that the MyA.Do() will be called. Is this a bug?
I'm using the RC2 of PythonNet for .NET1.1 and Python2.4.2.

Any ideas?

Markus


From brian.d.lloyd at gmail.com  Fri May 26 16:49:12 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Fri, 26 May 2006 10:49:12 -0400
Subject: [Python.NET] Hanging the application in import
In-Reply-To: <010401c67fb1$991336b0$d50cc70a@dlh.st.com>
References: <010401c67fb1$991336b0$d50cc70a@dlh.st.com>
Message-ID: <1c0b4a390605260749u38019b21sf7e41619d2213009@mail.gmail.com>

Lalit - I can't reproduce this on any version of Python for .NET. It would
be best if you could post the actual code you have rather than a summary, as
it is probably not something anyone can diagnose without context.

-Brian

On 5/25/06, Lalit DIGARI <lalit.digari at st.com> wrote:
>
> Hello All,
> I have a module ex say a ,and in module b I m using clr and having code
> import clr, I m imorting mudule b into module a ,but application is hanging
> at the point where in moduel a there is import (something) but if I comented
> the line import clr then application passes through that hanging point any
> body having any clue to the problem.
>
> Exmaple
>
> Module a
> {
> Import module b // hanging point
> }
>
> Module b
> {
> Import CLR //after commenting this line application do not hang
> ...
> ...
> }
>
> Regard's
> Lalit
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20060526/6aa1d8d7/attachment.html 

From Brian.Lloyd at revolution.com  Fri May 26 16:49:54 2006
From: Brian.Lloyd at revolution.com (Brian Lloyd)
Date: Fri, 26 May 2006 10:49:54 -0400
Subject: [Python.NET] Problems with subclasses...
References: <4477109C.5060802@gmx.de>
Message-ID: <65531D426735784F854EE658938A5853015F7E25@MI8NYCMAIL03.Mi8.com>

 
Hi Markus -
 
a limitation of Python for .NET is that overrides you write in Python are only visible to Python code. There is some possibility that in the future we could generate a .NET subclass whenever you subclass in Python and provide delegate implementations of overridden methods that would be visible to .NET, but that does not currently exist.
 
-Brian

________________________________

From: pythondotnet-bounces at python.org on behalf of Markus Schumacher
Sent: Fri 5/26/2006 10:28 AM
To: pythondotnet at python.org
Subject: [Python.NET] Problems with subclasses...



Hi list,

Sorry if this is posted twice, however I didn't see this message on the
list. Maybe the company mailserver hasn't delievered it :(

I got a problem here. I have the a class in .NET1.1 (Class A) with
the method public virtual void Do() for example.
Another .NET class (say Class B) has a collection of Class A and a
method DoAll() which iterates over all
Class A in B and calls the Do() Method.
So now comes the problem. In Python I have a class MyA derived from
.NET Class A and overrides the method Do().

Now I add some of my MyA class to the B class and execute DoAll() on
B. Surprisingly, only the Do() methods of A are called not the
PythonNet Do() in the MyA instances.

I would have expected that the MyA.Do() will be called. Is this a bug?
I'm using the RC2 of PythonNet for .NET1.1 and Python2.4.2.

Any ideas?

Markus

_________________________________________________
Python.NET mailing list - PythonDotNet at python.org
http://mail.python.org/mailman/listinfo/pythondotnet