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@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@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@lists.ironpython.com [mailto:users-bounces@lists.ironpython.com] On Behalf Of Brian Lloyd Sent: Friday, March 31, 2006 12:43 PM To: pythondotnet@python.org Cc: users@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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
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...) -----Original Message----- From: Brian Lloyd [mailto:Brian.Lloyd@revolution.com] Sent: Tuesday, May 23, 2006 9:17 AM To: Dino Viehland; Discussion of IronPython; pythondotnet@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@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@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@lists.ironpython.com [mailto:users-bounces@lists.ironpython.com] On Behalf Of Brian Lloyd Sent: Friday, March 31, 2006 12:43 PM To: pythondotnet@python.org Cc: users@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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
participants (2)
-
Brian Lloyd -
Dino Viehland