Skip to content

Errors with example calling Python from .NET #249

Closed

Description

@brenzo90

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:

image

This is from using the latest master branch and Python 2.7. Has the array handling changed recently?

Activity

  1. den-run-ai commented on Aug 23, 2016

    @den-run-ai
    Contributor

    @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.

    image

  2. patstew commented on Aug 23, 2016

    @patstew
    Contributor

    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.

  3. den-run-ai commented on Aug 23, 2016

    @den-run-ai
    Contributor

    @patstew can you also explain why arithmetic is implemented like this?

    Mathematical operations involving python and literal/managed types must have the python object first, eg np.pi2 works, 2np.pi doesn't
    
  4. patstew commented on Aug 23, 2016

    @patstew
    Contributor

    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

  5. den-run-ai commented on Aug 23, 2016

    @den-run-ai
    Contributor

    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:

    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

    —
    You are receiving this because you commented.
    Reply to this email directly, view it on GitHub
    #249 (comment),
    or mute the thread
    https://github.com/notifications/unsubscribe-auth/AHgZ5Q8rBS_NwWml2PJEahiFnGrGgGLUks5qiysdgaJpZM4JqZjA
    .

  6. self-assigned this
    on Aug 24, 2016
  7. added this to the 2.2.0 milestone on Aug 24, 2016
  8. brenzo90 commented on Aug 24, 2016

    @brenzo90
    Author

    @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.

  9. Thraka commented on Aug 31, 2016

    @Thraka

    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)

  10. den-run-ai commented on Aug 31, 2016

    @den-run-ai
    Contributor

    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:

    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)

    —
    You are receiving this because you were mentioned.
    Reply to this email directly, view it on GitHub
    #249 (comment),
    or mute the thread
    https://github.com/notifications/unsubscribe-auth/AHgZ5Q2DVj1v7SnMmqb9bRXurMDnNXczks5qlP2QgaJpZM4JqZjA
    .

  11. added a commit that references this issue on Sep 9, 2016
  12. modified the milestones: 2.3.0, 2.2.0 on Feb 2, 2017
  13. vmuriart commented on Feb 17, 2017

    @vmuriart
    Contributor

    @denfromufa I found out today that numpy is pre-installed in Travis build workers. We could use those if we ever get the embedded tests running.

  14. vmuriart commented on Mar 7, 2017

    @vmuriart
    Contributor

    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.

  15. modified the milestones: 2.4.0, 2.3.0 on Mar 8, 2017
  16. vmuriart commented on Mar 8, 2017

    @vmuriart
    Contributor

    I got this issue fixed, I'll merge in the fix after v2.3.0 release

  17. den-run-ai commented on Mar 8, 2017

    @den-run-ai
    Contributor

    @vmuriart this is great! @JimSEOW was looking for this fix:

    ncgeib/PythonInterface#2 (comment)

  18. vmuriart commented on Mar 8, 2017

    @vmuriart
    Contributor

    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.

  19. added a commit that references this issue on Mar 11, 2017
    7165801
  20. vmuriart commented on Mar 12, 2017

    @vmuriart
    Contributor

    #427 will fix this in case anyone wants to review

  21. added a commit that references this issue on Mar 14, 2017
    4df6105
  22. added a commit that references this issue on Apr 7, 2017
    4b87e2a
  23. added a commit that references this issue on Jun 1, 2017
    1aa6e4c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions