Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

numpy.ma.zeros/ones/empty don't work correctly with keyword arguments #4582

Closed
gerritholl opened this issue Apr 4, 2014 · 8 comments
Closed

Comments

@gerritholl
Copy link
Contributor

The zeros/ones/empty constructors for 'numpy.ma' don't like to be called with keyword arguments shape, dtype:

In [1]: numpy.ma.zeros(2, "f8")
Out[1]: 
masked_array(data = [ 0.  0.],
             mask = False,
       fill_value = 1e+20)

In [2]: numpy.ma.zeros(shape=2, dtype="f8")
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-1a1b42c40a81> in <module>()
----> 1 numpy.ma.zeros(shape=2, dtype="f8")

TypeError: __call__() missing 1 required positional argument: 'a'
@abalkin
Copy link
Contributor

abalkin commented Apr 4, 2014

gh-4584 is a "proof of concept" patch. An alternative approach would be to compile ma functions from a template like one used for namedtuple.

Some optimizations are possible to avoid re-processing function signatures on every call.

@abalkin
Copy link
Contributor

abalkin commented Apr 4, 2014

Also, this does not work for functions that are implemented in C. TODO: Obtain function signature by parsing docstring.

@abalkin
Copy link
Contributor

abalkin commented Apr 4, 2014

This also brings up a question of numpy's plans with respect to PEP 436.

@charris
Copy link
Member

charris commented Apr 4, 2014

Re: PEP 436, hard to say. Looking through the proposal, much would depend on the completeness of the conversion functions and the flexibility of the documentation format. I'm particularly concerned about the latter as, IMHO, we currently have a pretty good documentation format and the proposal, while vague on that point, doesn't fill me with confidence.

@abalkin
Copy link
Contributor

abalkin commented Apr 5, 2014

@charris - PEP 436 is not just a proposal. The framework is already in Python 3.4 and the work started to convert all Python builtins.

Personally, I hate that approach. Writing Python extensions used to be a breeze but PEP 436 reminds me of SWIG.

On the other hand, the markup is very flexible because it supports including arbitrary python code to generate C, so in some distant future it can be used in .src files to generate ufuncs.

I thought I've seen a tool that parses numpy docstrings and generates python signatures, but I cannot find it in the source tree. Does it exist or was I day-dreaming?

@charris
Copy link
Member

charris commented Apr 5, 2014

@abalkin Do you mean numpy/add_newdocs.py? It adds docstrings to C extension functions. I don't think we have any parsers at the moment.

@abalkin
Copy link
Contributor

abalkin commented Apr 5, 2014

I was not day-dreaming: I was using PyCharm. Here is what I see when I ⌘-b to the source of np.zeros:

def zeros(shape, dtype=None, order='C'): # real signature unknown; restored from __doc__
    """
    zeros(shape, dtype=float, order='C')

        Return a new array of given shape and type, filled with zeros.

If they can do that, we should be able as well.

@jjhelmus
Copy link
Contributor

The original issue concerning calling ma.zeros, etc with only keyword arguments and no positional arguments was fixed in PR #6355.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants