-
-
Notifications
You must be signed in to change notification settings - Fork 374
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
list of validator #158
list of validator #158
Conversation
Codecov Report
@@ Coverage Diff @@
## master #158 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 8 8
Lines 551 563 +12
Branches 122 125 +3
=====================================
+ Hits 551 563 +12
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #158 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 8 8
Lines 551 563 +12
Branches 122 125 +3
=====================================
+ Hits 551 563 +12
Continue to review full report at Codecov.
|
OK so let’s do this. But if we tackle this, I would suggest: |
What about also adding What about mappings? For example: |
yep!
I’d say that exactly what optional() is for. :) So yes, you’ll have to handle that case. That reminds me: unless someone has good arguments, I don’t think we should do
Baby steps. :) |
I see what you did there with the "you'll need to..." ! I appreciate attrs, but I'm not up for implementing this now. You might prefer to close this PR and migrate comments to #39. |
No problem! This is kind of the reason, why we still don’t have it: it’s more work than it looks initially if you want to cover all bases. :-/ |
This feels like a bit of reinventing the type annotation system in Py3. If I understand this correctly, the feature is Why not That is, I think I'd rather write this code: from pathlib import Path
from typing import Iterable
from attr import attrib, attrs
from attr.validators import instance_of
@attrs()
class ThingWithPaths(object):
_paths = attrib(validator=is_type(Iterable[Path]))
def exists(self):
for path in self._paths:
if not path.exists():
return False
return True
thing1 = ThingWithPaths([Path("."), Path("foo")])
print("thing1 exists:", thing1.exists())
thing2 = ThingWithPaths([".", "foo"]) # validation fails here
print("thing2 exists:", thing2.exists()) So what's missing is Another advantage here is that if we have can find the type annotation (eg #151), then is could even be simpler: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #158 (comment)
@wsanchez, >>> isinstance(['qwe', 'asd'], List[int])
True
|
@IlyaSkriblovsky Yeah, I'm figuring that out, which is weak sauce but that's why I changed the code to I'll add here a reference to a ticket to fix that, which you just sent to Glyph: python/typing#377 I guess it's just unfortunate not to be able to leverage typing better. From your work on cattrs, I got the impression that it was possible, but that was optimistic, I guess. |
So my understanding is that So I guess we still need a solution for all the legacy-impaired. Closing this at the request of the reporter tho. |
From the new docs:
"A validator that raises a TypeError if the initializer is called with a non-list type or with a list that contains one or more elements of a wrong type. None values are not permitted. As with instance_of, checks are perfomed using isinstance() therefore it’s also valid to pass a tuple of types."