EnvironmentError
When I try to install a package or upgrade pip, using pip install I got this error massage. WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate is not yet valid (_ssl.c:1122)'))': /packages/97/f3/c064343ac58d1a54c393a3f66483a29500f644a5918deeb935d28673edd9/virtualenv-20.1.0-py2.py3-none-any.whl WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate is not yet valid (_ssl.c:1122)'))': /packages/97/f3/c064343ac58d1a54c393a3f66483a29500f644a5918deeb935d28673edd9/virtualenv-20.1.0-py2.py3-none-any.whl WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate is not yet valid (_ssl.c:1122)'))': /packages/97/f3/c064343ac58d1a54c393a3f66483a29500f644a5918deeb935d28673edd9/virtualenv-20.1.0-py2.py3-none-any.whl WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate is not yet valid (_ssl.c:1122)'))': /packages/97/f3/c064343ac58d1a54c393a3f66483a29500f644a5918deeb935d28673edd9/virtualenv-20.1.0-py2.py3-none-any.whl WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate is not yet valid (_ssl.c:1122)'))': /packages/97/f3/c064343ac58d1a54c393a3f66483a29500f644a5918deeb935d28673edd9/virtualenv-20.1.0-py2.py3-none-any.whl ERROR: Could not install packages due to an EnvironmentError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Max retries exceeded with url: /packages/97/f3/c064343ac58d1a54c393a3f66483a29500f644a5918deeb935d28673edd9/virtualenv-20.1.0-py2.py3-none-any.whl (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate is not yet valid (_ssl.c:1122)'))) Please help me out -- https://mail.python.org/mailman/listinfo/python-list
Python Client Rest API Invocation - POST with empty body - Invalid character found in method name [{}POST]. HTTP method names must be tokens
I have a Tomcat+Java based server exposing REST APIs. I am writing a client in
python to consume those APIs. Everything is fine until I send empty body in
POST request. It is a valid use case for us. If I send empty body I get 400 bad
request error - Invalid character found in method name [{}POST]. HTTP method
names must be tokens.
If I send empty request from POSTMAN or Java or CURL it works fine, problem is
only when I used python as a client.
Following is python snippet -
json_object={}
header = {'alias': 'A', 'Content-Type' : 'application/json', 'Content-Length' :
'0'}
resp = requests.post(url, auth=(username, password), headers=header,
json=json_object)
I tried using data as well instead of json param to send payload with not much
of success.
I captured the wireshark dumps to understand it further and found that the
request tomcat received is not as per RFC2616
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html). Especially the part -
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
I could see in from wireshark dumps it looked like - {}POST
HTTP/1.1
As we can see the empty body is getting prefixed with http-method, hence tomcat
reports that as an error. I then looked at python http library code - client.py.
Following are relevant details -
File - client.py
Method - _send_output (starting at line # 1001) -
It first sends the header at line #1010 and then the body somewhere down in the
code. My hunch is that (I could be wrong here) perhaps in this case header is
way longer 310 bytes than body 2 bytes, so by the time complete header is sent
on wire body is already pushed and hence TCP frames are order in such a way
that body appears first. To corroborate this I added a delay of 1 second just
after sending header line#1011 and bingo, the error disappeared and it started
working fine. Not sure if this is completely correct analysis, but can someone
in the know can confirm or let me know how to fix this.
Env Details - Client and Server on local machine as of now.
* Client
* Python Version - 3.9, Python Requests module version - 2.25
* Server
* Java 13, Tomcat 9.
P.S. - Please see attached screenshots of wireshark dump with relevant part
highlighted.
Regards,
Bhushan
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dispatch table of methods with various return value types
On 19/11/2020 02:13, Loris Bennett wrote:
dn writes:
Firsty, thanks for taking the time to write such a detailed reply.
Bitte!
I have a method for manipulating the membership of groups such as:
def execute(self, operation, users, group):
"""
Perform the given operation on the users with respect to the
group
"""
action = {
'get': self.get,
'add': self.add,
'delete': self.delete,
}
return action.get(operation)(users, group)
The 'get' action would return, say, a dict of users attribute, whereas
the 'add/delete' actions would return, say, nothing, and all actions
could raise an exception if something goes wrong.
The method which calls 'execute' has to print something to the terminal,
such as the attributes in the case of 'get' and 'OK' in the cases of
'add/delete' (assuming no exception occurred).
Is there a canonical way of dealing with a method which returns different
types of data, or should I just make all actions return the same data
structure so that I can generate a generic response?
Is the problem caused by coding the first step before thinking of the overall
task? Try diagramming or pseudo-coding the complete solution (with multiple
approaches), ie the operations AND the printing and exception-handling.
You could have a point, although I do have a reasonable idea of what the
task is and coming from a Perl background, Python always feels a bit
like pseudocode anyway (which is one of the things I like about Python).
+1 the ease of Python, but can this be seductive?
Per the comment about Perl/Python experience, the operative part is the
"thinking", not the tool - as revealed in responses below...
Sometimes we design one 'solution' to a problem, and forget (or 'brainwash'
ourselves into thinking) that there might be 'another way'.
It may/not apply in this case, but adjusting from a diagram-first methodology,
to the habit of 'jumping straight into code' exhibited by many colleagues,
before readjusting back to (hopefully) a better balance; I felt that
coding-first often caused me to 'paint myself into a corner' with some
'solutions, by being too-close to the code and not 'stepping back' to take a
wider view of the design - but enough about me...
Might it be more appropriate to complete not only the get but also its
reporting, as a unit. Similarly the add and whatever happens after that; and the
delete, likewise.
Currently I am already obtaining the result and doing the reporting in
one method, but that makes it difficult to write tests, since it
violates the idea that one method should, in general, just do one thing.
That separation would seem appropriate here, since testing whether a
data set is correctly retrieved from a database seems to be
significantly different to testing whether the
reporting of an action is correctly laid out and free of typos.
SRP = design thinking! +1
I knew the idea, but I didn't now the TLA for it ;-)
Yes, there are plenty of those!
You may be interested in reading about "Clean Code", instigated (IIRC)
by "Uncle Bob" (Robert Martin). NB Python may/not be used for
book-examples. Just the other day I came across "Clean Code in Python",
Mariano Anaya, PacktPub, 2018. I have yet to read it, but the contents
page seemed to 'tick all the boxes'. The book is two years old, and IIRC
he presented at EuroPython a few years before that (YouTube videos
on-line - in case you prefer that medium, or want to gain a flavor
before spending money...). All of these TLAs, and others comprising the
"SOLID Principles" appear in the ToC, along with plenty of others, eg
YAGNI and EAFP; plus some specific to Python, eg MRO.
TDD = early testing! +1
Agreed: The tasks are definitely separate. The first is data-related. The second
is about presentation.
In keeping with the SRP philosophy, keep the split of execution-flow into the
three (or more) functional-tasks by data-process, but turn each of those tasks
into two steps/routines. (once the reporting routine following "add" has been
coded, and it comes time to implement "delete", it may become possible to repeat
the pattern, and thus 're-use' the second-half...)
Putting it more formally: as the second-half is effectively 'chosen' at the same
time as the first, is the reporting-routine "dependent" upon the data-processor?
function get( self, ... )
self.get_data()
self.present_data()
function add( self, ... )
self.add_data()
self.report_success_fail()
...
Thus, the functional task can be tested independently of any reporting follow-up
(for example in "get"); whilst maintaining/multiplying SRP...
The above approach appeals to me a lot. Slight downsides are that
such 'metafunctions' by necessity non-SRP functions and that, as there
would be no point writing tests for such functions, some
