Senthil Kumaran <sent...@uthcode.com> added the comment:
Our discussion stemmed from this point. If you look at the change proposed,
Request class is taking a new parameter by name 'method' and it is initialized
to None:
class Request:
def __init__(self, url, data=None, headers={},
- origin_req_host=None, unverifiable=False):
+ origin_req_host=None, unverifiable=False,
+ method=None):
But that actually defaults to GET method in terms of HTTP request for often
used scenarios where the only required parameter (url) is sent.
This happens in the get_method call:
def get_method(self):
- if self.data is not None:
+ """Return a string indicating the HTTP request method."""
+ if self.method is not None:
+ return self.method
+ elif self.data is not None:
return "POST"
else:
return "GET"
Since, it is understood that the default action of Request(url) is to do a GET,
I proposed that we have Request's method parameter default to GET instead of
None, so the change would look like:
class Request:
def __init__(self, url, data=None, headers={},
- origin_req_host=None, unverifiable=False):
+ origin_req_host=None, unverifiable=False,
+ method="GET"):
And it is more meaningful when someone is looking at the Request signature.
Specifying method=None and implicitly meaning it as "GET" for normal situations
was not intuitive to me. (This is not case when we do not pass an explicit
method arg).
At this point, Ezio's summary of API changes discussed becomes interesting. I
read again and it seems to me that, the assumption is get_method is an
important method which determines what method should be used and method should
be given preference over data.
My point is, get_method is an useful, helper function that is helpful is
sending the correct method to the http.client code which does the actual task.
In the current situation, get_method "determines" based on data parameter
should it send a "GET" or a "POST", but if we start using method=arg then,
get_method should just return what was initialized by the method arg
(defaulting to "GET").
2) The next problem comes when a user has specified both data and method="GET".
This becomes an invalid scenario, but a decision has been to taken as what
should be given preference?
- As the user has sent "data", should the request be considered a POST?
- But user specified it as "GET" (intentionally or by mistake), so should the
data not be used and Request should do only a GET?
- Or should we throw an error?
My personal on this is -1 on throwing an error and when data is sent, just do
the POST (data overrides method).
BTW, this needs to discussed irrespective of point 1). But having method="GET"
could give raise to his scenario more often. A person would just send data and
forget about changing the method to "POST".
Coming to specific questions which Ezio pointed:
My take:
1) should method always have priority or should 'POST' always be used whenever
data is passed?
If data is passed use POST.
2) if the method is e.g. 'GET' and data is passed, should an error be raised?
Nope, give data the priority and do POST. (As urllib is currently doing)
3) should Request.method be private?
Not necessarily, it should be public.
4) should the value of Request.method be initialized in the __init__ or can it
also be None?
My take - It should be initialized to default (GET), instead of None.
5) if the value of Request.method is always initialized, should we deprecate
get_method?
This is an interesting question. get_method essentially becomes less useful or
it could serve as an arbiter when data and GET is sent and may be used as
reliable way to get the Request's method. It should not be deprecated.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
