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

Dino Viehland dinov at exchange.microsoft.com
Tue May 23 18:40:29 CEST 2006

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

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
  - user creates instances of that type
  - then the user imports assembly B that contributes the non-generic
    '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.


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

More information about the PythonDotNet mailing list