[Python.NET] [IronPython] Naming and resolution of generic types (complete!)

[Brian Lloyd]

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
> 
>