[IronPython] .NET Attributes

Dino Viehland dinov at exchange.microsoft.com
Wed Mar 29 00:52:58 CEST 2006

The usage of decorators on classes is interesting, and is worth a follow up to the python mailing lists...

There's actually a lot of interesting problems like what you describe below w/ attributes and runtime vs. compile time.  For example if we were to do a from __experimental__ import ... for optional static typing (http://www.artima.com/weblogs/viewpost.jsp?thread=89161) then we'd have a similar tension between doing things at runtime vs. compile time - as it's really still runtime logic that's being added..

For the most part I believe we can get the best of both worlds here.  For example even though we'd be statically compiling types somewhere in the generated code is still the body used for module initialization.  This code runs at import time just like it would w/ a normal python module.

Likewise there are also still executable class statements (these would turn into CLR class initializers) and these would run when a class statement normally would run.

The reason why I mention these is that when these run we can check and see if the static compiler made the right decisions and fix anything it did wrong at runtime.  To take an example that is simpler than attributes:

class foo(object):
        if False:
                def bar(self):
                        print "Hello world!"

Anyone who tries to call bar on an instance of a foo should get an exception.  The static transformation of that would be into something like this:

class foo {
        Dict myDict;

        static foo(){
                myDict = new Dict();
                        myDict['bar'] = new ReflectedMethod(foo.bar);

        public object bar(){
                if(myDict['bar'] == null) throw MissingMemberException();
                if(myDict['bar'] == bar) {      // or something...
                        Ops.Print('hello world');
                        return null;
                } else {
                        return Ops.Call(barFunc);

Attributes here are trickier but could be handled in a similar fashion.  But in this case we'd need to generate a new class at runtime that contains the correct attributes, and prevent the C# code from getting an instance of the statically compiled class (e.g. by throwing an exception whenever it gets created).  That means we've effectively pushed ourselves all the way back to the fully dynamic experience but that's better than being wrong.

In general we don't want to trade off ANY of the runtime facilities of Python to make this happen.  Instead we want to retain all of those capabilities while generating IL & Metadata that allows other statically typed languages to consume the less-dynamic portions of the language.  In other words if a Python programmer can tell we compiled the code statically at runtime we've made a mistake.

But doing all of this is a lot of work...  There's a reason we don't have it yet :).

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ernst, Nathan
Sent: Tuesday, March 28, 2006 5:42 AM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET Attributes

I wouldn't give up completely on using decorators for classes.  True,
Python 2.4 doesn't support them on classes, only functions.  I think
consistency should be sought here.

After reading PEP 318 (http://www.python.org/dev/peps/pep-0318/) a
little closer, I noticed that there *are* some examples of using
decorators on classes.  (See examples 2 and 5 at the end of the PEP).
While not included in 2.4, I could not find if it has been ruled out as
a later enhancement.

Note that there may be a potential problem using decorator syntax for
attributes.  In CPython, a decorator is merely a syntactical shortcut
for applying a function to a function definition.  It could be said
that, in IronPython, the attribute is being applied to a function.  To
me, this seems kind of confused, as the attribute descriptor now becomes
a special case descriptor for the interpreter to have to handle because
the descriptor is not being called with the function/class definition as
an argument.  Instead, the attributes must be compiled into the
generated code.

It is probably not that large of a deal, though. (Just playing devil's
advocate here). Despite this, I still like the decorator syntax.


-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Monday, March 27, 2006 11:45 PM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET Attributes

I like this too...  It's interesting that while the syntax isn't exactly
the same for giving both classes & functions attributes they are both
getting that information in the same way.  I was previously worried
about the differences between classes & functions but I think this
brings it all together.



This e-mail contains information that may be confidential and
proprietary. It is to be read and used solely by the intended recipient(s).
Citadel and its affiliates retain all proprietary rights they may have in the
information. If you are not an intended recipient, please notify us
immediately either by reply e-mail or by telephone at 312-395-2100
and delete this e-mail (including any attachments hereto) immediately
without reading, disseminating, distributing or copying. We cannot give
any assurances that this e-mail and any attachments are free of viruses
and other harmful code. Citadel reserves the right to monitor, intercept
and block all communications involving its computer systems.

users mailing list
users at lists.ironpython.com

More information about the Ironpython-users mailing list