[issue10850] inconsistent behavior concerning multiprocessing.manager.BaseManager._Server
New submission from chrysn : The multiprocessing.manager.BaseManager class has a class property called _Server, defaulting to multiprocessing.manager.Server, that is used in the ._run_server method (typically invoked via .run()) to determine the class of the server that is to be created. On the other hand, the .get_server() method creates an instance of Server independent of what is configured in ._Server. Thus, managers started via .run() behave slightly different than those started with .get_server().serve_forever(), and in a way that is hard to track. I am aware that the ._Server property is undocumented, but it's quite useful when extending BaseManager in a way that it needs to be configured by the server. I suggest to have .get_server() use ._Server instead of Server; I can't think of situations in which this does the wrong thing (rather, I assume that up to now, users of ._Server didn't try running with .get_server().serve_forever(); it seems ._Server is not used in the standard library). -- components: None messages: 125606 nosy: chrysn priority: normal severity: normal status: open title: inconsistent behavior concerning multiprocessing.manager.BaseManager._Server type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue10850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1649329] gettext.py incompatible with eggs
Changes by chrysn <[EMAIL PROTECTED]>: -- nosy: +chrysn _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1649329> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35569] OSX: Enable IPV6_RECVPKTINFO
chrysn added the comment: Testing the application to current git master (on a borrowed machine with Darwin Kernel Version 18.5.0), the provided patch does enable the desired IPV6_RECVPKTINFO flag, and the received pktinfo struct complies to the spec. -- ___ Python tracker <https://bugs.python.org/issue35569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35569] OSX: Enable IPV6_RECVPKTINFO
New submission from chrysn : Python builds on MacOS do not expose the IPV6_RECVPKTINFO flag specified in [RFC3842], which is required for UDP protocols that need control over their servers' sending ports like [CoAP]. While I don't own Apple hardware and thus can't test it, the [nginx] code indicates that this API is available on OSX and is just gated behind `-D__APPLE_USE_RFC_3542`. Searching the web for that define indicates that other interpreted langues and applications use the flag as well (PHP, Ruby; PowerDNS, nmap, libcoap). Please consider enabling this on future releases of Python on OSX. [RFC3542]: https://tools.ietf.org/html/rfc3542 [CoAP]: https://github.com/chrysn/aiocoap/issues/69 [nginx]: http://hg.nginx.org/nginx/rev/9fb994513776 -- components: IO messages: 332389 nosy: chrysn priority: normal severity: normal status: open title: OSX: Enable IPV6_RECVPKTINFO type: enhancement ___ Python tracker <https://bugs.python.org/issue35569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29886] links between binascii.{un,}hexlify / bytes.{,to}hex
New submission from chrysn:
The function binascii.{un,}hexlify and bytes.{,to}hex do almost the same things
(plus/minus details of whether they accept whitespace, and whether the
hex-encoded data is accepted/returned as strings or bytes).
I think that it would help users to point that out in the documentation, eg. by
adding a "Similar functionality is provided by the ... function." lines at the
ends of the functions' documentations.
--
assignee: docs@python
components: Documentation
messages: 290050
nosy: chrysn, docs@python
priority: normal
severity: normal
status: open
title: links between binascii.{un,}hexlify / bytes.{,to}hex
type: enhancement
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue29886>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19084] No way to use TLS-PSK from python ssl
Changes by chrysn : -- nosy: +chrysn ___ Python tracker <http://bugs.python.org/issue19084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36217] recvmsg support on Windows
New submission from chrysn : Windows has support for advanced socket APIs of RFC 3542 (eg. pktinfo, see https://docs.microsoft.com/en-us/windows/desktop/api/ws2ipdef/ns-ws2ipdef-in6_pktinfo), but those can not be used on Python as there is no recvmsg implementation (tested on 3.7.1 on Windows 10). The recvmsg function is, among other things, required for implementing the CoAP protocol (RFC 7252: introspection of ICMP errors). Windows does have a recvmsg function (as documented at https://msdn.microsoft.com/en-us/a46449f7-3206-45e9-9df0-f272b8cdcc4b), and supports flags to make actual use of it (like RECVPKTINFO above). Given many of the missing flags of RFC 3542 are being added in issue29515, please consider adding a recvmsg method to Windows socket objects. -- components: Windows messages: 337337 nosy: chrysn, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: recvmsg support on Windows type: enhancement ___ Python tracker <https://bugs.python.org/issue36217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15978] asyncore: included batteries don't fit
New submission from chrysn:
the asyncore module would be much more useful if it were well integrated in the
standard library. in particular, it should be supported by:
* subprocess
* BaseHTTPServer / http.server (and thus, socketserver)
* urllib2 / urllib, http.client
* probably many other network libraries except smtpd, which already uses
asyncore
without widespread asyncore support, it is not possible to easily integrate
different servers and services with each other; with asyncore support, it's
just a matter of creating the objects and entering the main loop. (eg, a http
server for controlling a serial device, with a telnet-like debugging interface).
the socketserver even documents that it would like to have such a framework
("Future work: [...] Standard framework for select-based multiplexing"). it
would be rather difficult to port in the generic case (as socketserver based
code in general relies on blocking `read`s or `readline`s), but can be done in
particular cases (i've ported SimpleHTTPServer, but it's a mess of
monkey-patching). for subprocess, there's a bunch of recipies at [1]; pyserial
(not standard library, but might as well become) can be ported quite easily [2].
[1]
http://code.activestate.com/recipes/576957-asynchronous-subprocess-using-asyncore/
[2]
http://sourceforge.net/tracker/?func=detail&aid=3559321&group_id=46487&atid=446305
this issue touches several modules, so for practical implementation, it might
be split up for the different individual fixes to come and track them. some of
them will bring incompatible changes -- it's easy to get SimpleHTTPServer to a
state where it can run unmodified inside asyncore, and emulate its external
interfaces (serve_forever just being a wrapper to asyncore.loop), but hard to
say if it will work with what people built atop of it. how can we find a
roadmap for that?
python already has batteries for nonblocking operation included -- let's just
make sure they fit in the other gadgets!
--
messages: 170782
nosy: chrysn
priority: normal
severity: normal
status: open
title: asyncore: included batteries don't fit
___
Python tracker
<http://bugs.python.org/issue15978>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15978] asyncore: included batteries don't fit
chrysn added the comment: i'm aware this is ambitious, and hope that at least the individual sub-agendas will be manageable. as for vague, i can enhance it (i'd start refining the individual sub-agendas -- or do you think the "big picture" needs more details too?). integration of frameworks is hard, i know. for some libraries, it might not even be feasible, or it could be that it'd be easier to write a new server than integrating into the existing one. (eg it might be easier to refactor http servers into a generic and a blocking part first, and then offer a http.server.AsyncServer in parallel to the existing implementation). that's why i'd like to try to get a rough roadmap instead of hacking ahead :-) nevertheless, the current situation is not satisfying -- we have a versatile http client module, and yet who wants to fetch asynchronously is left with a stub implementation in the asyncore docs. that's not what one would expect from the "batteries included" catchphrase. we don't need all of that implemented *right now*, but maybe we can do better than implementing it never. -- ___ Python tracker <http://bugs.python.org/issue15978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15978] asyncore: included batteries don't fit
chrysn added the comment: i've redirected my request to python-ideas as suggested. for future reference, my email can be found at http://mail.python.org/pipermail/python-ideas/2012-September/016185.html -- ___ Python tracker <http://bugs.python.org/issue15978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m
New submission from chrysn: the attached test.py snipplet, which runs an asyncio main loop to the completion of a coroutine raising SystemExit, runs cleanly when invoked using `python3 test.py`, but shows a logging error from the Task.__del__ method when invoked using `python3 -m test`. the error message (attached as test.err) indicates that the builtins module has already been emptied by the time the Task's destructor is run. i could reproduce the problem with an easier test case without asyncio (destructoretest.py), but then again, there the issue is slightly more obvious (one could argue a "don't do that, then"), and it occurs no matter how the program is run. i'm leaving this initially assigned to asyncio, because (to the best of my knowledge) test.py does not do bad things by itself, and the behavior is inconsistent only there. -- components: asyncio messages: 227440 nosy: chrysn, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: SystemExit out of run_until_complete causes AttributeError when using python3 -m versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue22480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m
Changes by chrysn : Added file: http://bugs.python.org/file36707/test.py ___ Python tracker <http://bugs.python.org/issue22480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m
Changes by chrysn : Added file: http://bugs.python.org/file36708/test.err ___ Python tracker <http://bugs.python.org/issue22480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m
Changes by chrysn : Added file: http://bugs.python.org/file36709/destructortest.py ___ Python tracker <http://bugs.python.org/issue22480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29650] abstractmethod does not work when deriving from Exception
New submission from chrysn: The "TypeError: Can't instantiate abstract class C with abstract methods x" exception does not get raised when when the involved ABCMeta class is derived from an Exception. The attached file shows that a class without an implementation of an abstractmethod can get instanciated; replacing the derivation from Exception with a derivation from another class (say, A) makes the instanciation throw the proper TypeError. -- files: demo.py messages: 288571 nosy: chrysn priority: normal severity: normal status: open title: abstractmethod does not work when deriving from Exception type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46668/demo.py ___ Python tracker <http://bugs.python.org/issue29650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23759] urllib.parse: make coap:// known
New submission from chrysn: The CoAP protocol (RFC 7252) registers the new URI schemes coap and coaps. They adhere to the generic RFC3986 rules, and use netloc and relative URIs. Therefore, please add the 'coap' and 'coaps' schemes to the uses_relative and uses_netloc lists in urllib.parse. I'm not sure about uses_params; the CoAP protocol in itself does not do anything special with the ';' character in URIs, so probably it should not be included there. (But then again, neither does RFC2616 mention ";" in the context of addresses, and it is included in uses_params). -- components: Library (Lib) messages: 239106 nosy: chrysn priority: normal severity: normal status: open title: urllib.parse: make coap:// known type: enhancement ___ Python tracker <http://bugs.python.org/issue23759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23759] urllib.parse: make coap:// known
chrysn added the comment: i wholeheartedly agree that a generic solution would be preferable, but as you pointed out, that needs to be well-researched. until there is a concrete plan for that, please don't let the ideal solution get in the way of a practical update of the uri scheme list. -- ___ Python tracker <http://bugs.python.org/issue23759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28268] bz2.open does not use __fspath__ (PEP 519)
New submission from chrysn: The bz2.open function accepts a file name; after PEP 519 (file system path protocol) it "is expected that most APIs in Python's standard library that currently accept a file system path will be updated appropriately to accept path objects". BZ2File explicitly checks for types (bz2.py:94-97), so it will need explicit adaption. -- messages: 277357 nosy: chrysn priority: normal severity: normal status: open title: bz2.open does not use __fspath__ (PEP 519) type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue28268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
