Mailman 3 May 2006 - Python.NET

Problems with subclasses...
by Markus Schumacher 26 May '06

26 May '06

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

2 1

Hanging the application in import
by Lalit DIGARI 26 May '06

26 May '06

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

2 1

Re: [Python.NET] [IronPython] Naming and resolution of generic types (complete!)
by Brian Lloyd 23 May '06

23 May '06

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(a)python.org > [mailto:pythondotnet-bounces@python.org] On Behalf Of Dino Viehland > Sent: Monday, May 22, 2006 4:25 PM > To: Discussion of IronPython; pythondotnet(a)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(a)lists.ironpython.com > [mailto:users-bounces@lists.ironpython.com] On Behalf Of Brian Lloyd > Sent: Friday, March 31, 2006 12:43 PM > To: pythondotnet(a)python.org > Cc: users(a)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(a)lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _________________________________________________ > Python.NET mailing list - PythonDotNet(a)python.org > http://mail.python.org/mailman/listinfo/pythondotnet > >

2 1

Naming and resolution of generic types (complete!)
by Brian Lloyd 22 May '06

22 May '06

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

5 4

Hello??
by Mathew Yeates 12 May '06

12 May '06

Anybody out there? Did this list die? Mathew

3 2

Problem passing parameters to a python function from C#
by Tiago Matias 12 May '06

12 May '06

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

2 1