Re: [IronPython] .Net attributes/decorators
Thanks for the explanation. I like the opt in idea -- taken to its fullest, that could allow .Net-style decorators on an opt-in module basis, could it not? And I see the point about the many platforms in one codebase approach you describe as a way of enabling the larger Python community. By pursuing both approaches, the many-in-one and the opt-in to the fullest, I think IPy can continue to fulfill what I understand now to have been the original goal, of serving the Python community, while also providing an enticing alternative to static .Net languages for non-Pythonistas looking for a more comfortable home. In the meantime, I know where to go when I get stuck on how to use ClrType.py to use .Net attributes. You probably know where I can go, too, but we're probably thinking of different places. s thanks again, Hank On Tue, May 18, 2010 at 4:50 PM, Dino Viehland di...@microsoft.com wrote: The answer is kind of both. When it comes to the core language grammar we are (and I believe will always be) an equivalent set. That’s rather important in that any code which is .NET specific can still be parsed by other Python implementations and therefore you can do various if I’m running on IronPython do this else if I’m on Jython do that or if I’m on CPython do something else – which is a fairly common pattern and even shows up in the standard library. When it comes to the various builtin types we intend to be a superset but that superset is only available after the user has specifically opted in to IronPython. So let’s look at some examples how this has played out. To add generic support we used Python’s existing indexing support rather than adding parsing support for something like Dictionaryint, int which would have matched C#. But at the same time we don’t want to modify the core objects too much – for example a future version of CPython could choose to add indexing support to built-in functions to add some new feature of their own. Therefore our built-in functions which are generic are actually a subtype of the normal built-in function type and add indexing. Our normal built-in functions don’t support indexing (types/generic types actually still need this treatment of not having indexing by default but I haven’t gotten around to fixing that one yet). And of course we try and make sure that all of the extensions that we do offer are only available on an opt-in basis and that opt-in basis is per-module rather than tainting all code in the interpreter. That enables some code to be Python specific and other code to be Ipy specific. That’s done via “import clr” (or importing any other .NET namespace actually) which makes any additional attributes that we’ve added to types available (for example __clrtype__ is not visible until you do an import clr). That enables us to expose things which are .NET specific but still allows pure Python code to run without seeing anything change – so for example if some code as doing dir() it’s not going to freak out because there’s some unexpected attributes. *From:* users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] *On Behalf Of *Hank Fay *Sent:* Tuesday, May 18, 2010 11:11 AM *To:* Discussion of IronPython *Subject:* [IronPython] .Net attributes/decorators In reviewing the discussion of .Net decorators in the list (thank you Google Groups), I did not come across a discussion of what I saw as the central issue: is IronPython to be a Superset of Python (every Python program will run in IronPython, not every IronPython program will run in Python), or is IronPython to be an equivalent set (every Python program will run in IPy, and every IPy will run in Python). Has there been a discernment on this issue? For me, coming from a non-Python world, it makes sense to view IPy as a superset of Python. This perspective would, e.g., allow the use of .Net decorators on classes (which in turn would facilitate returning .Net objects). I've read about the ways of using __clrtype__ to do this in a Pythonic manner. My interest is in simplicity and clarity in my programs, rather than maintaining two-way compatibility (which I could not port to Python, in any case, for a .Net program using .Net features). thanks, Hank Fay ___ 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
Re: [IronPython] .NET attributes for methods
This looks very promising but I cannot make it work. I have changed
product.py in DevHawk's example to:
#from clrtypeold import ClrMetaclass
import clrtype
class Product(object):
#__metaclass__ = ClrMetaclass
__metaclass__ = clrtype.ClrClass
_clrnamespace = DevHawk.IronPython.ClrTypeSeries
#_clrproperties = {
#name:str,
#cost:float,
#quantity:int,
#}
def __init__(self, name, cost, quantity):
self.name = name
self.cost = cost
self.quantity = quantity
def calc_total(self):
return self.cost * self.quantity
@property
@clrtype.accepts()
@clrtype.returns(str)
def name(self):
return self._name
@name.setter
@clrtype.accepts(str)
@clrtype.returns()
def name(self, value):
self._name = value
When I run it I don't see any items in the listbox. When I check the
name, it is a property:
py a.root.listbox1.Items[0]
= Product object at 0x002B
py a.root.listbox1.Items[0].GetType().GetProperties()
= Array[PropertyInfo]((System.Reflection.RuntimePropertyInfo object at
0x002C [System.String name]))
Whe I used the old clrtype with _clrproperties = {'name': str, ...}, it
worked.
--
-- Lukáš
Shri Borde wrote:
Here is an updated version of clrtype.py that uses @property +
@clrtype.accepts/@clrtype.returns to indicate a CLR property, instead
of using _clrproperties. I think its more Pythonic in general, but
also you should be able to modify @notify_property to work with it.
Note that notify_property won't just work. You will have to change it
to propagate the func_name, arg_types, and return_type properties from
the old getter/setter function objects to the new getter/setter
function objects since these values are used by clrtype to generate
the CLR members. Something like this:
class notify_property(property):
def propagate_attributes(old_function, new_function):
new_function.func_name = old_function.func_name
new_function.arg_types = old_function.arg_types
new_function.return_type = old_function.return_type
def __init__(self, getter):
def newgetter(slf):
try:
return getter(slf)
except AttributeError:
return None
propagate_attributes(getter, newgetter)
super(notify_property, self).__init__(newgetter)
def setter(self, setter):
def newsetter(slf, newvalue):
oldvalue = self.fget(slf)
if oldvalue != newvalue:
setter(slf, newvalue)
slf.OnPropertyChanged(setter.__name__)
propagate_attributes(setter, newsetter)
return property(
fget=self.fget,
fset=newsetter,
fdel=self.fdel,
doc=self.__doc__)
*From:* Lukas Cenovsky [mailto:cenov...@bakalari.cz]
*Sent:* Thursday, November 12, 2009 11:01 AM
*To:* Shri Borde
*Subject:* Re: [IronPython] .NET attributes for methods
Shri Borde wrote:
So the new clrtype.py still works - cool!
Yep ;-)
I am not an expert on data binding, so I don't have any suggestions.
Why do you say that the decorator approach will not work with
Silverlight? Does @notifiy_property from
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html
use any feature not available in Silverlight?
It does not (as far as I know because it is pure IronPython). But
@notify_property does not work with clrtypes:
class ViewModel(NotifyPropertyChangedBase):
__metaclass__ = clrtype.ClrMetaclass
_clrnamespace = Cenda.ViewModel
_clrproperties = {'size': str}
def __init__(self):
super(ViewModel, self).__init__()
# must be string to two-way binding work correctly
self.size = '10'
@notify_property
def size(self):
return self._size
@size.setter
def size(self, value):
self._size = value
print 'Size changed to %r' % self.size
When I run this code, the size is still clr property and Python getter
and setter are not run.
So basically I need to override/enhance clr getter and setter created
by clrtype._clrproperties.
--
-- Lukáš
*From:* Lukas Cenovsky [mailto:cenov...@bakalari.cz]
*Sent:* Thursday, November 12, 2009 8:09 AM
*To:* Shri Borde
*Subject:* Re: [IronPython] .NET attributes for methods
Thanks, that works!
What do you think would be the best approach to create notifiable
properties for Silverlight? I did it for WPF (via decorators:
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html)
but it seems to me it won't be possible to do it similarly for
Silverlight...
--
-- Lukáš
Shri Borde wrote:
Can you use _clrproperties instead of _clrfields? DevHawk's same
created a field and a property even when you just used _clrfields. I
don't do that anymore. So you will need to use _clrproperties to get
properties, which SL must use for data binding.
*From:* users-boun
Re: [IronPython] .NET attributes for methods
, String name, Object[] bases, String selfNames)
at unnamed$1.unnamed(CodeContext $globalContext, FunctionCode functionCode)
at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx)
at IronPython.Compiler.PythonScriptCode.Run(Scope scope)
at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope)
at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope)
at Microsoft.Scripting.Hosting.CompiledCode.Execute(ScriptScope scope)
at Microsoft.Scripting.Silverlight.DynamicEngine.Run(String entryPoint)
at Microsoft.Scripting.Silverlight.DynamicApplication.DynamicApplication_Startupb__1()
at Microsoft.Scripting.Silverlight.Cache.Download(List`1 uris, Action onComplete)
at Microsoft.Scripting.Silverlight.HttpVirtualFilesystem.DownloadAndCache(List`1 uris, Action onComplete)
at Microsoft.Scripting.Silverlight.DynamicScriptTags.DownloadExternalCode(Action onComplete)
at Microsoft.Scripting.Silverlight.DynamicApplication.DynamicApplication_Startupb__0()
at Microsoft.Scripting.Silverlight.DynamicLanguageConfig.DownloadLanguages(DynamicAppManifest appManifest, Action onComplete)
at Microsoft.Scripting.Silverlight.DynamicApplication.DynamicApplication_Startup(Object sender, StartupEventArgs e)
at System.Windows.CoreInvokeHandler.InvokeEventHandler(Int32 typeIndex, Delegate handlerDelegate, Object sender, Object args)
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, String eventName)
|
Shri Borde wrote:
Here is an updated version of clrtype.py that uses @property +
@clrtype.accepts/@clrtype.returns to indicate a CLR property, instead
of using _clrproperties. I think its more Pythonic in general, but
also you should be able to modify @notify_property to work with it.
Note that notify_property won't just work. You will have to change it
to propagate the func_name, arg_types, and return_type properties from
the old getter/setter function objects to the new getter/setter
function objects since these values are used by clrtype to generate
the CLR members. Something like this:
class notify_property(property):
def propagate_attributes(old_function, new_function):
new_function.func_name = old_function.func_name
new_function.arg_types = old_function.arg_types
new_function.return_type = old_function.return_type
def __init__(self, getter):
def newgetter(slf):
try:
return getter(slf)
except AttributeError:
return None
propagate_attributes(getter, newgetter)
super(notify_property, self).__init__(newgetter)
def setter(self, setter):
def newsetter(slf, newvalue):
oldvalue = self.fget(slf)
if oldvalue != newvalue:
setter(slf, newvalue)
slf.OnPropertyChanged(setter.__name__)
propagate_attributes(setter, newsetter)
return property(
fget=self.fget,
fset=newsetter,
fdel=self.fdel,
doc=self.__doc__)
*From:* Lukas Cenovsky [mailto:cenov...@bakalari.cz]
*Sent:* Thursday, November 12, 2009 11:01 AM
*To:* Shri Borde
*Subject:* Re: [IronPython] .NET attributes for methods
Shri Borde wrote:
So the new clrtype.py still works - cool!
Yep ;-)
I am not an expert on data binding, so I don't have any suggestions.
Why do you say that the decorator approach will not work with
Silverlight? Does @notifiy_property from
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html
use any feature not available in Silverlight?
It does not (as far as I know because it is pure IronPython). But
@notify_property does not work with clrtypes:
class ViewModel(NotifyPropertyChangedBase):
__metaclass__ = clrtype.ClrMetaclass
_clrnamespace = Cenda.ViewModel
_clrproperties = {'size': str}
def __init__(self):
super(ViewModel, self).__init__()
# must be string to two-way binding work correctly
self.size = '10'
@notify_property
def size(self):
return self._size
@size.setter
def size(self, value):
self._size = value
print 'Size changed to %r' % self.size
When I run this code, the size is still clr property and Python getter
and setter are not run.
So basically I need to override/enhance clr getter and setter created
by clrtype._clrproperties.
--
-- Lukáš
*From:* Lukas Cenovsky [mailto:cenov...@bakalari.cz]
*Sent:* Thursday, November 12, 2009 8:09 AM
*To:* Shri Borde
*Subject:* Re: [IronPython] .NET attributes for methods
Thanks, that works!
What do you think would be the best approach to create notifiable
properties for Silverlight? I did it for WPF (via decorators:
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html)
but it seems to me it won't be possible to do it similarly
Re: [IronPython] .NET attributes for methods
I can help you create a property. And I can help you get it to work with your
decorators (you can check if the name property exposes your @notify_property
wrapper methods or not, and presumably that works). Beyond that, you are on
your own :)
I would try calling the property methods to make sure they are accessible.
Something like this. If that works, I am not sure what Silverlight needs to
make databinding happy.
props = a.root.listbox1.Items[0].GetType().GetProperties()
prop = props[0]
prop.GetGetMethod.Invoke(a, None) # call using Reflection
About the SystemError: Application code cannot access
System.AppDomain.get_CurrentDomain() using Reflection. error when defining
interfaces, it could be worked around. We need to call
AppDomain.DefineDynamicAssembly, and IronPython itself does do this. So its
just a question of figuring out the right way to access an AppDomain instance.
Will look into it, but I doubt it will help you with data binding.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Friday, November 13, 2009 5:42 AM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET attributes for methods
This looks very promising but I cannot make it work. I have changed product.py
in DevHawk's example to:
#from clrtypeold import ClrMetaclass
import clrtype
class Product(object):
#__metaclass__ = ClrMetaclass
__metaclass__ = clrtype.ClrClass
_clrnamespace = DevHawk.IronPython.ClrTypeSeries
#_clrproperties = {
#name:str,
#cost:float,
#quantity:int,
#}
def __init__(self, name, cost, quantity):
self.name = name
self.cost = cost
self.quantity = quantity
def calc_total(self):
return self.cost * self.quantity
@property
@clrtype.accepts()
@clrtype.returns(str)
def name(self):
return self._name
@name.setter
@clrtype.accepts(str)
@clrtype.returns()
def name(self, value):
self._name = value
When I run it I don't see any items in the listbox. When I check the name, it
is a property:
py a.root.listbox1.Items[0]
= Product object at 0x002B
py a.root.listbox1.Items[0].GetType().GetProperties()
= Array[PropertyInfo]((System.Reflection.RuntimePropertyInfo object at
0x002C [System.String name]))
Whe I used the old clrtype with _clrproperties = {'name': str, ...}, it worked.
--
-- Lukáš
Shri Borde wrote:
Here is an updated version of clrtype.py that uses @property +
@clrtype.accepts/@clrtype.returns to indicate a CLR property, instead of using
_clrproperties. I think its more Pythonic in general, but also you should be
able to modify @notify_property to work with it.
Note that notify_property won't just work. You will have to change it to
propagate the func_name, arg_types, and return_type properties from the old
getter/setter function objects to the new getter/setter function objects since
these values are used by clrtype to generate the CLR members. Something like
this:
class notify_property(property):
def propagate_attributes(old_function, new_function):
new_function.func_name = old_function.func_name
new_function.arg_types = old_function.arg_types
new_function.return_type = old_function.return_type
def __init__(self, getter):
def newgetter(slf):
try:
return getter(slf)
except AttributeError:
return None
propagate_attributes(getter, newgetter)
super(notify_property, self).__init__(newgetter)
def setter(self, setter):
def newsetter(slf, newvalue):
oldvalue = self.fget(slf)
if oldvalue != newvalue:
setter(slf, newvalue)
slf.OnPropertyChanged(setter.__name__)
propagate_attributes(setter, newsetter)
return property(
fget=self.fget,
fset=newsetter,
fdel=self.fdel,
doc=self.__doc__)
From: Lukas Cenovsky [mailto:cenov...@bakalari.cz]
Sent: Thursday, November 12, 2009 11:01 AM
To: Shri Borde
Subject: Re: [IronPython] .NET attributes for methods
Shri Borde wrote:
So the new clrtype.py still works - cool!
Yep ;-)
I am not an expert on data binding, so I don't have any suggestions. Why do
you say that the decorator approach will not work with Silverlight? Does
@notifiy_property from
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html
use any feature not available in Silverlight?
It does not (as far as I know because it is pure IronPython). But
@notify_property does not work with clrtypes:
class ViewModel(NotifyPropertyChangedBase):
__metaclass__ = clrtype.ClrMetaclass
_clrnamespace = Cenda.ViewModel
_clrproperties = {'size': str}
def __init__(self):
super(ViewModel, self).__init__()
# must be string to two-way binding work correctly
self.size = '10
Re: [IronPython] .NET attributes for methods
Help with getting properties to work will hopefully resolve the
databinding as well ;-)
The property getter looks wrong but I have no idea what's wrong:
py props = a.root.listbox1.Items[0].GetType().GetProperties()
py props
= Array[PropertyInfo]((System.Reflection.RuntimePropertyInfo object at
0x002C [System.String name]))
py prop = props[0]
py prop.GetGetMethod()
= System.Reflection.RuntimeMethodInfo object at 0x002B
[System.String name()]
py prop.GetGetMethod().Invoke(a.root.listbox1.Items[0], None)
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation.
at module in string, line 0
Just for clarification a is Silverlight Application instance
As for the interface error - this is a different strory. You may
remember I created WCF service in IronPython with just interface defined
in C#. To be able to move interface to IronPython, I need such interface
to work with Silverlight too because Silverlight is the cause why I am
building WCF services.
--
-- Lukáš
Shri Borde wrote:
I can help you create a property. And I can help you get it to work
with your decorators (you can check if the name property exposes
your @notify_property wrapper methods or not, and presumably that
works). Beyond that, you are on your own :)
I would try calling the property methods to make sure they are
accessible. Something like this. If that works, I am not sure what
Silverlight needs to make databinding happy.
props = a.root.listbox1.Items[0].GetType().GetProperties()
prop = props[0]
prop.GetGetMethod.Invoke(a, None) # call using Reflection
About the SystemError: Application code cannot access
System.AppDomain.get_CurrentDomain() using Reflection. error when
defining interfaces, it could be worked around. We need to call
AppDomain.DefineDynamicAssembly, and IronPython itself does do this.
So its just a question of figuring out the right way to access an
AppDomain instance. Will look into it, but I doubt it will help you
with data binding.
*From:* users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lukas Cenovsky
*Sent:* Friday, November 13, 2009 5:42 AM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] .NET attributes for methods
This looks very promising but I cannot make it work. I have changed
product.py in DevHawk's example to:
#from clrtypeold import ClrMetaclass
import clrtype
class Product(object):
#__metaclass__ = ClrMetaclass
__metaclass__ = clrtype.ClrClass
_clrnamespace = DevHawk.IronPython.ClrTypeSeries
#_clrproperties = {
#name:str,
#cost:float,
#quantity:int,
#}
def __init__(self, name, cost, quantity):
self.name = name
self.cost = cost
self.quantity = quantity
def calc_total(self):
return self.cost * self.quantity
@property
@clrtype.accepts()
@clrtype.returns(str)
def name(self):
return self._name
@name.setter
@clrtype.accepts(str)
@clrtype.returns()
def name(self, value):
self._name = value
When I run it I don't see any items in the listbox. When I check the
name, it is a property:
py a.root.listbox1.Items[0]
= Product object at 0x002B
py a.root.listbox1.Items[0].GetType().GetProperties()
= Array[PropertyInfo]((System.Reflection.RuntimePropertyInfo object at
0x002C [System.String name]))
Whe I used the old clrtype with _clrproperties = {'name': str, ...},
it worked.
--
-- Lukáš
Shri Borde wrote:
Here is an updated version of clrtype.py that uses @property +
@clrtype.accepts/@clrtype.returns to indicate a CLR property, instead
of using _clrproperties. I think its more Pythonic in general, but
also you should be able to modify @notify_property to work with it.
Note that notify_property won't just work. You will have to change it
to propagate the func_name, arg_types, and return_type properties from
the old getter/setter function objects to the new getter/setter
function objects since these values are used by clrtype to generate
the CLR members. Something like this:
class notify_property(property):
def propagate_attributes(old_function, new_function):
new_function.func_name = old_function.func_name
new_function.arg_types = old_function.arg_types
new_function.return_type = old_function.return_type
def __init__(self, getter):
def newgetter(slf):
try:
return getter(slf)
except AttributeError:
return None
propagate_attributes(getter, newgetter)
super(notify_property, self).__init__(newgetter)
def setter(self, setter):
def newsetter(slf, newvalue):
oldvalue = self.fget(slf)
if oldvalue != newvalue:
setter(slf, newvalue)
slf.OnPropertyChanged(setter.__name__)
propagate_attributes
Re: [IronPython] .NET attributes for methods
Thanks to Shri and the new clrtype both issues are resolved. I will post
details soon on my blog.
--
-- Lukáš
Lukas Cenovsky wrote:
Help with getting properties to work will hopefully resolve the
databinding as well ;-)
The property getter looks wrong but I have no idea what's wrong:
py props = a.root.listbox1.Items[0].GetType().GetProperties()
py props
= Array[PropertyInfo]((System.Reflection.RuntimePropertyInfo object at
0x002C [System.String name]))
py prop = props[0]
py prop.GetGetMethod()
= System.Reflection.RuntimeMethodInfo object at 0x002B
[System.String name()]
py prop.GetGetMethod().Invoke(a.root.listbox1.Items[0], None)
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation.
at module in string, line 0
Just for clarification a is Silverlight Application instance
As for the interface error - this is a different strory. You may
remember I created WCF service in IronPython with just interface
defined in C#. To be able to move interface to IronPython, I need such
interface to work with Silverlight too because Silverlight is the
cause why I am building WCF services.
--
-- Lukáš
Shri Borde wrote:
I can help you create a property. And I can help you get it to work
with your decorators (you can check if the name property exposes
your @notify_property wrapper methods or not, and presumably that
works). Beyond that, you are on your own :)
I would try calling the property methods to make sure they are
accessible. Something like this. If that works, I am not sure what
Silverlight needs to make databinding happy.
props = a.root.listbox1.Items[0].GetType().GetProperties()
prop = props[0]
prop.GetGetMethod.Invoke(a, None) # call using Reflection
About the SystemError: Application code cannot access
System.AppDomain.get_CurrentDomain() using Reflection. error when
defining interfaces, it could be worked around. We need to call
AppDomain.DefineDynamicAssembly, and IronPython itself does do this.
So its just a question of figuring out the right way to access an
AppDomain instance. Will look into it, but I doubt it will help you
with data binding.
*From:* users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lukas Cenovsky
*Sent:* Friday, November 13, 2009 5:42 AM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] .NET attributes for methods
This looks very promising but I cannot make it work. I have changed
product.py in DevHawk's example to:
#from clrtypeold import ClrMetaclass
import clrtype
class Product(object):
#__metaclass__ = ClrMetaclass
__metaclass__ = clrtype.ClrClass
_clrnamespace = DevHawk.IronPython.ClrTypeSeries
#_clrproperties = {
#name:str,
#cost:float,
#quantity:int,
#}
def __init__(self, name, cost, quantity):
self.name = name
self.cost = cost
self.quantity = quantity
def calc_total(self):
return self.cost * self.quantity
@property
@clrtype.accepts()
@clrtype.returns(str)
def name(self):
return self._name
@name.setter
@clrtype.accepts(str)
@clrtype.returns()
def name(self, value):
self._name = value
When I run it I don't see any items in the listbox. When I check the
name, it is a property:
py a.root.listbox1.Items[0]
= Product object at 0x002B
py a.root.listbox1.Items[0].GetType().GetProperties()
= Array[PropertyInfo]((System.Reflection.RuntimePropertyInfo object at
0x002C [System.String name]))
Whe I used the old clrtype with _clrproperties = {'name': str, ...},
it worked.
--
-- Lukáš
Shri Borde wrote:
Here is an updated version of clrtype.py that uses @property +
@clrtype.accepts/@clrtype.returns to indicate a CLR property, instead
of using _clrproperties. I think its more Pythonic in general, but
also you should be able to modify @notify_property to work with it.
Note that notify_property won't just work. You will have to change it
to propagate the func_name, arg_types, and return_type properties
from the old getter/setter function objects to the new getter/setter
function objects since these values are used by clrtype to generate
the CLR members. Something like this:
class notify_property(property):
def propagate_attributes(old_function, new_function):
new_function.func_name = old_function.func_name
new_function.arg_types = old_function.arg_types
new_function.return_type = old_function.return_type
def __init__(self, getter):
def newgetter(slf):
try:
return getter(slf)
except AttributeError:
return None
propagate_attributes(getter, newgetter)
super(notify_property, self).__init__(newgetter)
def setter(self, setter):
def newsetter(slf, newvalue):
oldvalue = self.fget(slf)
if oldvalue
Re: [IronPython] .NET attributes for methods
So the new clrtype.py still works - cool!
I am not an expert on data binding, so I don't have any suggestions. Why do you
say that the decorator approach will not work with Silverlight? Does
@notifiy_property from
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html
use any feature not available in Silverlight?
From: Lukas Cenovsky [mailto:cenov...@bakalari.cz]
Sent: Thursday, November 12, 2009 8:09 AM
To: Shri Borde
Subject: Re: [IronPython] .NET attributes for methods
Thanks, that works!
What do you think would be the best approach to create notifiable properties
for Silverlight? I did it for WPF (via decorators:
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html)
but it seems to me it won't be possible to do it similarly for Silverlight...
--
-- Lukáš
Shri Borde wrote:
Can you use _clrproperties instead of _clrfields? DevHawk's same created a
field and a property even when you just used _clrfields. I don't do that
anymore. So you will need to use _clrproperties to get properties, which SL
must use for data binding.
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Wednesday, November 11, 2009 2:37 AM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET attributes for methods
I did change __metaclass__ to ClrMetaclass. See the attached source I use for
testing - the only difference is to comment/uncomment appropriate part in
product.py.
The outputs look the same, there are no visible exceptions:
DevHawk:
py a.root.FindName('listbox1').ItemsSource[0].GetType().GetFields()
= Array[FieldInfo]((System.Reflection.RtFieldInfo object at
0x002B [Double cost],
System.Reflection.RtFieldInfo object at 0x002C [Int32 quantity],
System.Reflection.RtFieldInfo object at 0x002D [System.String
name],
System.Reflection.RtFieldInfo object at 0x002E
[IronPython.Runtime.Types.PythonType .class],
System.Reflection.RtFieldInfo object at 0x002F
[IronPython.Runtime.PythonDictionary .dict],
System.Reflection.RtFieldInfo object at 0x0030 [System.Object[]
.slots_and_weakref]))
Shri:
py a.root.FindName('listbox1').ItemsSource[0].GetType().GetFields()
= Array[FieldInfo]((System.Reflection.RtFieldInfo object at
0x002B [Double cost],
System.Reflection.RtFieldInfo object at 0x002C [Int32 quantity],
System.Reflection.RtFieldInfo object at 0x002D [System.String
name],
System.Reflection.RtFieldInfo object at 0x002E
[IronPython.Runtime.Types.PythonType .class],
System.Reflection.RtFieldInfo object at 0x002F
[IronPython.Runtime.PythonDictionary .dict],
System.Reflection.RtFieldInfo object at 0x0030 [System.Object[]
.slots_and_weakref]))
--
-- Lukáš
Shri Borde wrote:
Note that you will have to set __metaclass__ to ClrMetaclass, not
ClrTypeMetaclass as in DevHawk's sample. I had changed the name of the type.
The old name will cause a NameError, but maybe SL is hiding exceptions. Can you
do o.GetType().GetFields() and display that on the page to inspect the object
and also make sure that no exceptions were thrown?
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Tuesday, November 10, 2009 2:59 PM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET attributes for methods
I have just found that the Silverlight binding does not work with this version
of clrtype and/or IronPython 2.6RC2.
I used DevHawk demo [1] and after I added reference to Microsoft.Dynamic in
clrtypemetaclass.py it worked flawlessly. But when I switch to your version, no
items show in the listbox.
By the way - I have seen a commit message you have added support for interfaces
- nice! ;-)
--
-- Lukáš
[1]
http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/^_^_clrtype^_^_/SL%20databinding%20demo.ziphttp://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/%5E_%5E_clrtype%5E_%5E_/SL%20databinding%20demo.zip
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes for methods
Silverlight doesn't support ICustomTypeDescriptor -- that's probably why
binding is failing. You need to emit CLR properties to use data binding with
Silverlight 2 and 3.
2009/11/12 Shri Borde shri.bo...@microsoft.com
So the new clrtype.py still works - cool!
I am not an expert on data binding, so I don't have any suggestions. Why do
you say that the decorator approach will not work with Silverlight? Does
@notifiy_property from
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.htmluse
any feature not available in Silverlight?
*From:* Lukas Cenovsky [mailto:cenov...@bakalari.cz]
*Sent:* Thursday, November 12, 2009 8:09 AM
*To:* Shri Borde
*Subject:* Re: [IronPython] .NET attributes for methods
Thanks, that works!
What do you think would be the best approach to create notifiable
properties for Silverlight? I did it for WPF (via decorators:
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html)
but it seems to me it won't be possible to do it similarly for
Silverlight...
--
-- Lukáš
Shri Borde wrote:
Can you use _clrproperties instead of _clrfields? DevHawk's same
created a field and a property even when you just used _clrfields. I don't
do that anymore. So you will need to use _clrproperties to get properties,
which SL must use for data binding.
*From:* users-boun...@lists.ironpython.com [
mailto:users-boun...@lists.ironpython.comusers-boun...@lists.ironpython.com]
*On Behalf Of *Lukas Cenovsky
*Sent:* Wednesday, November 11, 2009 2:37 AM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] .NET attributes for methods
I did change __metaclass__ to ClrMetaclass. See the attached source I use
for testing - the only difference is to comment/uncomment appropriate part
in product.py.
The outputs look the same, there are no visible exceptions:
DevHawk:
py a.root.FindName('listbox1').ItemsSource[0].GetType().GetFields()
= Array[FieldInfo]((System.Reflection.RtFieldInfo object at
0x002B [Double cost],
System.Reflection.RtFieldInfo object at 0x002C [Int32 quantity],
System.Reflection.RtFieldInfo object at 0x002D [System.String
name],
System.Reflection.RtFieldInfo object at 0x002E
[IronPython.Runtime.Types.PythonType .class],
System.Reflection.RtFieldInfo object at 0x002F
[IronPython.Runtime.PythonDictionary .dict],
System.Reflection.RtFieldInfo object at 0x0030 [System.Object[]
.slots_and_weakref]))
Shri:
py a.root.FindName('listbox1').ItemsSource[0].GetType().GetFields()
= Array[FieldInfo]((System.Reflection.RtFieldInfo object at
0x002B [Double cost],
System.Reflection.RtFieldInfo object at 0x002C [Int32 quantity],
System.Reflection.RtFieldInfo object at 0x002D [System.String
name],
System.Reflection.RtFieldInfo object at 0x002E
[IronPython.Runtime.Types.PythonType .class],
System.Reflection.RtFieldInfo object at 0x002F
[IronPython.Runtime.PythonDictionary .dict],
System.Reflection.RtFieldInfo object at 0x0030 [System.Object[]
.slots_and_weakref]))
--
-- Lukáš
Shri Borde wrote:
Note that you will have to set __metaclass__ to ClrMetaclass, not
ClrTypeMetaclass as in DevHawk's sample. I had changed the name of the type.
The old name will cause a NameError, but maybe SL is hiding exceptions. Can
you do o.GetType().GetFields() and display that on the page to inspect the
object and also make sure that no exceptions were thrown?
*From:* users-boun...@lists.ironpython.com [
mailto:users-boun...@lists.ironpython.comusers-boun...@lists.ironpython.com]
*On Behalf Of *Lukas Cenovsky
*Sent:* Tuesday, November 10, 2009 2:59 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] .NET attributes for methods
I have just found that the Silverlight binding does not work with this
version of clrtype and/or IronPython 2.6RC2.
I used DevHawk demo [1] and after I added reference to Microsoft.Dynamic in
clrtypemetaclass.py it worked flawlessly. But when I switch to your version,
no items show in the listbox.
By the way - I have seen a commit message you have added support for
interfaces - nice! ;-)
--
-- Lukáš
[1]
http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/^_^_clrtype^_^_/SL%20databinding%20demo.ziphttp://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/%5E_%5E_clrtype%5E_%5E_/SL%20databinding%20demo.zip
___
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
Re: [IronPython] .NET attributes for methods
I have just found that the Silverlight binding does not work with this version of clrtype and/or IronPython 2.6RC2. I used DevHawk demo [1] and after I added reference to Microsoft.Dynamic in clrtypemetaclass.py it worked flawlessly. But when I switch to your version, no items show in the listbox. By the way - I have seen a commit message you have added support for interfaces - nice! ;-) -- -- Lukáš [1] http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/^_^_clrtype^_^_/SL%20databinding%20demo.zip http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/%5E_%5E_clrtype%5E_%5E_/SL%20databinding%20demo.zip Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes for methods
Note that you will have to set __metaclass__ to ClrMetaclass, not ClrTypeMetaclass as in DevHawk's sample. I had changed the name of the type. The old name will cause a NameError, but maybe SL is hiding exceptions. Can you do o.GetType().GetFields() and display that on the page to inspect the object and also make sure that no exceptions were thrown? From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Tuesday, November 10, 2009 2:59 PM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes for methods I have just found that the Silverlight binding does not work with this version of clrtype and/or IronPython 2.6RC2. I used DevHawk demo [1] and after I added reference to Microsoft.Dynamic in clrtypemetaclass.py it worked flawlessly. But when I switch to your version, no items show in the listbox. By the way - I have seen a commit message you have added support for interfaces - nice! ;-) -- -- Lukáš [1] http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/^_^_clrtype^_^_/SL%20databinding%20demo.ziphttp://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/%5E_%5E_clrtype%5E_%5E_/SL%20databinding%20demo.zip Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto: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
Re: [IronPython] .NET attributes for methods
I was thinking about this... Does ir mean that (after adding such support to clrtype) and building a .dll from the interface class, this class can be used from c#? -- -- Lukáš Shri Borde wrote: The clrtype module could be extended to make it possible to declare CLR interfaces in Python code. Something like: class IFoo(object): *__metaclass__ = ClrType.ClrInterface # Proposed way to indicate an interface* @clrtype.accepts(int, str) @clrtype.returns(int) @clrtype.attribute(OperationContractAttribute)() def foo(i, s):raise RuntimeError(this should not get called) This does not work today... *From:* users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lukas Cenovsky *Sent:* Friday, October 30, 2009 10:41 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] .NET attributes for methods Thanks. I wanted to implement WCF service in pure Ironpython but I overlooked the [OperationContract] method attribute is used in the interface declaration. Anyway, thanks to class attributes it is now possible to implement the WCF service in IronPython and have only the interface done in C#. See my blog post: http://gui-at.blogspot.com/2009/10/wcf-service-in-ironpython.html DllImport is good to have too - I can get rid of of my Win32API.dll when simulating user's input http://gui-at.blogspot.com/2008/07/simulate-users-input.html :-) -- -- Lukáš Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.com mailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com mailto: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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes for methods
It should be possible. However, note that you create the .dll using clr.GetSubclassedTypes (and clr.CompileSubclassedTypes) which requires you to run your application with all the scenarios you care about. You can't just run a simple command line like csc.exe foo.cs and get a dll. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Monday, November 02, 2009 9:29 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes for methods I was thinking about this... Does ir mean that (after adding such support to clrtype) and building a .dll from the interface class, this class can be used from c#? -- -- Lukáš Shri Borde wrote: The clrtype module could be extended to make it possible to declare CLR interfaces in Python code. Something like: class IFoo(object): __metaclass__ = ClrType.ClrInterface # Proposed way to indicate an interface @clrtype.accepts(int, str) @clrtype.returns(int) @clrtype.attribute(OperationContractAttribute)() def foo(i, s):raise RuntimeError(this should not get called) This does not work today... From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Friday, October 30, 2009 10:41 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes for methods Thanks. I wanted to implement WCF service in pure Ironpython but I overlooked the [OperationContract] method attribute is used in the interface declaration. Anyway, thanks to class attributes it is now possible to implement the WCF service in IronPython and have only the interface done in C#. See my blog post: http://gui-at.blogspot.com/2009/10/wcf-service-in-ironpython.html DllImport is good to have too - I can get rid of of my Win32API.dll when simulating user's inputhttp://gui-at.blogspot.com/2008/07/simulate-users-input.html :-) -- -- Lukáš Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto: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
Re: [IronPython] .NET attributes for methods
Thanks. I wanted to implement WCF service in pure Ironpython but I overlooked the [OperationContract] method attribute is used in the interface declaration. Anyway, thanks to class attributes it is now possible to implement the WCF service in IronPython and have only the interface done in C#. See my blog post: http://gui-at.blogspot.com/2009/10/wcf-service-in-ironpython.html DllImport is good to have too - I can get rid of of my Win32API.dll when simulating user's input http://gui-at.blogspot.com/2008/07/simulate-users-input.html :-) -- -- Lukáš Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes for methods
The clrtype module could be extended to make it possible to declare CLR interfaces in Python code. Something like: class IFoo(object): __metaclass__ = ClrType.ClrInterface # Proposed way to indicate an interface @clrtype.accepts(int, str) @clrtype.returns(int) @clrtype.attribute(OperationContractAttribute)() def foo(i, s):raise RuntimeError(this should not get called) This does not work today... From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Friday, October 30, 2009 10:41 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes for methods Thanks. I wanted to implement WCF service in pure Ironpython but I overlooked the [OperationContract] method attribute is used in the interface declaration. Anyway, thanks to class attributes it is now possible to implement the WCF service in IronPython and have only the interface done in C#. See my blog post: http://gui-at.blogspot.com/2009/10/wcf-service-in-ironpython.html DllImport is good to have too - I can get rid of of my Win32API.dll when simulating user's inputhttp://gui-at.blogspot.com/2008/07/simulate-users-input.html :-) -- -- Lukáš Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto: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
Re: [IronPython] .NET attributes
On 9/14/06, Dino Viehland [EMAIL PROTECTED] wrote:
We're tentatively thinking that this is a 2.0 feature but if we figured out a
syntax we really liked we'd try to get it into 1.1.
It seems as if there are two clean ways to do this in my mind.
1. Use python2.4's decorator sytax and extend it to allow class and
class variable attribute declaration. This has the pitfall of
breaking cpython compatibility with decorators though. At the same
time, why use decorators when you can use attributes?
2. Thinking about this problem brings me back to an elegant solution
that Philip Eby came up with to allow python2.3 users to use
decorators for turbogears.
class Root:
[expose()]
def method(): ...
Granted special logic has to be added to the decorator method. This
prompted me to try:
import clr
clr.AddReference('System.Web.Services')
from System.Web.Services import *
[WebServiceAttribute]
class Echo(WebService):
[WebMethodAttribute]
def echo(msg):
return msg
The advantage here is syntactically correct python. IP could just add
some special logic to apply the attributes. Another advantage is that
it matches the sytax of C# attributes. Evil programmers could even
apply decorators and attributes to a method!
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote:
On 9/14/06, Dino Viehland [EMAIL PROTECTED] wrote:
We're tentatively thinking that this is a 2.0 feature but if we figured out
a syntax we really liked we'd try to get it into 1.1.
It seems as if there are two clean ways to do this in my mind.
1. Use python2.4's decorator sytax and extend it to allow class and
class variable attribute declaration. This has the pitfall of
breaking cpython compatibility with decorators though. At the same
time, why use decorators when you can use attributes?
When this was last discussed on Python-Dev, Guido agreed that class
decorators could go into core Python. (Partly because of the IronPython
usecase.)
The best thing to do (IMHO) is to see if a syntax can be agreed on
Python-Dev, to ensure future compatibility with CPython.
Michael Foord
http://www.voidspace.org.uk/python/index.shtml
2. Thinking about this problem brings me back to an elegant solution
that Philip Eby came up with to allow python2.3 users to use
decorators for turbogears.
class Root:
[expose()]
def method(): ...
Granted special logic has to be added to the decorator method. This
prompted me to try:
import clr
clr.AddReference('System.Web.Services')
from System.Web.Services import *
[WebServiceAttribute]
class Echo(WebService):
[WebMethodAttribute]
def echo(msg):
return msg
The advantage here is syntactically correct python. IP could just add
some special logic to apply the attributes. Another advantage is that
it matches the sytax of C# attributes. Evil programmers could even
apply decorators and attributes to a method!
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
We're tentatively thinking that this is a 2.0 feature but if we figured out a syntax we really liked we'd try to get it into 1.1. It seems as if there are two clean ways to do this in my mind. 1. Use python2.4's decorator sytax and extend it to allow class and class variable attribute declaration. This has the pitfall of breaking cpython compatibility with decorators though. At the same time, why use decorators when you can use attributes? When this was last discussed on Python-Dev, Guido agreed that class decorators could go into core Python. (Partly because of the IronPython usecase.) The best thing to do (IMHO) is to see if a syntax can be agreed on Python-Dev, to ensure future compatibility with CPython. I agree. A proof of concept that demonstrates the use of class decorators might help them decide. -H. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: On 9/14/06, Dino Viehland [EMAIL PROTECTED] wrote: We're tentatively thinking that this is a 2.0 feature but if we figured out a syntax we really liked we'd try to get it into 1.1. It seems as if there are two clean ways to do this in my mind. 1. Use python2.4's decorator sytax and extend it to allow class and class variable attribute declaration. This has the pitfall of breaking cpython compatibility with decorators though. At the same time, why use decorators when you can use attributes? When this was last discussed on Python-Dev, Guido agreed that class decorators could go into core Python. (Partly because of the IronPython usecase.) What about class variables, properties, etc? The AttributeTargets enum lists many options. I don't see cpython allowing decorators on properties. Also, decorators and attributes are different beasts. Allowing their syntax to be the same would make it difficult to distingush which way it should be used. I personally think attribute support should trump decorator support in IP. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote: On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: On 9/14/06, Dino Viehland [EMAIL PROTECTED] wrote: We're tentatively thinking that this is a 2.0 feature but if we figured out a syntax we really liked we'd try to get it into 1.1. It seems as if there are two clean ways to do this in my mind. 1. Use python2.4's decorator sytax and extend it to allow class and class variable attribute declaration. This has the pitfall of breaking cpython compatibility with decorators though. At the same time, why use decorators when you can use attributes? When this was last discussed on Python-Dev, Guido agreed that class decorators could go into core Python. (Partly because of the IronPython usecase.) What about class variables, properties, etc? The AttributeTargets enum lists many options. I don't see cpython allowing decorators on properties. Also, decorators and attributes are different beasts. Allowing their syntax to be the same would make it difficult to distingush which way it should be used. I personally think attribute support should trump decorator support in IP. Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... David ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Also attributes being classes and decorators functions might help. I agree it is better to allow the decorator syntax in more places than cpython than the alternative. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote: Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Sounds very good. Also attributes being classes and decorators functions might help. Can't CPython decorators also be classes (I haven't tried this) ? Michael Foord http://www.voidspace.org.uk/python/index.shtml I agree it is better to allow the decorator syntax in more places than cpython than the alternative. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Sounds very good. Also attributes being classes and decorators functions might help. Can't CPython decorators also be classes (I haven't tried this) ? Callable classes I suppose ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote:
On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote:
Charlie Moad wrote:
Take away decorator support and you'll lose at least this Python
programmer...
Decorators and attributes have at least some commonality, which is why
this syntax ended up in Python in the first place...
Allowing decorator syntax in places CPython doesn't is better than not
allowing it where it does...
So it sounds like people want decorator syntax for attributes. Would
it be sufficient to check for inheritance from System.Attribute to
distinguish the two?
Sounds very good.
Also attributes being classes and decorators
functions might help.
Can't CPython decorators also be classes (I haven't tried this) ?
Callable classes I suppose
You mean instances...
I meant something like this, which works in CPython and is a good way of
implementing the descriptor protocol :
class DecoratorClass(object):
def __init__(self, function):
self.function = function
def __call__(self, *args, **keywargs):
print 'called'
return self.function(*args, **keywargs)
Michael Foord
http://www.voidspace.org.uk/python/index.shtml
@DecoratorClass
def function(*args):
print args
function('hello')
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie Moad wrote:
On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote:
Charlie Moad wrote:
Take away decorator support and you'll lose at least this Python
programmer...
Decorators and attributes have at least some commonality, which is why
this syntax ended up in Python in the first place...
Allowing decorator syntax in places CPython doesn't is better than not
allowing it where it does...
So it sounds like people want decorator syntax for attributes. Would
it be sufficient to check for inheritance from System.Attribute to
distinguish the two?
Sounds very good.
Also attributes being classes and decorators
functions might help.
Can't CPython decorators also be classes (I haven't tried this) ?
Callable classes I suppose
(Oops... put my sig in the middle of the code.)
You mean instances...
I meant something like this, which works in CPython and is a good way of
implementing the descriptor protocol :
class DecoratorClass(object):
def __init__(self, function):
self.function = function
def __call__(self, *args, **keywargs):
print 'called'
return self.function(*args, **keywargs)
@DecoratorClass
def function(*args):
print args
function('hello')
Provide '__get__' and friends to implement the descriptor protocol on a
function. My guess is that this is pretty much how class methods become
bound methods on instances.
Michael Foord
http://www.voidspace.org.uk/python/index.shtml
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Unfortunately, CPython only allows the decorator syntax before a function declaration... You could always manually call the decorator function w/ the class object and see what you get back though. Charlie's earlier point about all the different targets is a really good one though - worse than even properties are things like arguments, return types, etc... that won't fit in at all w/ decorators. You could imagine allowing the syntax anywhere, but there'd be no way to disambiguate between a return decorator and a function decorator in Python. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Moad Sent: Friday, September 15, 2006 7:46 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Sounds very good. Also attributes being classes and decorators functions might help. Can't CPython decorators also be classes (I haven't tried this) ? Callable classes I suppose ___ 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
Re: [IronPython] .NET attributes
Charlie's earlier point about all the different targets is a really good one though - worse than even properties are things like arguments, return types, etc... that won't fit in at all w/ decorators. You could imagine allowing the syntax anywhere, but there'd be no way to disambiguate between a return decorator and a function decorator in Python. By using attribute-target specifiers? (type, property, param, field, etc.) -H. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Dino Viehland wrote: Unfortunately, CPython only allows the decorator syntax before a function declaration... You could always manually call the decorator function w/ the class object and see what you get back though. Charlie's earlier point about all the different targets is a really good one though - worse than even properties are things like arguments, return types, etc... that won't fit in at all w/ decorators. You could imagine allowing the syntax anywhere, but there'd be no way to disambiguate between a return decorator and a function decorator in Python. It's uglier, but what about providing built in functions for applying attributes. A specific built-in could apply return attributes etc. This at least avoids the problem of adding a syntax that is incompatible with CPython. Michael Foord http://www.voidspace.org.uk/python/index.shtml -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Moad Sent: Friday, September 15, 2006 7:46 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes On 9/15/06, Michael Foord [EMAIL PROTECTED] wrote: Charlie Moad wrote: Take away decorator support and you'll lose at least this Python programmer... Decorators and attributes have at least some commonality, which is why this syntax ended up in Python in the first place... Allowing decorator syntax in places CPython doesn't is better than not allowing it where it does... So it sounds like people want decorator syntax for attributes. Would it be sufficient to check for inheritance from System.Attribute to distinguish the two? Sounds very good. Also attributes being classes and decorators functions might help. Can't CPython decorators also be classes (I haven't tried this) ? Callable classes I suppose ___ 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 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.4/448 - Release Date: 14/09/2006 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] .NET attributes
What is the expected timeline for support for .NET attributes in IronPython? -- Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes
Charlie is correct. Remember that the IronPython VSIntegration sample is really
for two different set of folks:
1.) People using IronPython
2.) People trying to integrate their language into Visual Studio
In the case of IronPython web services, the project templates were included
only for completeness of the sample for set #2, even though (as has been
noted) they are non-functional due to reliance on .NET attributes.
The WebSite projects ('Venus' and Web Application Project - style) *are*
usable, although there are still a number of language and integration issues to
get them working better (e.g. event handler generation from the web designer
doesn't work, debugging is broken in certain scenarios). More details will be
forthcoming when the V3 Visual Studio 2005 SDK ships (should be any day now).
Thanks,
Aaron Marten
From: [EMAIL PROTECTED] On Behalf Of Charlie Moad
Sent: Wednesday, September 13, 2006 5:42 AM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET attributes
I have seen these examples, but my impression was that they are not
useable. The generic web site one may be, but I am pretty sure the
web service example does not expose any methods as services.
On 9/13/06, S H Yoon [EMAIL PROTECTED] wrote:
C:\Program Files\Visual Studio
2005SDK\2006.08\VisualStudioIntegration\Samples\IronPythonIntegration\WebSiteProj
ect\WebSiteProject.proj
Seems like here and below this tree. I see plenty of examples of IPY web
including Webservice. Is there a good guide to these? I am compeletly
ignorant about ASP.net / Web developement, but I would love learn how via
IP.
Yes, IP is one hellauba sharp job,
Hoon,
Charlie Moad [EMAIL PROTECTED] wrote:
On 9/13/06, Sanghyeon Seo wrote:
What is the expected timeline for support for .NET attributes in
IronPython?
I know this has probably been brought up before, but I wanted to speak
up to maybe put a little more priority behind this. I personally feel
limited many times because there isn't attribute support in IP. To my
knowledge I can't do relatively simple things like asp.net web
services. Also fine grained xml serialization doesn't seem doable as
well. If I am wrong, please Please correct me! It could be the fact
that most XML related functionality in .Net relies heavily on
attributes, but they seem prevalent everywhere.
Keep up the great work,
Charlie
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
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
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] NET Attributes.
Thanks for all the info. I was looking into using IP with AutoCAD and .NET attributes are required.tjrOn 7/26/06, Michael Foord
[EMAIL PROTECTED] wrote:Martin Maly wrote: Unfortunately, no. Adding .NET attributes on Python classes in
IronPython is not possible. Somewhat similar Pythonic thing is function and method decorators: @command("MyCommand", CommandFlags.Modal) def RunMyCommand():
…. However, this will not interoperate well with .NET since .NET is not aware of the decorator mechanism. For more information, you can check out:
http://docs.python.org/whatsnew/node6.html There is another option to use function doc strings, but that would be more complicated to use and I'd probably use it as one of the last resorts.
However if you need to mark a class as serializable (or use any other.NET attribute), you just can't do it from IronPython at the moment. :-(Fuzzyman
http://www.voidspace.org.uk/python/index.shtml Martin *From:*
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] *On Behalf Of *Tim Riley *Sent:* Wednesday, July 26, 2006 10:17 AM
*To:* Discussion of IronPython *Subject:* [IronPython] NET Attributes. Is it possible to use .NET attributes in IronPython? For example I have C# code that looks like: [CommandMethod(MyCommand,
CommandFlags.Modal)] public static void RunMyCommand() { 'code here } Can I do something similiar in IP? I'll take anything.
___ users mailing list users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com___users mailing listusers@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
[IronPython] NET Attributes.
Is it possible to use .NET attributes in IronPython? For example I have C# code that looks like:[CommandMethod(MyCommand, CommandFlags.Modal)]public static void RunMyCommand(){ 'code here
}Can I do something similiar in IP? I'll take anything.
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] NET Attributes.
Martin Maly wrote:
Unfortunately, no. Adding .NET attributes on Python classes in
IronPython is not possible.
Somewhat similar Pythonic thing is function and method decorators:
@command(“MyCommand”, CommandFlags.Modal)
def RunMyCommand():
….
However, this will not interoperate well with .NET since .NET is not
aware of the decorator mechanism.
For more information, you can check out:
http://docs.python.org/whatsnew/node6.html
There is another option to use function doc strings, but that would be
more complicated to use and I’d probably use it as one of the last
resorts.
However if you need to mark a class as serializable (or use any other
.NET attribute), you just can't do it from IronPython at the moment. :-(
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
Martin
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Tim Riley
*Sent:* Wednesday, July 26, 2006 10:17 AM
*To:* Discussion of IronPython
*Subject:* [IronPython] NET Attributes.
Is it possible to use .NET attributes in IronPython? For example I
have C# code that looks like:
[CommandMethod(MyCommand, CommandFlags.Modal)]
public static void RunMyCommand()
{
'code here
}
Can I do something similiar in IP? I'll take anything.
___
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
Re: [IronPython] .NET Attributes
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
[IronPython] .NET Attributes
Hi, When there will be support for .NET Attributes in IronPython? Is there any way currently to mark my class as Serializable? -- Andrzej ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET Attributes
This is a tough problem... There are two issues here. But the executive summary here is I'd say the earliest you should *expect* to see this is 1.1, but if (somehow) we end up with some extra time we might have something in the 1.0 timeframe (but don't hold your breath!). The first issue here is that when your code gets compiled we don't create what are truly .NET classes. Let's forget about old-style classes for a second (as those are REALLY not .NET classes, and never will be) and instead focus on new-style classes. When you define a class we'll see if anyone else has inherited from the same set of base-types (including .NET interfaces). If someone has then we'll use that class instead of creating a new class. If they haven't we'll derive a new class from your base-class set, overriding all of the virtual methods, and creating some new fields like __dict__ and __class__. Those fields allow us to both allow you to change the type of your classes at runtime as well as attach new properties to instances. They also allow us to create a limited number of CLR types (which aren't garbage collected) which means long-running programs creating lots of types don't leak. In the end there's not really anything good for us to attach the attributes to. To get that we'd need to move to a more static-compilation model while at the same time retaining the ability to do all the great dynamic stuff with Python. It's a hard problem and one that we simply haven't solved yet. The second problem is also just as tough, but it's completely different. How do you even express an attribute on a class? There's no Python syntax for this so we'd have to add something new. It'd be great if we could use decorators here, but they don't apply to classes. So maybe that's something like __attributes__ = [Serializable, ...] or something along those lines but it's not clear what's the best way to go here... 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 Andrzej Krzywda Sent: Monday, March 27, 2006 4:55 AM To: users@lists.ironpython.com Subject: [IronPython] .NET Attributes Hi, When there will be support for .NET Attributes in IronPython? Is there any way currently to mark my class as Serializable? -- Andrzej ___ 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
Re: [IronPython] .NET Attributes
On the topic of decorators and integrating with .NET, it seems that in order to keep IronPython as close to CPython, it would be a good idea to consider adding .NET specific pieces as a library instead of an addition to the language. That way people could write python code that works in IronPython and CPython equally well without changing radically how the code is written. For example, if I wanted to make a class serializable, it seems logical to inherit from some serializable base class. from clr.netisms import IPSerializableclass MyClass(IPSerializable):This may be an obvious solution, but it seems to make more sense to add IronPython specific libraries to help integrate with .NET than to pollute the language. I mention this because one of the great things about Python is the batteries included mentality. There are many great libraries that would be excellent to run using IronPython (ZODB for example) that may conflict if the language gets massaged to fit into .NET perfectly. Often times writing to the lowest common denominator can be bad (SQL portability for example), but I believe in the case of Python, whatever can be done to work with the massive amount of libraries will be the most beneficial. I apologize if this is already addressed. I am thinking about issues such as these from a python programmer's perspective.Great work!EricOn 3/27/06, Dino Viehland [EMAIL PROTECTED] wrote: This is a tough problem...There are two issues here.But the executive summary here is I'd say the earliest you should *expect* to see this is 1.1, but if (somehow) we end up with some extra time we might have something in the 1.0 timeframe (but don't hold your breath!).The first issue here is that when your code gets compiled we don't create what are truly .NET classes.Let's forget about old-style classes for a second (as those are REALLY not .NET classes, and never will be) and instead focus on new-style classes. When you define a class we'll see if anyone else has inherited from the same set of base-types (including .NET interfaces).If someone has then we'll use that class instead of creating a new class.If they haven't we'll derive a new class from your base-class set, overriding all of the virtual methods, and creating some new fields like __dict__ and __class__.Those fields allow us to both allow you to change the type of your classes at runtime as well as attach new properties to instances.They also allow us to create a limited number of CLR types (which aren't garbage collected) which means long-running programs creating lots of types don't leak. In the end there's not really anything good for us to attach the attributes to.To get that we'd need to move to a more static-compilation model while at the same time retaining the ability to do all the great dynamic stuff with Python.It's a hard problem and one that we simply haven't solved yet. The second problem is also just as tough, but it's completely different.How do you even express an attribute on a class?There's no Python syntax for this so we'd have to add something new.It'd be great if we could use decorators here, but they don't apply to classes.So maybe that's something like __attributes__ = [Serializable, ...] or something along those lines but it's not clear what's the best way to go here... 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 Andrzej KrzywdaSent: Monday, March 27, 2006 4:55 AMTo: users@lists.ironpython.comSubject: [IronPython] .NET AttributesHi,When there will be support for .NET Attributes in IronPython? Is there any way currently to mark my class as Serializable?--Andrzej___users mailing listusers@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com___users mailing list users@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET Attributes
This is great feedback. And yet another way we could consider doing this would be something whacky with metaclasses where we had an attribute-aware metaclass or something like that But it demonstrates the difficulty in adding support for features like this and the reason we need to tread lightly here. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Larson Sent: Monday, March 27, 2006 9:11 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET Attributes On the topic of decorators and integrating with .NET, it seems that in order to keep IronPython as close to CPython, it would be a good idea to consider adding .NET specific pieces as a library instead of an addition to the language. That way people could write python code that works in IronPython and CPython equally well without changing radically how the code is written. For example, if I wanted to make a class serializable, it seems logical to inherit from some serializable base class. from clr.netisms import IPSerializable class MyClass(IPSerializable): This may be an obvious solution, but it seems to make more sense to add IronPython specific libraries to help integrate with .NET than to pollute the language. I mention this because one of the great things about Python is the batteries included mentality. There are many great libraries that would be excellent to run using IronPython (ZODB for example) that may conflict if the language gets massaged to fit into .NET perfectly. Often times writing to the lowest common denominator can be bad (SQL portability for example), but I believe in the case of Python, whatever can be done to work with the massive amount of libraries will be the most beneficial. I apologize if this is already addressed. I am thinking about issues such as these from a python programmer's perspective. Great work! Eric On 3/27/06, Dino Viehland [EMAIL PROTECTED] wrote: This is a tough problem...There are two issues here.But the executive summary here is I'd say the earliest you should *expect* to see this is 1.1, but if (somehow) we end up with some extra time we might have something in the 1.0 timeframe (but don't hold your breath!). The first issue here is that when your code gets compiled we don't create what are truly .NET classes.Let's forget about old-style classes for a second (as those are REALLY not .NET classes, and never will be) and instead focus on new-style classes. When you define a class we'll see if anyone else has inherited from the same set of base-types (including .NET interfaces).If someone has then we'll use that class instead of creating a new class.If they haven't we'll derive a new class from your base-class set, overriding all of the virtual methods, and creating some new fields like __dict__ and __class__.Those fields allow us to both allow you to change the type of your classes at runtime as well as attach new properties to instances.They also allow us to create a limited number of CLR types (which aren't garbage collected) which means long-running programs creating lots of types don't leak. In the end there's not really anything good for us to attach the attributes to.To get that we'd need to move to a more static-compilation model while at the same time retaining the ability to do all the great dynamic stuff with Python.It's a hard problem and one that we simply haven't solved yet. The second problem is also just as tough, but it's completely different.How do you even express an attribute on a class?There's no Python syntax for this so we'd have to add something new.It'd be great if we could use decorators here, but they don't apply to classes.So maybe that's something like __attributes__ = [Serializable, ...] or something along those lines but it's not clear what's the best way to go here... 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 Andrzej Krzywda Sent: Monday, March 27, 2006 4:55 AM To: users@lists.ironpython.com Subject: [IronPython] .NET Attributes Hi, When there will be support for .NET Attributes in IronPython? Is there any way currently to mark my class as Serializable? -- Andrzej ___ 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 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users
Re: [IronPython] .NET Attributes
For the purposes of consistency, the attribute decorators would need to apply everywhere an attribute is able to exist in .NET: types, members, etc. In the case of Serializable, merely subclassing ISerializable isn't necessarily the best way, since a class can be decorated with SerializableAttribute instead. Would magic comments be sufficient? eg // ATTRIBUTE: Serializeable class MyClass(FooBase): // ATTRIBUTE: MyMemberAttribute def Foo(): (Forgive my Python -- it's a little rusty...) Actually, wasn't there a PEP regarding decorators? winmail.dat___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
