Repository navigation
Configurable should warn on unrecognized arguments #926
Copy link
Copy link
Open
Description
Currently direct HasTraits subclasses warn when they receive unrecognized arguments:
traitlets/tests/test_traitlets.py
Lines 2802 to 2810 in b0eaa6a
| def test_super_bad_args(): | |
| class SuperHasTraits(HasTraits): | |
| a = Integer() | |
| w = ["Passing unrecognized arguments"] | |
| with expected_warnings(w): | |
| obj = SuperHasTraits(a=1, b=2) | |
| assert obj.a == 1 | |
| assert not hasattr(obj, "b") |
However, this does not work with Configurable and its subclasses, although it is a subclass of HasTraits:
| class Configurable(HasTraits): |
Context
This is implemented in:
traitlets/traitlets/traitlets.py
Lines 1381 to 1399 in b0eaa6a
| try: | |
| super().__init__(*super_args, **super_kwargs) | |
| except TypeError as e: | |
| arg_s_list = [repr(arg) for arg in super_args] | |
| for k, v in super_kwargs.items(): | |
| arg_s_list.append(f"{k}={v!r}") | |
| arg_s = ", ".join(arg_s_list) | |
| warn( | |
| "Passing unrecognized arguments to super({classname}).__init__({arg_s}).\n" | |
| "{error}\n" | |
| "This is deprecated in traitlets 4.2." | |
| "This error will be raised in a future release of traitlets.".format( | |
| arg_s=arg_s, | |
| classname=self.__class__.__name__, | |
| error=e, | |
| ), | |
| DeprecationWarning, | |
| stacklevel=2, | |
| ) |
Related to #145.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels

Activity
minrk commentedon Jun 16, 2025
I think this may be specific to IPython's handling of deprecation warnings, which I believe tries to only show deprecations caused directly by the interactive session, and not transitively.
stacklevel=2in the warning means the warning points toConfigurable.__init__, which IPython doesn't show by default. But running a regular script withPYTHONWARNINGS=ddoes show the warning:minrk commentedon Jun 16, 2025
In fact, I think the correct stacklevel for HasTraits is 3 and for Configurable it should be 4. 2 isn't right like it is for a typical method, though I don't really understand why not.
krassowski commentedon Jun 16, 2025
What should we do about this? The leads to some mistakes when
IPython.embed()is run and users make typos in keyword arguments, so I suppose this is an IPython issue?Besides, should it be a
DeprecationWarning, or aUserWarning? It is both, but I feel like this should never be suppressed.minrk commentedon Jun 16, 2025
This warning is displayed where DeprecationWarnings are enabled when you call e.g.
IPython.embed(a=5).But I think it's fine to switch it to a UserWarning, since it is always a bug in the calling code when this happens.
minrk commentedon Jun 16, 2025
FWIW, this warning was initially a RuntimeWarning in #177 but demoted to DeprecationWarning in #188 because of how often it was triggered and not actionable. But that was 10 years ago, so turning it back to RuntimeWarning or UserWarning now probably makes sense (I still have no clear grasp on what most warning classes are for).