Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Allow three-argument converters (like validators/on_setattr) #709
Comments
|
Maybe, converters and validators can (or event should) be merged (similarly to click callbacks)? def int_validator(self, attrib, value):
return int(value) # Validates and converts at the same time :-)I guess that would be very backwards incompatible, but maybe this can (still) be added to the new |
This is something I've been thinking about in the past days. I think a marker-wrapper for three-argument converters would be most solid and in line with our other APIs? |
|
There's also #146 which still bothers me that it's unresolved but to which I still don't have a good answer, 3.5 years later. :( |
|
Thank you for the discussion! @sscherfke I think this is kind of thing that happened to Personally I like separate validators, as they are running after all the conversions (hence - guaranteed to work with fully-initialized self!) and imply that the field value doesn't change (unless some reckless guy will do @hynek #146 is pretty informative, thank you for mentioning it! :) I actually missed the stacktrace point when I was thinking about it (and maybe some performance issues, as there is a level of indirection here...). Though, I think that having I do like the marker-wrapper idea (e.g. UPD: Just saw the comment in the PR. Actually, if |
I'd like to move the discussion from converter decorator PR to this issue.
I think converters are semantically closer to
on_setattrandvalidatorthandefault. E.g.attr.ib(converter=...)allows you to pass a list of callables and pipes them automatically - exactly likeattr.ib(validator=...)andattr.ib(on_setattr=...)and there isattr.convertersmodule, likeattr.settersandattr.validators.If we allow passing half-initialized self to converter, why don't allow full-form converters,
converter(self, attr, value)to make them the same ason_setattr, but for initialization?To support one, two and three-argument converters there should be either inspect-magic (in py2 - getargspec, in py3 - signature) or mandatory
Converterwrapper for two and three-argument converters.