gmpy
gmpy copied to clipboard
aleaxit
pycharm inspection "Unexpected argument" for gmpy2.mpz(...)
I'm unsure exactly what's causing this, but pycharm 2022.3 community edition always seems to complain about passing a parameter to gmpy2.mpz, e.g. gmpy2.mpz(123456789) or gmpy2.mpz("123456789"). And there's no way from the instance of the inspection error to ignore it. So I assume there's something that can be done from the library side (if not a further buried option on the client side I've yet to find). If I had to warrant a guess, it's finding the signature with no parameter passed and assuming you can't pass a positional argument ever.
The code always runs fine but the inspection just complains and clutter's up the screen, and I don't want to disable this specific inspection as it is useful in other situations.
I have however found that it seems like this inspection is built from the documentation, as this is the code it renders for the implementation of gmpy2.mpz reads:
def __init__(self): # real signature unknown; restored from __doc__
pass
Perhaps this can be alleviated by updating the docs to have the documentation be more "parseable"? If it's grabbing it from here:
"""
mpz() -> mpz(0)
If no argument is given, return mpz(0).
mpz(n) -> mpz
Return an 'mpz' object with a numeric value 'n' (truncating n
to its integer part if it's a Fraction, 'mpq', float or 'mpfr').
mpz(s[, base=0]):
Return an 'mpz' object from a string 's' made of digits in the
given base. If base=0, binary, octal, or hex Python strings
are recognized by leading 0b, 0o, or 0x characters, otherwise
the string is assumed to be decimal. Values for base can range
between 2 and 62.
"""
Maybe the second paragraph needs to go first? Just a guess.
This isn't annoying to me enough to where I want to struggle with building and deploying gmpy2 myself, but it seems easy enough for a maintainer to fix.
Documentation was changed a lot in the development version, could you try it?
Unfortunately, #358 is still valid. But you can go to the actions page, get recent successful run of the pip_install_gmpy2 workflow on the master (e.g. this) and download the build artifact. It has html-docs.
Same you can do on any pull request. I think, #383 is related to your issue and I would appreciate your review. Unfortunately, I don't know how pycharm deals with introspection of Python extensions. But if it does it like the Sphinx does - with above PR this issue may be fixed. Here is how docstring look like in docs on that PR:
The documentation changes look like they would fix my issue if my guesses are correct, but I don't think I can fully test this with just the documentation artifacts alone (unless I'm missing something)
The top of the generated gmpy2.py file in pycharm has the header:
# encoding: utf-8
# module gmpy2.gmpy2
# from C:\Python3\lib\site-packages\gmpy2\gmpy2.cp310-win_amd64.pyd
# by generator 1.147
So I think I'd need to replace the .pyd file, and I imagine that would require me just getting the whole gmpy2 development environment up and running on win 11. Which, if it's well documented, I can attempt. But otherwise I will probably shy away from, barring some help by someone knowledgeable.
that would require me just getting the whole gmpy2 development environment up and running on win 11. Which, if it's well documented, I can attempt.
Yes, I think so. We don't provide binary wheels for the development version of the gmpy2. IIUIC, latest release wheels were built as documented in mingw64/msys2_build.txt and/or docs/win_build.rst.
I'm trying to automate this process with CI on the win-wheels. I doubt it's working: it seems the delvewheel fails to "fix" the wheel by copying required DLL's (wheel size is smaller than in the latest release, see recent build) and these wheels are working only in the CI environment. But same build instructions as in the workflow file should work for you.
@casevh, maybe you could do an alpha release with windows wheels? (Since last time I've used M$ Windows 20+ years ago, my progress on the win-wheels branch is slow.) In this way, @brubsby could test if this issue is still valid for the development version.
I just successfully completed a Windows build. I will make a few small updates and do an alpha release.
@casevh, could you please share instructions, that seems to be working for you? So far we have docs/win_build.rst, mingw64/msys2_build.txt and windows_build.txt.
The (mostly) correct instructions are mingw64/msys2_build.txt. docs/win_build.rst should become the nicely formatted version of msys2_build.txt. I will delete windows_build.txt.
I'll add to the Windows build document as time permits this week.
I'll add to the Windows build document as time permits this week.
If you would just update msys2_build.txt - this will be great.
I've updated msys2_build.txt and msys2_64_shared.sh.
gmpy2 supports a C-API for supporting third party extensions. There is at least one Windows extension that uses it. See #320. To support that use, I provide the headers and un-mangled DLLs for GMP, MPFR, and MPC. I want to use a fairly static environment for the official Windows wheels.
@brubsby, now you are able to test pre-release version. Do you still have this issue with pycharm or it should be closed?
The latest sphinx documentation is still not up to date, but now it includes mentioned above changes in the mpz docstring.
Ok, I had a time to run this horrible beast. (All this on 2023.2.2, package was installed from CI wheels to workaround #438.)
@casevh, probably we could close this issue. I don't see any warnings on simple file:
On another hand, it seems the PyCharm doesn't support multiple function signatures (like e.g sphinx does) and the mpz signature looks funny:
But same true for the int() builtin:
So, I think we can't do anything here. For some context: https://discuss.python.org/t/signatures-a-call-to-action/23580