Expose HTTPRedirect default status

[jaraco]

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_status class 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.

[webknjaz]

Why not assign self.status right here?

[jaraco]

Yes, I think that would be preferable.

[webknjaz]

Can we use super()?

[jaraco]

Yes, perhaps, but that's outside the scope of this PR.

[webknjaz]

I'd move it before six preserving alphabetic order

[jaraco]

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.

[webknjaz]

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.

[Safihre]

Another dependency.. And also a non standard language concept of class property.
Is there really no better and more general solution?

[jaraco]

codacy fail - this is a classmethod, so the convention is cls.

[jaraco]

codacy fail - it can't be a static method because it's a class property.

[jaraco]

Another dependency.. And also a non standard language concept of class property.
Is there really no better and more general solution?

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 default_status a static method, such that the usage is HTTPRedirect.default_status() or HTTPRedirect.get_default_status(), but that feels a little too verbose to me. Of course, such a method would have the advantage of communicating to the user that the value is calculated (and might change based on context).

@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?

[Safihre]

It would be trivial to make that default_status a static method, such that the usage is HTTPRedirect.default_status() or HTTPRedirect.get_default_status(), but that feels a little too verbose to me. Of course, such a method would have the advantage of communicating to the user that the value is calculated (and might change based on context).

What is so wrong with that?
get_default_status() seems pretty reasonable and understandable if an external third party application wants to get this info: it's a getter/setter-style.

[webknjaz]

it's a getter/setter-style

It's normally applied to instances, not classes. It's pythonic way to use @property decorator, but it's not applicable to properties at the class level. I support @jaraco's intention to bring a bit more elegance into the codebase.

[codacy-bot]

Issue found: Method could be a function

[codacy-bot]

Issue found: Method should have "self" as first argument

[codacy-bot]

Here is an overview of what got changed by this pull request:

Issues
======
- Added 2
           

See the complete overview on Codacy

[codecov]

Codecov Report

Merging #1611 into master will decrease coverage by 0.44%.
The diff coverage is 83.33%.

@@            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