Skip to content

[Bug]: Args for tripcolor #22303

Closed
Closed

Description

@ThibaultGROUEIX

Bug summary

Thanks for matplotlib!
tripcolor fails if colors are passed with named argument i.e c=values instead of just values. The error is not very informative and it seems a dangerous practice to ignore kwargs and only use args.

  File "/mnt/session_space/conda_envs/latest39/lib/python3.9/site-packages/matplotlib/tri/tripcolor.py", line 57, in tripcolor
    C = np.asarray(args[0])
IndexError: list index out of range

Code for reproduction

plt.tripcolor(vertices[:,0], vertices[:,1], c=values, triangles=triangles)

Actual outcome

  File "/mnt/session_space/conda_envs/latest39/lib/python3.9/site-packages/matplotlib/tri/tripcolor.py", line 57, in tripcolor
    C = np.asarray(args[0])
IndexError: list index out of range

Expected outcome

a successful plot.

Additional information

No response

Operating system

No response

Matplotlib Version

3.5.1

Matplotlib Backend

No response

Python version

No response

Jupyter version

No response

Installation

No response

Activity

  1. QuLogic commented on Jan 25, 2022

    @QuLogic
    Member

    Please provide a complete example. (Also, I don't think c is a valid keyword argument to tripcolor.)

  2. jklymak commented on Jan 28, 2022

    @jklymak
    Member

    I'll close for lack of response, but do request a re-open if there is still an issue here.

  3. anntzer commented on Jan 28, 2022

    @anntzer
    Contributor

    Basically tripcolor(np.random.rand(5), np.random.rand(5), C=np.random.rand(5)) currently fails with the not-so-informative error message above (the correct invocation is tripcolor(np.random.rand(5), np.random.rand(5), np.random.rand(5))). I think we should indeed not allow passing C by keyword, only positionally (see #11526 for essentially the same discussion on quiver); however the error could be made clearer.

  4. added and removed on Jan 28, 2022
  5. timhoffm commented on Jan 28, 2022

    @timhoffm
    Member

    Unfortunately, the API is heavily overloaded. We need an *args parameter that can take many forms, and we cannot get rid of it without major API breakage. Things to do:

    • Clarify which APIs we want to support
    • Improve the documentation
    • Cleanup the parameter parsing. There seem some assumptions to be baked in. Probably we should have an internal parser function triangulation, C, kwargs = parse_params(args, kwargs) that we can unittest the defined API against, and that issues reasonable warnings.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions