Nothing fancy, however I was manually copying status.py file from Django Rest Framework in every project. So I thought I would release this as a pypi package and it may come useful to others also.
I love that within 8 hours of this being released 3 people found it necessary to submit identical PRs to support HTTP 418 “I am a Teapot”. I wonder if they did the same against Django, or if this is Parkinson’s law of triviality in action… :-)
Make that 4. :-)
hey, may I know the reason? I don’t want to come off as rude, but you probably knew I was going to merge the first one. And I still don’t see why three others also sent same PR.
what I am missing? (:
I have been wondering about this also. Knowing nothing about the people that
made the additional PRs my immediate impression is that they did not make the
PRs to help the project, but to further their own egos. It’s not like the
first PR for that status code were hidden in page 23 of open PRs–but here
we’re talking about PR number 1, 2, 3 and 4. Whether intentional or not, I
definitively see this as antisocial behaviour bordering on bullying.
Why? If it wasn’t clear from the my comment, I was being sarcastic. What positive impact did you feel that piling on a fourth PR to do the exact same thing as the only three open PRs against the project—all created in the last 8 hours—would achieve?
Troll, eh? I guess I deserved that, although trolling wasn’t my intention. This shows how easy it is to unintentionally “pile on” in disembodied forum discussions like this I guess. I did it here, even though asking why someone else did it was the topic of my post! My apologies.
Does this come from django?
It seems really weird to have the numeric value in the name for your constant. It requires you to remember more like saying:
#define 4_four 4
#define 4_four 4
I prefer the names used by golang’s http package.
For reading code, I prefer this, because some of the numeric codes are so well-known that I find it easier if I can tell at a glance which numerical status code is being returned. For writing I agree it has a bit of a disadvantage, but ideally your editor solves that with tab-completion.
I second that. In the case of HTTP, I don’t think I’m alone in knowing the numbers much, much better than I know the names. For most other enumerations, I’d use just the names, since the entire point is to not have to know the numbers…
In code style, we should always be prioritizing maintenance over initial development. It’s by far the larger cost.
Question about HTTP status codes in general: should they be represented as int or as string? It’s prolly inconsequential, though I’ve seen both choices floating around.
That’s curious. What are the benefits of string representation? I have only seen ints.
IIS will pass fractional sub-codes so I suppose it might be too support handling those?
Oh wow, hadn’t encountered that. Yes, strings would be helpful there. Thanks for passing that along.
I’d answer “no”. They should be represented as strongly typed instances, though probably with the option of giving a custom one - possibly enums with the correct ints would be adequate. Look at spray.io (or its spiritual successor http4s) for a library that I think handles status codes really well.
It’s appropriate that an HTTP library would define some response code types for the programmer. Yet it’s interesting to note that both of the libraries listed choose to represent the “raw” response code as int. Again, inconsequential, but curious…
I would use int only. Because range of the number also matters and int are easier to compare. Check these lines. For example, any code between 200 and 299, including those, is considered success.
Equivalently, for a string type, you could check the first character to determine which class the response falls in.