web_poet.page_object decorator #44
Conversation
Codecov Report
@@ Coverage Diff @@
## master #44 +/- ##
===========================================
- Coverage 100.00% 96.14% -3.86%
===========================================
Files 14 15 +1
Lines 320 337 +17
===========================================
+ Hits 320 324 +4
- Misses 0 13 +13
|
|
|
||
| @web_poet.page_object | ||
| def MyPage(resp: HttpResponse): | ||
| return {"title": resp.css("title::text").get()} |
There was a problem hiding this comment.
alternative syntax, which doesn't destroy the function:
def parse_foo(resp: HttpResponse):
return {"title": resp.css("title::text").get()}
FooPage = web_poet.page_object(parse_foo)
| """ | ||
| class PageObject(ItemPage): | ||
| def __init__(self, *args, **kwargs): | ||
| # FIXME: save arguments as properly named attributes |
There was a problem hiding this comment.
This is optional, to keep the generated class as close as possible to the hand-written class. See example above - MyPage has self.resp attribute.
| PageObject.__init__.__annotations__ = func.__annotations__ | ||
|
|
||
| # TODO: check that type annotations work properly | ||
| # TODO: preserve the original function as an attribute? |
There was a problem hiding this comment.
Is it to keep the implementation closer to functools.update_wrapper? Maybe we could leave this for a future change.
There was a problem hiding this comment.
I was thinking more about this: if you decorate function, you can't use it anymore, it becomes a class with a completely different API; this is weird. https://github.com/scrapinghub/web-poet/pull/44/files#r882977954 could be another way to address it.
This is an experiment, to see how "functional" Page Objects could look like, if it's possible to implement them, and to get feedback about the idea.