Re: [Python-ideas] PEP 543-conform TLS library
On Fri, 26 Oct 2018 17:41:26 +0200 Mathias Laurin wrote: > > So, can anybody clarify these two points from the PEP? > > Or should I just address Cory Benfield (who does not seem very > active anymore lately) and Christian Heimes directly? Either that, or post on python-dev where you'll be more likely to be read by the relevant people :-) Regards Antoine. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP 543-conform TLS library
Hello Python ideas, I have implemented an (I believe) PEP 543-conform TLS library and released TLS support in the latest version yesterday: https://github.com/Synss/python-mbedtls/tree/0.13.0 https://pypi.org/project/python-mbedtls/0.13.0/ As far as I know, I am the first one to follow PEP 543. So one point is that the API works. However, I have a couple of questions regarding the PEP: - I do not know what to do in `TLSWrappedBuffer.do_handshake()`. The full TLS handshake requires writing to the server, reading back, etc., (ClientHello, ServerHello, KeyExchange, etc.), which cannot be accomplished in a single buffer. For now, I am doing the handshake in `TLSWrappedSocket.do_handshake()`: I set the BIO to using the socket directly, then perform the handshake on the socket thus entirely bypassing the TLSWrappedBuffer. Once this is done, I swap the BIO to using the buffer and go on encrypting and decrypting from the buffer. That is, the encrypted communication is buffered. - The PEP sometimes mentions an "input buffer" and an "output buffer", and some other times just "the buffer". I believe that both implementations are possible. That is, with two different buffers for input and output, or a single one. I have implemented it with a single circular buffer (that is a stream after all). What the PEP is expecting is nonetheless not clear to me. So, can anybody clarify these two points from the PEP? Or should I just address Cory Benfield (who does not seem very active anymore lately) and Christian Heimes directly? Cheers, Mathias ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] async unittest.TestCase
On Oct 10, 2018, at 1:34 PM, Serhiy Storchaka wrote: > 10.10.18 20:19, Yury Selivanov пише: > > Thanks for proposing this. Yes, it makes sense to have > > unittest.AsyncTestCase in 3.8. AFAIK Lisa Roach (copied) was working > > on that (as well as on async Mock object), but I'm not sure what's the > > status of her work. I suggest to search for an open issue for this on > > bugs.python.org; if there's none, please create one. And let's make > > this happen. > > https://bugs.python.org/issue32972 > https://bugs.python.org/issue26467 I have a working prototype of asynchronous testing in a branch on github [1] but I took a different approach than what was discussed in bpo-32972. Should I open a new bpo or continue the discussion on the existing bpo? I'm leaning in the direction of opening a new bpo so as to not muddy the waters with the discussion around the other branch. Here's a summary of the approach that I took: - create a new class unittest.AsyncioTestCase that implements a few new methods and attributes: - asyncSetUp / asyncTearDown: are awaitable and call the synchronous setUp and tearDown methods. These only exist on the new sub-class. - _runTest: a new method on unittest.TestCase that encapsulates running the test case. This is simply the portion of unittest.TestCase.run() that runs setUp()/testMethod()/tearDown(). - _terminateTest: a new method on unittest.TestCase that is *always* called from within run() immediately *before* calling stopTest() on the result. The AsyncioTestCase specialization of this method is responsible to cleaning up the event loop in the same manner that asyncio.run() does. In particular, it shuts down asynchronous generators. [a] - event_loop: an overridable property on the new sub-class that creates and installs a new event loop. This is referred to from within the AsyncioTestCase specialization of _runTest to create the event loop - event loops are created and destroyed for each test method [b] - the same event loop persists from before setUp until after the cleanups are called - test methods that asyncio.iscoroutinefunction thinks are co-routines are run on the event loop; other test methods are called directly [c] With that said, should I open a new bpo or start discussion on the existing one anew? Cheers, dave. -- [1]: https://github.com/dave-shawley/cpython/pull/1 [2]: https://github.com/python/cpython/pull/9296 [a]: I explicitly chose to not shutdown outstanding tasks in _terminateTest so that the event loop complains loudly about them. This is an area that I would like to discuss further. [b]: I chose to create and destroy an event loop with each test method to avoid having tasks and other event loop settings from leaking between test calls. [c]: This is problematic since mock.patch decorated co-routines won't be called correctly. I'm going to discuss this with @lisroach on her bpo-26467 patch [2]. I have a feeling that the "AwaitableMock" approach may work out and change this code. See the most recent comments on [2] for details. -- People think right angles produce harmony, but they don't. They produce sleep. -- James Krenov ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] name2type mapping
Am 25.10.18 um 22:34 schrieb Steven D'Aprano: On Thu, Oct 25, 2018 at 10:04:05PM +0200, Thomas Güttler Lists wrote: I created a first draft of the name2type mapping which was discussed here some days ago: Since this is not a language feature, please take the discussion to a more appropriate forum such as this: https://mail.python.org/mailman/listinfo/code-quality The discussion was already taken to a an other forum: https://github.com/guettli/python-name2type-mapping I feel where proud and happy since Guido created an issue there. Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
