-
Notifications
You must be signed in to change notification settings - Fork 82
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
Makes article properties over writable by parser #330
Conversation
def __init__(self, func: Callable[[object], Any], priority: Optional[int], validate: bool): | ||
self.validate = validate | ||
def __init__(self, func: Callable[[object], Any], priority: Optional[int], validate: bool, overwrite: bool = False): | ||
self.validate = validate if not overwrite else False |
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.
Just writing the true path first for clarity.
self.validate = validate if not overwrite else False | |
self.validate = False if overwrite else validate |
@@ -137,7 +145,7 @@ def validated(self) -> "AttributeCollection": | |||
|
|||
@property | |||
def unvalidated(self) -> "AttributeCollection": | |||
return AttributeCollection(*[attr for attr in self.functions if not attr.validate]) | |||
return AttributeCollection(*[attr for attr in self.functions if not attr.validate and not attr.overwrite]) |
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.
Doesn't the following line modify the validated attribute already, s.t. it correctly identifies (un)validated attributes?
fundus/src/fundus/parser/base_parser.py
Line 80 in 1e506e1
self.validate = validate if not overwrite else False |
return AttributeCollection(*[attr for attr in self.functions if not attr.validate and not attr.overwrite]) | |
return AttributeCollection(*[attr for attr in self.functions if not attr.validate]) |
import functools | ||
|
||
|
||
class _CachedAttribute(object): |
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.
In general, I was a bit confused with the features added in this PR. Firstly, the overwrite_attribute
decorator and, secondly, the property caching. I'll spare you with my previous comments of confusion, but at first I thought that these are separate features and the custom cached attribute is only motivated to improve the general perfomance. Nertheless, here is how I understand it now:
The original problem outlined in #328 is caused by the use of the @property
decorator on lang
that we want to overwrite in the parsers. Here, we cannot continue using the standard properties since the defined properties define no setter, thus preventing the properties to be overwritten in subclasses with methods with the @attribute
decorator. Did I understand this correctly? The origin of the error or at least an error traceback would have been helpful to include in the issue or the PR description.
def __init__(self, func: Callable[[object], Any], priority: Optional[int], validate: bool, overwrite: bool = False): | ||
self.validate = validate if not overwrite else False | ||
self.overwrite = overwrite |
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.
Could you clarify why an overwritten attribute can not be a validated attribute? If we allow overwritten attributes to be validated, they are the same as the regular attributes.
import functools | ||
|
||
|
||
class _CachedAttribute(object): |
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.
I'm a bit unsure if this entire attribute caching via a custom property is necessary. Some alternatives come to my mind:
- We could define a setter for the relevant properties. But this would be bad since we don't want
lang
etc. to be mutable openly. - From a design perspective, why are the
lang
andplaintext
computed in the article and not in the parser? So maybe we can move both of these properties from theArticle
to theBaseParser
as attributes. Then we need to includelang
andplaintext
as fields in theArticle
dataclass, s.t. they are populated delayed as the other attributes. This way it would also be explicit that these are attributes one may overwrite from theBaseParser
andArticle
would define the skeleton of attributes as dataclass fields. - What would be wrong with the regular
cached_attribute
? I tried to replace it with the custom one and it seemed to work fine, even when overwriting it in a parser.
No longer relevant after the latest rework #559 |
This PR adds functionality to write over properties like
lang
defined in thearticle
class. We do so by replacing the formerproperty
logic with a custom one. The new implementation now caches the values as well so it now works likecached_property
but instead ofcached_property
it can be overwritten.I.e. to overwrite the
lang
attribute ofArticle
use the following in your desired parser.closes #328