[issue27931] Email parse IndexError <""@wiarcom.com>
Константин Волков <konstantin.j.vol...@gmail.com> added the comment: ping -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27931] Email parse IndexError <""@wiarcom.com>
Константин Волков added the comment: ping -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28212] Closing server in asyncio is not efficient
Константин Волков added the comment: Seems that my example wasn`t good. Real reason in it was that closing server is not closing already established connections, and seems that it is not expected to do. Andrew, can you provide your example? I catched some problems but now I think it was because of asyncio internal logic misunderstanding. May be if you provide your example there will be some ideas. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28463] Email long headers parsing/serialization
Константин Волков added the comment: But message ID have its own syntax https://www.ietf.org/rfc/rfc2822.txt: 3.6.4. Identification fields message-id = "Message-ID:" msg-id CRLF msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] 3.2.3. Folding white space and comments However, where CFWS occurs in this standard, it MUST NOT be inserted in such a way that any line of a folded header field is made up entirely of WSP characters and nothing else. Its not obvious, but it seems that there must be no CRLF symbol before MessageID. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28463] Email long headers parsing/serialization
Константин Волков added the comment: Something with inserting long strings here. Its duplicating for some reason. Adding example as attachment. -- Added file: http://bugs.python.org/file45124/test.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28463] Email long headers parsing/serialization
Константин Волков added the comment: Something with copy paste. x = '<147672320775.19544.6718708004153358...@mkren-spb.root.devdomain.local>' -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28463] Email long headers parsing/serialization
New submission from Константин Волков: There is strange thing with long headers serialized, they have \n prefix. Example fails on Python3.4/3.5: from email.message import Message from email import message_from_bytes x = '<147672320775.19544.6718708004153358...@mkren-spb.root.devdomain.local>' header = 'Message-ID' msg = Message() msg[header] = x data = msg.as_bytes() msg2 = message_from_bytes(data) print(x) print(msg2[header]) assert msg2[header] == x MessageID was generated by email.utils.make_msgid function. -- components: email messages: 278820 nosy: barry, r.david.murray, Константин Волков priority: normal severity: normal status: open title: Email long headers parsing/serialization versions: Python 3.4, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28212] Closing server in asyncio is not efficient
Константин Волков added the comment: Seems that its not so hard - in loop.remove_reader add self._ready.append(reader) after reader.cancel() May be its needed to check that its not already there, but I cant imagine how it can be. 2016-09-20 23:16 GMT+03:00 Andrew Svetlov <rep...@bugs.python.org>: > > Andrew Svetlov added the comment: > > It's a known annoying issue. > Honestly I don't know how to fix it properly. > `transport.close()` is affected also because `protocol.connection_lost()` > is called on next loop iteration only. > > Adding a small `asyncio.sleep()` between finishing all worn and loop > closing solves the problem for me but the solution is not obvious for > newbies. > > -- > nosy: +asvetlov > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue28212> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28212] Closing server in asyncio is not efficient
Константин Волков added the comment: Attached file with test example. There in "ping" task "except" and "finally" sections never called as expected (but code inside "try" will work). Server is closed while client connection is active, and it just removes reading task from loop. You can still find it through Task.all_tasks(), but it is weakref array. So, sometime later GC will simply delete this task and no finalization will be performed. -- Added file: http://bugs.python.org/file44756/task_example.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28212] Closing server in asyncio is not efficient
Константин Волков added the comment: Yes? may be a in a hour, 2016-09-20 18:12 GMT+03:00 Guido van Rossum <rep...@bugs.python.org>: > > Guido van Rossum added the comment: > > Can you please supply a complete example? > > --Guido (mobile) > > -- > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue28212> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28212] Closing server in asyncio is not efficient
Константин Волков added the comment: Thats not a thing I talking about. But thanks for "wait_closed", I will be use it in future ) Im talking about reading tasks.When reader removed from selector, there is reading task for it. Loop do "cancel" for it, but it not really cancelling task. Its only marking task for be cancelled on next loop step. It must raise Cancel exception, so task may do corresponding actions inside it (for exemple try..except Cancel). But it will not happen, because there will be no next step - task removed from selector and now is missed from loop. It will freese in "cancelling" state forever if protocol implementation wouldn`t take care about it itself. Some protocol implementations make "_step" for such tasks manually to loop them for correct finishing, someone makes "set_result(None)", but its all looks bad. Seems it will be better put it in loop after removing from selector, so it will go "cancelling way" itself as every task do. 2016-09-20 17:50 GMT+03:00 R. David Murray <rep...@bugs.python.org>: > > R. David Murray added the comment: > > You have to call wait_closed to complete the shutdown. > > This should probably be mentioned directly in the socket server docs (at > least in the examples) (assuming I'm not wrong...but I'm pretty sure I'm > right) rather than by implicit reference to Server via the create_server > comment. > > -- > assignee: -> docs@python > components: +Documentation > nosy: +docs@python, r.david.murray > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue28212> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28213] asyncio SSLProtocol _app_transport is private
New submission from Константин Волков: Seems that this field must not be private(or must have read-only property) as it is supposed to use outside of class. I catched that, when implemented STARTTLS smtp process, when you must start SSL connection over existing socket connection. Currently it is not hard, its easy to add SSL layer as loop do: self._tls_protocol = sslproto.SSLProtocol() socket_transport = self.transport socket_transport._protocol = self._tls_protocol self.transport = self._tls_protocol._app_transport self._tls_protocol.connection_made(socket_transport) But here you must access to private property "app_transport". It must be public because its purpose to public "result" of SSL layer implementation. >From class BaseSelectorEventLoop: def _make_ssl_transport(...): ... return ssl_protocol._app_transport -- components: asyncio messages: 277020 nosy: gvanrossum, yselivanov, Константин Волков priority: normal severity: normal status: open title: asyncio SSLProtocol _app_transport is private versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28212] Closing server in asyncio is not efficient
New submission from Константин Волков: When you close asyncio socket server it closes all connection sockets, remove its readers and do "cancel" for readers. Problem is that, that after this reader tasks are leaved alone in "cancelling" state. They wouldn`t be really cancelled, because they need a loop step for that. But they are not in loop now(they suggest execution throught selector, but they not presented there after removal). Cancelling step woldn`t be done and tasks wouldn`t be really finished, and no finishing actions can be done. I think that It is good idea such tasks to "ready" queue, so they can be executed in normal task way after removing from selector. -- components: asyncio messages: 277019 nosy: gvanrossum, yselivanov, Константин Волков priority: normal severity: normal status: open title: Closing server in asyncio is not efficient versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27931] Email parse IndexError <""@wiarcom.com>
New submission from Константин Волков:
Email lib fails to parse some emails:
from email._header_value_parser import get_angle_addr
get_angle_addr('<""@wiarcom.com> SIZE=28113').addr_spec
IndexError: list index out of range
Seems that email address can be parsed.
--
components: email
messages: 274140
nosy: barry, r.david.murray, Константин Волков
priority: normal
severity: normal
status: open
title: Email parse IndexError <""@wiarcom.com>
versions: Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27931>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
