[issue38242] Revert the new asyncio Streams API
Change by Ian Good : -- nosy: +icgood nosy_count: 9.0 -> 10.0 pull_requests: +30142 pull_request: https://github.com/python/cpython/pull/13143 ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45081] dataclasses that inherit from Protocol subclasses have wrong __init__
Ian Good added the comment: Julian, That is certainly a workaround, however the behavior you are describing is inconsistent with PEP-544 in both word and intention. From the PEP: > To explicitly declare that a certain class implements a given protocol, it > can be used as a regular base class. It further describes the semantics of inheriting as "unchanged" from a "regular base class". If the semantics are "unchanged" then it should follow that super().__init__() would pass through the protocol to the object.__init__, just like a "regular base class" would if it does not override __init__. Furthermore, the intention of inheriting a Protocol as described in the PEP: > Static analysis tools are expected to automatically detect that a class > implements a given protocol. So while it's possible to subclass a protocol > explicitly, it's not necessary to do so for the sake of type-checking. The purpose of adding a Protocol sub-class as an explicit base class is thus only to improve static analysis, it should *not* to modify the runtime semantics. Consider the case where a package maintainer wants to enhance the flexibility of their types by transitioning from using an ABC to using structural sub-typing. That simple typing change would be a breaking change to the package consumers, who must now remove a super().__init__() call. Ian -- ___ Python tracker <https://bugs.python.org/issue45081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45081] dataclasses that inherit from Protocol subclasses have wrong __init__
Ian Good added the comment:
I believe this was a deeper issue that affected all classes inheriting
Protocol, causing a TypeError on even the most basic case (see attached):
Traceback (most recent call last):
File "/.../test.py", line 14, in
MyClass()
File "/.../test.py", line 11, in __init__
super().__init__()
File
"/usr/local/Cellar/python@3.9/3.9.7/Frameworks/Python.framework/Versions/3.9/lib/python3.9/typing.py",
line 1083, in _no_init
raise TypeError('Protocols cannot be instantiated')
TypeError: Protocols cannot be instantiated
This was a new regression in 3.9.7 and seems to be resolved by this fix. The
desired behavior should be supported according to PEP 544:
https://www.python.org/dev/peps/pep-0544/#explicitly-declaring-implementation
--
nosy: +icgood
Added file: https://bugs.python.org/file50277/test.py
___
Python tracker
<https://bugs.python.org/issue45081>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34975] start_tls() difficult when using asyncio.start_server()
Ian Good added the comment: #36889 was reverted, so this is not resolved. I'm guessing this needs to be moved to 3.9 now too. Is my original PR worth revisiting? https://github.com/python/cpython/pull/13143/files -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue34975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream
Change by Ian Good : -- nosy: +icgood ___ Python tracker <https://bugs.python.org/issue36889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34975] start_tls() difficult when using asyncio.start_server()
Ian Good added the comment: I added start_tls() to StreamWriter. My implementation returns a new StreamWriter that should be used from then on, but it could be adapted to modify the current writer in-place (let me know). I've added docs, an integration test, and done some additional "real-world" testing with an IMAP server I work on. Specifically, "openssl s_client -connect xxx -starttls imap" works like a charm, and no errors/warnings are logged on disconnect. -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue34975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34975] start_tls() difficult when using asyncio.start_server()
Change by Ian Good : -- keywords: +patch pull_requests: +13056 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34975] start_tls() difficult when using asyncio.start_server()
New submission from Ian Good : There does not seem to be a public API for replacing the transport of the StreamReader / StreamWriter provided to the callback of a call to asyncio.start_server(). The only way I have found to use the new SSL transport is to update protected members of the StreamReaderProtocol object, e.g.: async def callback(reader, writer): loop = asyncio.get_event_loop() transport = writer.transport protocol = transport.get_protocol() new_transport = await loop.start_tls( transport, protocol, ssl_context, server_side=True) protocol._stream_reader = StreamReader(loop=loop) protocol._client_connected_cb = do_stuff_after_start_tls protocol.connection_made(new_transport) async def do_stuff_after_start_tls(ssl_reader, ssl_writer): ... -- components: asyncio messages: 327665 nosy: asvetlov, icgood, yselivanov priority: normal severity: normal status: open title: start_tls() difficult when using asyncio.start_server() versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
