Refactoring and normalized-method #123
Conversation
|
eventually i remodeled the context's aspects that imo names the things in a clearer way. however, i think it may even be useful to make what is now |
funkyfuture
force-pushed
the
refactoring
branch
3 times, most recently
from
790cc91
to
86776a5
Compare
|
@nicolaiarocci can you estimate when you will review this? i'd appreciate any short feedback for my planning. |
note to self: this may be easily tackled with a trail-property of Validator |
|
|
||
| def __call__(self, *args, **kwargs): | ||
| return self.validate(*args, **kwargs) | ||
|
|
||
| # TODO REMOVE? isn't used in the code, | ||
| # seems uninteresting for the public api |
|
Looks good to me - also a much needed refactor and cleanup work. We could merge this so |
|
what about the reanimg of i'd like to change that rather sooner than later as it clarifies a lot. or should i rather change this back and add comments as explanation and reminder? |
|
That's one tough question. Since we're still in beta though, I'd go ahead with the change. Make sure changelog is properly updated. Maybe also add docstrings notes. |
|
i named it but i didn't change it in otherwise i'm fine with merging it. |
- minor fix - Limitations on customizing in the docs
|
i added a commit that reorders the methods and comes with a minor fix and docs extension. can you think of a clearer name for |
funkyfuture
force-pushed
the
refactoring
branch
2 times, most recently
from
b69a0fb
to
0b813da
Compare
also, - fixed test for root_doc in custom validator - adds annotations for missing code - small docs-fix
fixed it. my bad. |
The main purposes of this PR is to prepare the code to implement #93 (and therefore rely completely on child-validators in order to follow object's trails). Furthermore it contains a lot of code-cleanup and -consolidation. some methods have been renamed for the sake of clarification.
this isn't finished yet as i will try to reduce code even more regarding one issue.in a later commit i would reorder the methods to an order as meaningful as possible.
@nicolaiarocci if this is supposed to be included not before the 1.0-release, i would also remove any deprecated parts. as i would also like to apply that to the documentation, an older version of the docs may be made available publicly.
@misja i don't see the point of the
current-method and would like to remove it. any objections?