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(); if(false){ 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. -Nathan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. ------------------------------------------------------------------------------------------------- ------------------------- CONFIDENTIALITY AND SECURITY NOTICE 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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
