[IronPython] Making A Windows Form App

Keith J. Farmer kfarmer at thuban.org
Thu Jul 7 03:11:10 CEST 2005


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: users-ironpython.com-bounces at lists.ironpython.com 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5239 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050706/33a89312/attachment.bin>


More information about the Ironpython-users mailing list