[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
Mark Haase added the comment: Defining isoformat() and fromisoformat() as functional inverses is misguided. Indeed, it's not even true: ``` Python 3.7.2 (default, Dec 28 2018, 14:27:11) [Clang 10.0.0 (clang-1000.11.45.5)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import datetime >>> s = '2019-08-07t10:44:00+00:00' >>> assert s == datetime.isoformat(datetime.fromisoformat(s)) Traceback (most recent call last): File "", line 1, in AssertionError ``` I agree with rdb that not parsing "Z" is inconvenient and counter intuitive. We have the same use case: parsing ISO strings created by JavaScript (or created by systems that interoperate with JavaScript). We have also memorized the same `.replace("Z", "+00:00")` hack, but this feels like a missing battery in the stdlib. As Paul points out the legacy of isoformat() complicates the situation. A new pair of functions for RFC-3339 sounds reasonable to me, either rfcformat()/fromrfcformat() or more boldly inetformat()/frominetformat(). The contracts for these functions are simple: fromrfcformat() parses RFC-3339 strings, and rfcformat() produces an RFC-3339 string. The docs for the ISO functions should be updated to point towards the RFC-compliant functions. I'd be willing to work on a PR, but a change of this size probably needs to through python-ideas first? -- nosy: +mehaase ___ Python tracker <https://bugs.python.org/issue35829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30740] SSLError when cancelling an SSL connection
New submission from Mark Haase: If a task is cancelled while it waiting for SSL negotiation, then an SSLError is raised, but there is no way (as far as I can tell) for the caller to catch it. (The example below is pretty contrived, but in an application I'm working on, the user can cancel downloads at any time.) Here's an example: import asyncio, random, ssl async def download(host): ssl_context = ssl.create_default_context() reader, writer = await asyncio.open_connection(host, 443, ssl=ssl_context) request = f'HEAD / HTTP/1.1\r\nHost: {host}\r\n\r\n' writer.write(request.encode('ascii')) lines = list() while True: newdata = await reader.readline() if newdata == b'\r\n': break else: lines.append(newdata.decode('utf8').rstrip('\r\n')) return lines[0] async def main(): while True: task = asyncio.Task(download('www.python.org')) await asyncio.sleep(random.uniform(0.0, 0.5)) task.cancel() try: response = await task print(response) except asyncio.CancelledError: print('request cancelled!') except ssl.SSLError: print('caught SSL error') await asyncio.sleep(1) loop = asyncio.get_event_loop() loop.run_until_complete(main()) loop.close() Running this script yields the following output: HTTP/1.1 200 OK request cancelled! HTTP/1.1 200 OK HTTP/1.1 200 OK : SSL handshake failed Traceback (most recent call last): File "/usr/lib/python3.6/asyncio/base_events.py", line 803, in _create_connection_transport yield from waiter File "/usr/lib/python3.6/asyncio/tasks.py", line 304, in _wakeup future.result() concurrent.futures._base.CancelledError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/asyncio/sslproto.py", line 577, in _on_handshake_complete raise handshake_exc File "/usr/lib/python3.6/asyncio/sslproto.py", line 638, in _process_write_backlog ssldata = self._sslpipe.shutdown(self._finalize) File "/usr/lib/python3.6/asyncio/sslproto.py", line 155, in shutdown ssldata, appdata = self.feed_ssldata(b'') File "/usr/lib/python3.6/asyncio/sslproto.py", line 219, in feed_ssldata self._sslobj.unwrap() File "/usr/lib/python3.6/ssl.py", line 692, in unwrap return self._sslobj.shutdown() ssl.SSLError: [SSL] shutdown while in init (_ssl.c:2299) I posted this on async-sig, and Nathaniel replied: > SSLObject.unwrap has the contract that if it finishes successfully, then the > SSL connection has been cleanly shut down and both sides remain in sync, and > can continue to use the socket in unencrypted mode. When asyncio calls unwrap > before the handshake has completed, then this contract is impossible to > fulfill, and raising an error is the right thing to do. So imo the ssl module > is correct here, and this is a (minor) bug in asyncio. The unwrap() call that throws is already wrapped in `try ... except SSLError` but the exception handler checks for specific SSL error codes and re-throws this particular SSL error. except (ssl.SSLError, ssl.CertificateError) as exc: if getattr(exc, 'errno', None) not in ( ssl.SSL_ERROR_WANT_READ, ssl.SSL_ERROR_WANT_WRITE, ssl.SSL_ERROR_SYSCALL): if self._state == _DO_HANDSHAKE and self._handshake_cb: self._handshake_cb(exc) raise self._need_ssldata = (exc.errno == ssl.SSL_ERROR_WANT_READ) I think this could be fixed checking for SSL_R_SHUTDOWN_WHILE_IN_INIT in this exception handler, but that constant doesn't exist in _ssl.c. As an alternative, maybe a new state _ABORT_HANDSHAKE could be introduced (the existing states are _DO_HANDSHAKE, _WRAPPED, _SHUTDOWN, and _UNWRAP). I'm happy to try my hand at either one of these approaches if somebody can point me in the right direction. -- components: asyncio messages: 296720 nosy: mehaase, yselivanov priority: normal severity: normal status: open title: SSLError when cancelling an SSL connection versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package
Mark Haase added the comment: Oh, sorry! I didn't realize you were a core dev or I would have replied sooner. Thank you for looking into this issue. -- ___ Python tracker <http://bugs.python.org/issue24875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package
Mark Haase added the comment: Vinay, thanks for the patch! I just tested it on my Ubuntu 16.04.1 box with Python 3.5.2 and it works perfectly. Your patch is cleaner than mine, too. Any idea how we get a CPython dev to look at this patch? -- ___ Python tracker <http://bugs.python.org/issue24875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package
Mark Haase added the comment: Hey Thomas and Vinay, thanks for looking into this. Although I discovered this problem on my MacOS laptop 6 months ago, today I also reproduced this issue on my Ubuntu desktop. ``` /home/mhaase/Downloads $ mkdir temp /home/mhaase/Downloads $ cd temp /home/mhaase/Downloads/temp $ pyvenv --system-site-packages pyvenv /home/mhaase/Downloads/temp $ source pyvenv/bin/activate (pyvenv) /home/mhaase/Downloads/temp $ pip --version pip 9.0.1 from /usr/local/lib/python2.7/dist-packages (python 2.7) (pyvenv) /home/mhaase/Downloads/temp $ python --version Python 3.5.2 (pyvenv) /home/mhaase/Downloads/temp $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS" (pyvenv) /home/mhaase/Downloads/temp $ uname -av Linux prodigy 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux ``` This bug is really annoying if you work with scientific Python (numpy, scipy, sklearn), as those are big, stable packages that I would prefer to install once on my system and then access from multiple venvs. The standardization of linux wheels in 2016 made this slightly less problematic (don't need to compile all of numpy just to create a venv for an ipython notebook), but this is still an annoying bug. Unfortunately, I think it lacks the upvotes to get attention from the PyPA developers. Maybe it would help to post this on the https://groups.google.com/forum/#!forum/pypa-dev mailing list? -- ___ Python tracker <http://bugs.python.org/issue24875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package
Mark Haase added the comment: Please ignore my previous message and patch. Although it installs a pip script into the virtual environment, the script's shebang points to the global python and not the venv python. I'm trying to figure out why this is, but the pip voodoo is way deeper than I understand. I can only guess that it has to do with sys.executable which appears to point to the normalized path, i.e. the system python instead of the symlink inside the venv. So I tried dstufft's other suggestion: disable system site packages before bootstrapping pip and then re-enable it afterward. This actually does work in an end-to-end test on my system. So I'm attaching another patch that applies to python 3.5 (1b279c2 on github -- I don't know the equivalent mercurial hash) that is smaller than the previous patch. I don't know what the side effects are of monkeying around with system site packages like this, so apologies in advance if this is a stupid thing to do... -- Added file: http://bugs.python.org/file43883/0002-Fix-issue-24875.patch ___ Python tracker <http://bugs.python.org/issue24875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com