Expose HTTPRedirect default status#1611
Conversation
…ct.default_status class property.
| status = int(status) | ||
| if status < 300 or status > 399: | ||
| raise ValueError('status must be between 300 and 399.') | ||
| status = int(status) if status is not None else self.default_status |
There was a problem hiding this comment.
Why not assign self.status right here?
There was a problem hiding this comment.
Yes, I think that would be preferable.
| raise ValueError('status must be between 300 and 399.') | ||
|
|
||
| self.status = status | ||
| CherryPyException.__init__(self, abs_urls, status) |
There was a problem hiding this comment.
Yes, perhaps, but that's outside the scope of this PR.
| import six | ||
| from six.moves import urllib | ||
|
|
||
| from jaraco.classes.properties import classproperty |
There was a problem hiding this comment.
I'd move it before six preserving alphabetic order
There was a problem hiding this comment.
I've been using a convention of creating four sections for imports: stdlib, compatibility (stdlib functionality but from third-party modules), third-party modules, and finally intrapackage imports. Perhaps my convention diverges slightly from the more common convention of putting all third-party imports (even six) in the same group.
There was a problem hiding this comment.
No, it's okay. It's good that you explained your way of structuring imports. I think makes sense, we should probably document this approach in contribution docs to make everyone follow the same code style.
|
Another dependency.. And also a non standard language concept of class property. |
| CherryPyException.__init__(self, abs_urls, status) | ||
|
|
||
| @classproperty | ||
| def default_status(cls): |
There was a problem hiding this comment.
codacy fail - this is a classmethod, so the convention is cls.
| CherryPyException.__init__(self, abs_urls, status) | ||
|
|
||
| @classproperty | ||
| def default_status(cls): |
There was a problem hiding this comment.
codacy fail - it can't be a static method because it's a class property.
It is a non-standard concept; i.e. it's not in the stdlib. I personally think it should be as it's a fairly basic concept in OO, even if only occasionally used. Yes, the additional dependency makes me a little sad, but not as sad as a copy/paste of the implementation (and subsequent maintenance burden). That is, if we assume a classproperty is desired. I believe a classproperty is desired. It would be trivial to make that @Safihre : Classproperty details aside, what interface do you think is best for the end user who wishes to resolve the default status for a redirect? |
What is so wrong with that? |
It's normally applied to instances, not classes. It's pythonic way to use |
jaraco
force-pushed
the
feature/http-redirect-default-status
branch
from
df9be29 to
c92503e
Compare
Codecov Report
@@ Coverage Diff @@
## master #1611 +/- ##
==========================================
- Coverage 77.56% 77.12% -0.45%
==========================================
Files 106 106
Lines 14374 14372 -2
==========================================
- Hits 11149 11084 -65
- Misses 3225 3288 +63 |
3 participants
While adapting some internal code, I had a situation where I wanted to handle the response directly rather than raising an HTTPRedirect, but I still wanted to use the same response code. After inspecting the logic for how HTTPRedirect calculates the appropriate response code for a redirect, I realized I wanted to re-use this logic rather than copy/paste it.
This change extracts that logic into the
HTTPRedirect.default_statusclass property, such that it can be used by a third party application even if HTTPRedirect itself isn't used.I'm a little sad this change adds a new dependency for the classproperty, but since it's not stdlib, that's the best option.