This also allows for easy implementation of array inputs to binary_repr and base_repr, for example:

In [1]: np.array2string(np.arange(5), formatter=np.binary_repr)
Out[1]: '[0 1 10 11 100]'

With current master "np.binary_repr(np.arange(5))" just gives a very uninformative error.

Two things:

1. It would be nice to add this capability to set_printoptions, so that it can be used inside of a context.
2. Would it make sense to have formatter be a dictionary mapping data-types or 'kinds' to formatters so that the array2string would handle multiple data-types differently.

Re: 2) I think the formatter itself could handle the conversion of the different types using a dictionary if the user desired such.

Added formatter func to set_printoptions in rgommers@8a1b057 (warning: I rebased the branch)

Re: 2), this is not very convenient to do with a dict in the formatter itself, because you would have to define formatters for all types even if you care about only one of them, and do type checks. On the other hand, I'm not sure what the best interface is. We could allow both a callable and a dict. In case of a dict, the user could pass in a dict with only the formatters he's interested in. Does that make sense?

I'm not sure the dict thing will be used a lot, but while I'm at it why not get it right...

Hi Ralph,

I've been thinking it would be nice if custom formatters could be set to only handle certain types. I'm not sure of the best way to handle that, however. A dictionary would be one method, another would be to let the function return None instead of a string, in which case array2print would use it's default formatting. Thoughts?

Functions returning None doesn't work well, because the user would have to duplicate the dtype checks in _array2string. This is a pain to get right and should be avoided. This interface is the most flexible I can think of (although it may be slightly confusing):

formatter : callable or dict of callables, optional
    If not None and a callable, ``formatter(x)`` is called for each array
    element x to obtain its string representation.
    If a dict of callables, the keys should be in ``{'bool', 'int_kind',
    'int', 'timeint', 'float_kind', 'float', 'longfloat', 'complex_kind',
    'complexfloat', 'longcomplexfloat', 'str'}``.  The keys 'int_kind',
    'float_kind' and 'complex_kind' handle all types of their kind, while
    other keys are more specific.  The callables again should return a
    string.  Types that are not specified (by their corresponding keys) are
    handled by the default formatters.  The precision argument is ignored.

Another small issue is this:

    try:
        format_function = a._format
    except AttributeError:

Does anyone know where this comes from? I can't find anything that has a _format attribute.

How about only using a dictionary and adding the key 'all'? That would simplify the interface a bit and I suspect avoid testing for a callable. If you go that way, it probably isn't worth checking if the callables work correctly. But I suspect folks using this option will be sophisticated enough to figure out what is going on.

That would work better I think. I'll implement this.

Also, I want to deprecate the _format thing with the request that if it's used to email the list. Because I suspect it's not used at all, and it looks very ugly.

The ._format method approach has been there since Numeric days, but like Ralph, I have never seen it used. I am +1 on deprecating it.

I see that you are already thinking about implementing the dictionary of separate formatting functions. This would be nice. I like Chuck's suggestion of always a dictionary interface as well.

Dictionary formatter implemented: rgommers/numpy@master...ticket-1218-array2string

There is a minor increase in overhead because all formatter classes need to be initialized. My unscientific measure of impact (running time of test suite) says this is not more that ~5%. I don't think this is a big issue.

That should address all your comments Charles.

Hello, Actually, I'm new here. I want to know how to contribute to numpy. Where is the mailing list ? And is this the main numpy repository ?

Hi, this is the main repo. Mailing lists at http://scipy.org/Mailing_Lists

Thanks. I'll join the mailing list. I'm a student of Indian Institute of
Technology, Delhi, India, and love to code.
Could you give me some advice that would help me start up contributing to
numpy ?

On Sun, Apr 24, 2011 at 10:20 PM, rgommers <
reply@reply.github.com>wrote:

Hi, this is the main repo. Mailing lists at http://scipy.org/Mailing_Lists

Reply to this email directly or view it on GitHub:
#72 (comment)

Sure, and welcome. Have a look at http://docs.scipy.org/doc/dev/ which explains the development process. It's pretty much the same for Numpy and Scipy. Depending on your interest you can start by trying to fix some bugs or implement open wishes, or contribute to the docs. Bug tracker is here: http://projects.scipy.org/numpy/ For new functionality it's always good to discuss on the mailing list first.

Do keep in mind that Numpy is quite mature, so changes have to be backwards compatible. Scipy is a bit less mature and covers a more broad spectrum of functionality, so if you see something there that particularly interests you then that could also be a good option.

I squashed the commits into a single one and pushed it in d8de71d

Thanks.