Filip Malczak added the comment:
If we're getting out of original scope, then I wonder... Maybe we should keep
only standard status codes here? If not, which should we support, and which
not? What about custom Spring 420 Method Failure?
One way to clean up mess here is to create some dictionaries called Http09,
Http10, Http11, but also Nginx, Spring, InternetDraft, etc - they would hold
codes specific to some standard or extension (and they should be incremental,
so Http11 would hold only those codes that came with HTTP 1.1, not any of HTTP
1.0 codes).
Also, we should provide function responses_mapping which should take
dictionaries with code mappings, so one may use it like
responses_mapping(Http09, Http10, Http11, Spring). Module attribute responses
should be initialized to responses_mapping(Http09, Http10, Http11), so it would
contain standard codes only.
responses_mapping (we should probably consider different name) should take any
number of dicts, merge them and return merging result. Additionally, I think it
should overwrite merged values, so if we call it with two dicts, which hold the
same key - value from last dict with this key should be used. Essentially, it
is just:
def responses_mapping(*dicts):
out = {}
for d in dicts:
out.update(d)
return out
Now, we would have clean responses dictionary (mentioned in first comment, one
that started this issue), and possibility to extend responses set with
different protocol and extension versions.
There may be one problem - many apps and libs (possibly standard python library
too) may use keys from out of HTTP standard, so this change could break
backwards compability.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20898>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
