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.