I see problems with #3, at least using those precise keywords.
A variant of #3, perhaps
reference <assembly, opt version, opt culture, opt signature>
from System.Drawing import *
rather than muddying up "import" and "from" would be suitable for non-standard
libraries. "import foo from bar" and "from bar import foo" doesn't really say
anything different when I read it. Unfortunately, as you note, a namespace and
an assembly are two different beasts (problem with #1).
The reference syntax I suggest could address the problem of versioning problems
with retrieving assemblies.
As for #4 in general. There's a problem of conflicting type names living in
peer assemblies. I think it'd best be limited to the BCL and other blessed
frameworks, which can (hopefully) be counted on to play nicely with namespaces.
Also, notably, these are likely to be candidates for the GAC, or some similar
cache.
So my thinking:
well-known assemblies: ~#4
others, or override: #3 (reference)________________________________ From: [EMAIL PROTECTED] on behalf of Jim Hugunin Sent: Wed 7/6/2005 5:23 PM To: Discussion of IronPython Subject: RE: [IronPython] Making A Windows Form App We clearly need a better design than the current sys.LoadAssembly* methods. For one thing, we shouldn't really be adding these to the existing sys module but putting new methods like this in a new IronPython module. As you point out, we should also do a better job of making this as invisible to the user as possible.
<<winmail.dat>>
_______________________________________________ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
