Skip to content

Compatibility issue between argparse and pythonnet packages #404

Closed

Description

@sg08013

Environment

  • Pythonnet version: 2.3.0.dev1 (built from master on 23/02/2017)
  • Python version: 2.7.13 64bit
  • Operating System: Windows 7 64bit

Details

  • I tested the pythonnet version from yesterday, 23/02/2017, as we are interested in the bug fix for the method overload issue Method overload object type #377. I noticed that we are now running into compatibility issues with the package argparse.

The package argparse now only works correctly, if the parsing of the command line arguments is done BEFORE the import statement of pythonnet (import clr).

If I revert my pythonnet version to pythonnet==2.2.2, then the problem disappears.

The following minimal test code illustrates the problem:

file: test.py
import argparse
# import clr # can't put it here, args.arg1 will be None

parser = argparse.ArgumentParser()
parser.add_argument('--arg1', '-a', help='argument 1', dest='arg1')
args = parser.parse_args()

import clr   
print('Argument 1 = ')
print(args.arg1)

Then I start the script from command line as

python test.py --arg1 "Hello World"

If I run the code with the "import clr" statement after the call to parser.parse_args() then I get the desired output: 
Argument 1 =
hello world

However, if I put the "import clr" at the beginning of the file, I get the output:
Argument 1 =
None

Activity

  1. den-run-ai commented on Feb 24, 2017

    @den-run-ai
    Contributor

    can you try before this pull request?

    #347

  2. den-run-ai commented on Feb 24, 2017

    @den-run-ai
    Contributor

    @filmor can you have a look at this, since this is most likely your pull request.

    @vmuriart looks like you imported clr before setargv tests, hence this case was not tested:

    #301

  3. vmuriart commented on Feb 24, 2017

    @vmuriart
    Contributor

    @sg08013 can you verify that sys.argv is returning as None in the 2nd case.
    @denfromufa yup. Though looking at the issue, it would have been better to test sys.argv is not None and then when it's imported shouldn't matter.

  4. den-run-ai commented on Feb 24, 2017

    @den-run-ai
    Contributor

    no, we need to check that sys.argv is not modified. Checking against None is not enough. Generally is not None is better syntax.

  5. filmor commented on Feb 24, 2017

    @filmor
    Member

    It should suffice to pass the information to Initialize that we are currently running in "module-mode" and skip the setting of argv in that case. I'll prepare a PR.

  6. den-run-ai commented on Feb 24, 2017

    @den-run-ai
    Contributor

    hey, guys, sorry if I sounded rude. i'm actually rude by design :)

  7. sg08013 commented on Feb 24, 2017

    @sg08013
    Author

    I just tested the value of sys.argv with the following code:

    import argparse
    import sys
    print(sys.argv)
    import clr 
    print(sys.argv)
    

    python test.py --arg1 "bla"
    ['test.py', '--arg1', 'bla']
    ['']

  8. vmuriart commented on Feb 24, 2017

    @vmuriart
    Contributor

    I can't think of a good way to write the test for this without breaking how pytest is designed to work. The best i can come up w is to have the test execute an external script via subprocess and report the result from it.

  9. vmuriart commented on Feb 24, 2017

    @vmuriart
    Contributor

    I would also like to point out that this is issue 404 - sys.args not found.

  10. den-run-ai commented on Feb 24, 2017

    @den-run-ai
    Contributor

    @vmuriart you can check if sys has args with hasattr. sys.args does not exist yet after Py_Initialize() in embedded mode.

    @sg08013 thanks for reporting the issue!

  11. added a commit that references this issue on Feb 24, 2017
    bac3ab3
  12. vmuriart commented on Feb 24, 2017

    @vmuriart
    Contributor

    Fixed the test on 012b488 to reflect the behavior being seen. Its marked as xfail for now until we fix it.

    Here's the test running against v2.2.2 showing that it worked.
    https://travis-ci.org/vmuriart/pythonnet/jobs/204904097

    Thanks @sg08013 for reporting and providing the example.

    side note, @sg08013 were you able to test if #377 fixed your other issue?

  13. sg08013 commented on Feb 24, 2017

    @sg08013
    Author

    @vmuriart I can't say yet, whether our issue is entirely resolved. We were having problems using overloaded methods from a C# assembly (in python). There were no crashes or exceptions, just empty return values. This part now runs through (=is resolved), but there is still something that does not work as expected (but this might be unrelated).
    I will let you know when I understand it better.

  14. sg08013 commented on Feb 24, 2017

    @sg08013
    Author

    And thanks to all of you for taking care of this issue so quickly! That's highly appreciated.

  15. added 2 commits that reference this issue on Feb 24, 2017
    4ee5196
    9e1a0e4
  16. added a commit that references this issue on Feb 24, 2017
    faf5faf
  17. added a commit that references this issue on Apr 7, 2017
    7ed31ec
  18. 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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions