You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[ENH]: AttributeError('... got an unexpected keyword argument ...') should set the .name attribute to the keyword #27878
I am in the process to write a library that uses the matplotlib library for its graphics needs. As such, most of "our" graphics functions are wrappers around existing matplotlib functions such as tripcolor, tricontour… A typical function of ours would be:
In this case the kwargs dictionnary may contain keywords aimed at the prepare_args process and keywords aimed at controlling the plotting. At the moment, prepare_args removes keywords from the dictionnary when used so that in principle, when kwargs arrive at plt.fun_name, it should only contain keywords known to plt.fun_name
However, if the user makes a mistake while setting the keyword for OUR part, it is not properly handled by prepare_args and it does remain inside kwargs and then is passed to plt.fun_name which then raises an AttributeError('... got an unexpected keyword argument ...').
I would like to be able to try and recover if that happens.
The name and obj attributes can be set using keyword-only arguments to the constructor. When set they represent the name of the attribute that was attempted to be accessed and the object that was accessed for said attribute, respectively.
Changed in version 3.10: Added the name and obj attributes
I looked at the matplotlib codebase but I am not an expert programmer so I may be wrong but I think what I would like was that Artist._update_props set the name attribute to k when raising the AttributeError.
Since I am using Python 3.11 this would allow me to try and remove spurious keywords.
This will break for python 3.9 but, according to the NEP29 schedule, we should be dropping support for that in April anyway. So if we target this for Matplotlib 3.10 there will be no problem.
Activity
rcomer commentedon Mar 7, 2024
This seems reasonable to me. My understanding is the same and it should just be a case of adding
name=khere:matplotlib/lib/matplotlib/artist.py
Lines 1193 to 1194 in 0da2da0
This will break for python 3.9 but, according to the NEP29 schedule, we should be dropping support for that in April anyway. So if we target this for Matplotlib 3.10 there will be no problem.