Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mockup of quick expression validator syntax #346

Open
bsamuel-ui opened this issue Feb 14, 2018 · 2 comments
Open

Mockup of quick expression validator syntax #346

bsamuel-ui opened this issue Feb 14, 2018 · 2 comments
Labels
Thinking Needs more braining.

Comments

@bsamuel-ui
Copy link

Here's a quick mockup of the idea.

The idea is to provide a special token VAL that constructs validators using magic methods so you can write:

@attr.s
class Test:
    positive = attr.ib(validator=[VAL.isa(int, float), VAL > 0.0])
    nonempty = attr.ib(validator=[VAL.len() >= 1])

And, of course, it can report the expression in the exception it raises.

Things to support in a real version:

  • __getitem__ to check keys
  • __getattr__ to allow property and method checks
  • the other operators, especially in and such
  • __call__ validates in the mockup, but attr.ib should tell the object to convert itself to a validator

I'd like to see what the community thinks before putting together a proper PR.

@hynek
Copy link
Member

hynek commented Feb 14, 2018

Do you need any changes in attrs for that? If not, it would be probably better to create a external package and see how it fares outside of attrs.

Putting/trying to put it into attrs straightaway would complicate things for you and impede its development.

@bsamuel-ui
Copy link
Author

Making it internal would mean _CountingAttr.__init__ and .validator could call .reify (or whatever) to get the real instance, thus allowing the machinery for expression building to be released.

Supporting VAL.user_method(...) or even VAL(...), means the __call__ method must inspect its arguments to determine if it's still being used to construct an expression or if it's actually validating. The scenario where someone is passing an Attribute as the second of three arguments is unlikely, but it is a validator so bizarre inputs are to be expected. (Other schemes like inspecting the call stack or assuming that the first validation means it's never going to be used to construct expressions are either cpython specific or could lead to heisenbugs.)

Of course, there's no point doing that for an external package as the versions will never match, so it may as well just inspect its arguments.

Putting/trying to put it into attrs straightaway would complicate things for you and impede its development.

Ha ha, very diplomatically put.

@hynek hynek added the Thinking Needs more braining. label Jun 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Thinking Needs more braining.
Projects
None yet
Development

No branches or pull requests

2 participants