Jared's email reminded me that I needed to get some feedback on how I plan
to integrate clrtypes.py into IronPython. Currently, most of what's in
clrtypes.py will move into the clr module, but a few pieces will be
renamed. Loosely, it will look like:
clr.assembly_attribute(AssemblyVersionAttribute("1.0.0.0"))
class Foo(object):
__metaclass__ = clr.TypedClass
__clr_namespace__ = 'MyFoo'
__clr_attributes__ = [
CLSCompliantAttribute(False)
]
def __init__(self):
self._bar = 0
@clr.property(int) # (type, virtual=True)
def bar(self): return self._bar
@bar.setter
def bar(self, value): self._bar = value
@ObsoleteAttribute
@clr.method(int, [int], virtual=False) # (return, args, virtual=True)
def frob(self, n):
return n*n
@clr.staticmethod(int, [int]) # (return, args)
def static_frob(n):
return n*n
Methods (and properties) are virtual by default, in keeping with normal
Python expectations. I'm not currently planning any visibility control
(public, private, etc.), either, but it's not too difficult to do if
requested.
Interfaces will look similar, except their metaclass will be
clr.TypedInterface (but they may not make the first release). I have no
plans for structs right now.
Fields are another thing that probably won't make v1, simply because I
don't see a really good use case for them (unlike properties). Ditto
overloaded methods (that will require a lot of work, but I think it's
possible).
I keep pondering whether I want to muck with namespaces to drop the
'Attribute' from attribute type names. Right now, I'm leaning against it.
The second part of this is improvements to pyc.py, which will now become
ipyc.exe (literally, in fact - the build process uses pyc.py to compile
*itself* into ipyc.exe). This will allow the creation of assemblies that
expose actual typed CLR classes, for use as plugins. For example, I'm also
working on some MSBuild Tasks to run ipyc, which are written in Python and
compiled with ipyc. Any sort of plugin should now be directly possible with
IronPython.
Finally, the new ipyc will gain the ability to target multiple platforms.
WinRT, WP8, iOS, and Android all require (some) classes to be generated
ahead of time, which ipyc will take care of, while also fixing up assembly
references/versions/etc. so that the various runtimes will load the
generated assemblies. For example, Android requires running the
mandroid.exe tool to generate wrappers for Android UI classes, and
WinRT/WP8 have no ability to generate classes at runtime *at all* (don't
get me started on that one...). This is finicky, as you might imagine, but
entirely doable. The real key is that IronPython's generated code really
only depends on CLR2 features, so only some metadata needs to be changed
and some namespaces fixed up.
All of this is a long way of saying that 2.7.4 is going to have some crazy
cool stuff in it, but it's taking a while to get it put together. If you're
interested in a preview, my static-pyc branch (
https://github.com/jdhardy/ironpython/tree/static-pyc) has the current
working version. I'd like to put out an Alpha by the end of November, but I
make no promises. :)
- Jeff
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users
