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
When trying to run the numpy example from the Readme file I see the following error:
TypeError : long() argument must be a string or a number, not '0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]'
This seems to be cause by the Py.kw function call. However, the numpy.array does not seem to be working properly. The console output looks like this:
This is from using the latest master branch and Python 2.7. Has the array handling changed recently?
If you are willing to write tests (preferrably without numpy dependency, just using built-in array.array), or find exactly which version broke this (somewhere around 2013-2014), then please let me know, so that we can assist you, since I consider this feature pretty important.
There is a marginally less ancient branch that worked (as far as I remember) here: https://github.com/patstew/pythonnet
I'm not sure when it broke, I don't use .net anymore.
It's been a while, but as far as I remember it's a limitation of Microsoft's DynamicObject API. They only override the operations for TryBinaryOperation where the DynamicObject is first. I believe you could fix it by using the lower-level DynamicMetaObject, but using that API requires a load more code.
You can always explicitly convert the right operand if you need to do a divide or shift or something else that doesn't easily swap.
The relevant stuff that I wrote is here: patstew@0bd8c47
Oh, I see that this is DLR limitation, and confirmed by MS team. The
suggestion in this thread is to implement dynamic operators (-, +, *, etc.)
for arbitrary order to work:
It's been a while, but as far as I remember it's a limitation of
Microsoft's DynamicObject API. They only override the operations for
TryBinaryOperation where the DynamicObject is first. I believe you could
fix it by using the lower-level DynamicMetaObject, but using that API
requires a load more code. I think.
The relevant stuff that I wrote is here: patstew/pythonnet@0bd8c47 patstew@0bd8c47
@denfromufa it looks like you may be looking in to this already. I can try to narrow down where this broke. I agree it is an important feature. I can't commit to when I will be able to start looking at this however. Hopefully soon.
Does this prevent normal implicit operator declarations from working? Using two pure .NET objects through python I'm getting a cast error. The equivalent code in .NET would work fine (when it goes through the implicit operator)
I believe implicit operator does not work and please open a separate issue
for this, since it is not related to this issue. In IronPython a special
conversion function is provided due to this limitation:
Does this prevent normal implicit operator declarations from working?
Using two pure .NET objects through python I'm getting a cast error. The
equivalent code in .NET would work fine (when it goes through the implicit
operator)
It requires some changes to the converter thats why I'm holding it off till next release since we already have a couple changes to converter/method override on this release.
Activity
den-run-ai commentedon Aug 23, 2016
@ShoTskii I found the version that was working. It actually took me few hours! This used to work in 2013:
fkarb/pythonnet_old@1cfd7e2
It looks like this was originally implemented by @patstew and then merged by @tonyroberts. (f3ff88d)
If you are willing to write tests (preferrably without numpy dependency, just using built-in array.array), or find exactly which version broke this (somewhere around 2013-2014), then please let me know, so that we can assist you, since I consider this feature pretty important.
patstew commentedon Aug 23, 2016
There is a marginally less ancient branch that worked (as far as I remember) here: https://github.com/patstew/pythonnet
I'm not sure when it broke, I don't use .net anymore.
den-run-ai commentedon Aug 23, 2016
@patstew can you also explain why arithmetic is implemented like this?
patstew commentedon Aug 23, 2016
It's been a while, but as far as I remember it's a limitation of Microsoft's DynamicObject API. They only override the operations for TryBinaryOperation where the DynamicObject is first. I believe you could fix it by using the lower-level DynamicMetaObject, but using that API requires a load more code.
You can always explicitly convert the right operand if you need to do a divide or shift or something else that doesn't easily swap.
The relevant stuff that I wrote is here: patstew@0bd8c47
den-run-ai commentedon Aug 23, 2016
Oh, I see that this is DLR limitation, and confirmed by MS team. The
suggestion in this thread is to implement dynamic operators (-, +, *, etc.)
for arbitrary order to work:
http://stackoverflow.com/questions/2075649/dynamicobject-implicit-casting
Here is the issue I was getting before for exactly this reason:
#86
On Tue, Aug 23, 2016 at 12:17 PM, patstew notifications@github.com wrote:
brenzo90 commentedon Aug 24, 2016
@denfromufa it looks like you may be looking in to this already. I can try to narrow down where this broke. I agree it is an important feature. I can't commit to when I will be able to start looking at this however. Hopefully soon.
Thraka commentedon Aug 31, 2016
Does this prevent normal
implicit operatordeclarations from working? Using two pure .NET objects through python I'm getting a cast error. The equivalent code in .NET would work fine (when it goes through the implicit operator)den-run-ai commentedon Aug 31, 2016
I believe implicit operator does not work and please open a separate issue
for this, since it is not related to this issue. In IronPython a special
conversion function is provided due to this limitation:
http://www.voidspace.org.uk/ironpython/dark-corners.shtml#implicit-conversion
On Tue, Aug 30, 2016 at 11:05 PM, Andy De George notifications@github.com
wrote:
Update README.md
vmuriart commentedon Feb 17, 2017
@denfromufa I found out today that
numpyis pre-installed in Travis build workers. We could use those if we ever get the embedded tests running.vmuriart commentedon Mar 7, 2017
Looks like this broke during the Develop/Py3 branch merges. 26cc77b.
Correction, post merge it worked until two commits later, eb825df broke it. That commit was trying to replicate this one 471673a.
Reverting eb825df fixes the issue, but breaks many things within python tests.
vmuriart commentedon Mar 8, 2017
I got this issue fixed, I'll merge in the fix after
v2.3.0releaseden-run-ai commentedon Mar 8, 2017
@vmuriart this is great! @JimSEOW was looking for this fix:
ncgeib/PythonInterface#2 (comment)
vmuriart commentedon Mar 8, 2017
It requires some changes to the converter thats why I'm holding it off till next release since we already have a couple changes to converter/method override on this release.
Fix numpy array and README example
vmuriart commentedon Mar 12, 2017
#427 will fix this in case anyone wants to review
Fix numpy array and README example (#427)
Fix numpy array and README example (pythonnet#427)
Rebase with master (#2)