Message234830
Latest patch with simpler(?) logic?
@Demian: This is a tough task! And I appreciate your kind words.
I have gone through your comments and I have made a few changes as per your suggestion but I have refrained from a few as well.
> get_status_type, apply_success_headers, apply_headers
The reason I wrote these three methods is that when a new dev wants to try out the library, he shouldn't have to handcode all the boilerplate. It makes no sense to to re-write this part of code for each new implementation. It can always be overwritten when required and it follows existing functionality.
But I understand your idea of what should be part of Public API and I have changed the access levels of most of such methods to class methods.
I have updated `get_status_type` to be of O(1) (hopefully) and removed HTTPStatusType.
I think since it is quite easy to overwrite `apply_headers` & `_get_status_type`, the default implementation can be straight up used by anyone with no modification and still yield satisfactory behaviour.
As for Doc, I really have no idea how to make it better. Maybe someone else can submit a patch later on? Or if you are fine, I will include your own Doc.
Thanks again. |
|
Date |
User |
Action |
Args |
2015-01-27 17:47:26 | last-ent | set | recipients:
+ last-ent, berker.peksag, martin.panter, demian.brecht |
2015-01-27 17:47:25 | last-ent | set | messageid: <1422380845.58.0.383273057023.issue23255@psf.upfronthosting.co.za> |
2015-01-27 17:47:25 | last-ent | link | issue23255 messages |
2015-01-27 17:47:25 | last-ent | create | |
|