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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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
>
>
_________________________________________________
Python.NET mailing list - PythonDotNet@python.org
http://mail.python.org/mailman/listinfo/pythondotnet
