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
We currently have some exceptions that take multiple parameters and use them to generated a pre-formatted exception:
classBaseZarrError(ValueError):
""" Base error which all zarr errors are sub-classed from. """_msg=""def__init__(self, *args: Any) ->None:
super().__init__(self._msg.format(*args))
classContainsGroupError(BaseZarrError):
"""Raised when a group already exists at a certain path."""_msg="A group exists in store {!r} at path {!r}."ContainsGroupError('a','b')
# ContainsGroupError("A group exists in store 'a' at path 'b'.")
I think this is kind of pointless, because outside of our tests we are not programmatically parsing the string contents of exception messages, and it's also confusing for developers because we don't document these parameters on the exception classes, and normal python exceptions don't (to my knowledge) require multiple arguments that go into a templated string.
Since IMO this pre-formatting is of negative value, I propose deprecating it. To make this smooth, creating an exception with a single argument will treat that as a pre-formatted string (i.e., normal python exception behavior). For exceptions that previously performed special formatting, this will be triggered by creating the exception with multiple arguments.
I don't know how to deprecate this "noisily" -- emitting a deprecation warning when an exception is raised doesn't really reach the right audience, and I don't know how to issue a developer-targeted deprecation warning for a specific form of object construction. Happy to hear other ideas here.
Activity
d-v-b commentedon Apr 23, 2026
this was fixed in #3403