Message234830
| Author |
last-ent |
| Recipients |
berker.peksag, demian.brecht, last-ent, martin.panter |
| Date |
2015年01月27日.17:47:23 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1422380845.58.0.383273057023.issue23255@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|