You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be even better to have an import hook that installs the extension-functions automatically. I guess the over-loading is the biggest problem here (i.e. we already have a function ToString() implemented for a class and have an extension providing ToString(string format)).
Is there any particular reason why this is done up-front instead of having a dynamic (cached?) __getattribute__ function that does this on-demand? That would enable us to just invalidate the cache when extensions are imported.
Yes, using those as static methods works, but can be quite annoying.
In my opinion, fixing this involves changing how the method resolution works, in that it should be deferred to call-time. Currently, the method objects are built up-front and there is no way to trigger a "refresh".
Unfeasible in some cases. When using a .NET library that defines objects which make use of extension methods, you don't know which ones make use of the extension methods. That would be a very hard thing to document in an API as a library author. As a consumer, you get a dll and a help file - not a list of which classes in the API make use of extension methods. You most often don't even know which objects to apply this model to until you see it fail - if you understand the exception thrown.
A group of us have been using IronPython 2.7 for 3 years now. As a previous user of python .NET years before, I'd really like to move onto CPython 3,5 with python .net now that it's active again but this limitation would be a bit crippling as we make use of extension methods a lot.
I'm not quite sure I understand what you are getting at. This feature is only about supporting the shortcut
ExtensionClass.Func(obj)
=>
obj.Func()
within Python. This resolution is done by the C# compiler up-front AFAIK, that is why the extension method shortcut is not supported on dynamic objects.
My proposal of how to achieve this is that the __getattr__ method of a random .NET object should be modeled after the normal C# resolution order, i.e. first check if there is a public method on the object itself and then check for fitting extension methods. This is quite a bit different from how it's implemented currently.
I'm sorry I was not clear. I'm only hoping to be able to call the method as a member of the class (the way you showed it with obj.Func() ) as well as be able to see 'Func' show up for tab completion / intellisense for 'obj.' which you also touched on earlier. Nothing different from what you were describing - I was only commenting on why it is difficult to go without these two items.
Activity
den-run-ai commentedon Dec 30, 2014
here is the background:
http://stackoverflow.com/questions/628482/can-you-use-linq-types-and-extension-methods-in-ironpython
filmor commentedon Jan 6, 2015
It would be even better to have an import hook that installs the extension-functions automatically. I guess the over-loading is the biggest problem here (i.e. we already have a function
ToString()implemented for a class and have an extension providingToString(string format)).filmor commentedon Jun 29, 2015
According to this http://stackoverflow.com/questions/299515/reflection-to-identify-extension-methods it's quite easy to at least find the correct
MethodInfoobjects. From skimming the Python.NET code I'd guess that we'd have to rebuild the method objects whenever extensions are imported.Is there any particular reason why this is done up-front instead of having a dynamic (cached?)
__getattribute__function that does this on-demand? That would enable us to just invalidate the cache when extensions are imported.tonyroberts commentedon Jun 29, 2015
One nice side-effect of having the methods built up-front is that you get tab completion in ipython.
filmor commentedon Jun 29, 2015
That we get also by overloading
__dir__which I intend to do anyhow toimplement DLR stuff.
tonyroberts commentedon Jun 29, 2015
oh ok, yeah in that case I can't immediately think of any reason not to do it dynamically.
bastelflp commentedon Jun 23, 2016
Is there any update on this issue?
lcorrigan commentedon Jul 10, 2016
I'm also quite curious of the status of this.
den-run-ai commentedon Jul 15, 2016
Can't you just use the extension method as static method?
It looks the extension mechanisms was not added to DLR, but somehow
ironpython has it.
On Saturday, July 9, 2016, lcorrigan [email protected] wrote:
filmor commentedon Jul 15, 2016
Yes, using those as static methods works, but can be quite annoying.
In my opinion, fixing this involves changing how the method resolution works, in that it should be deferred to call-time. Currently, the method objects are built up-front and there is no way to trigger a "refresh".
lcorrigan commentedon Jul 18, 2016
Unfeasible in some cases. When using a .NET library that defines objects which make use of extension methods, you don't know which ones make use of the extension methods. That would be a very hard thing to document in an API as a library author. As a consumer, you get a dll and a help file - not a list of which classes in the API make use of extension methods. You most often don't even know which objects to apply this model to until you see it fail - if you understand the exception thrown.
A group of us have been using IronPython 2.7 for 3 years now. As a previous user of python .NET years before, I'd really like to move onto CPython 3,5 with python .net now that it's active again but this limitation would be a bit crippling as we make use of extension methods a lot.
filmor commentedon Jul 18, 2016
I'm not quite sure I understand what you are getting at. This feature is only about supporting the shortcut
within Python. This resolution is done by the C# compiler up-front AFAIK, that is why the extension method shortcut is not supported on
dynamicobjects.My proposal of how to achieve this is that the
__getattr__method of a random .NET object should be modeled after the normal C# resolution order, i.e. first check if there is a public method on the object itself and then check for fitting extension methods. This is quite a bit different from how it's implemented currently.lcorrigan commentedon Jul 18, 2016
I'm sorry I was not clear. I'm only hoping to be able to call the method as a member of the class (the way you showed it with obj.Func() ) as well as be able to see 'Func' show up for tab completion / intellisense for 'obj.' which you also touched on earlier. Nothing different from what you were describing - I was only commenting on why it is difficult to go without these two items.
vmuriart commentedon Feb 24, 2017
This SO question has an example we can use for testing.
http://stackoverflow.com/questions/35207064/python-for-net-and-c-sharp-extensions-signalr-client-in-python-on-method-not
den-run-ai commentedon Feb 24, 2017
@vmuriart TDD :)
slide commentedon Jan 21, 2022
The code for IronPython for extension methods can be found here:
https://github.com/IronLanguages/ironpython2/blob/master/Src/IronPython/Runtime/Binding/MetaUserObject.Members.cs#L1402
matthiasburger commentedon Feb 14, 2023
is there any update on this? using EFCore with Python.NET doesn't work pretty good without Linq-Extensionsmethods... :)
Add CICD (pythonnet#55)