[issue33166] os.cpu_count() returns wrong number of processors on specific systems
Giampaolo Rodola' <g.rod...@gmail.com> added the comment: Oh! So both os.cpu_count() and psutil.cpu_count() are wrong? How do you determine the actual number of logical/physical CPUs on your machine? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33166] os.cpu_count() returns wrong number of processors on specific systems
Giampaolo Rodola' <g.rod...@gmail.com> added the comment: The difference between os.cpu_count() and psutil.cpu_count() is because one uses GetMaximumProcessorCount() and the other dwNumberOfProcessors. This is tracked as a bug in psutil bug tracker but it's not fixed yet: https://github.com/giampaolo/psutil/issues/771 As for Python this is where it was discussed and changed: https://bugs.python.org/issue30581 https://github.com/python/cpython/commit/c67bae04780f9d7590f9f91b4ee5f31c5d75b3c3 In summary: psutil is wrong and you should rely on os.cpu_count(). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33122] ftplib: FTP_TLS seems to have problems with sites that close the encrypted channel themselfes
Giampaolo Rodola' <g.rod...@gmail.com> added the comment: Please paste your code and traceback message. Also what's the remote FTP server you're connected to? You should be able to see it in the welcome message (you can set FTP_TLS.debugging to True). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32572] Add the ftplib option, overrides the IP address.
Giampaolo Rodola' <g.rod...@gmail.com> added the comment: Considering the security implications and the fact that it's a corner case I don't think this is worth adding as a new, public API, sorry. I think ftplib should expose and promote APIs reflecting common scenarios and good practices, yet be flexible enough in order to allow "breaking the rules". FWIW, you may get away with something like this, which IMO is not too bad (not tested): class FTP(ftplib.FTP): externalip = None def sendport(self, host, port): return super().sendport(self.externalip or host, port) def sendeprt(self, host, port): return super().sendeprt(self.externalip or host, port) -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32572> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32572] Add the ftplib option, overrides the IP address.
Giampaolo Rodola' <g.rod...@gmail.com> added the comment: Mmmm out of curiosity, how common is this? Usually when client is behind a NAT it's supposed to use PASV. What you're proposing is a configuration option which typically belong to servers, not clients. I don't remember ever bumping into a FTP client allowing such an option (e.g. does FileZilla have it?). Also, this has some security implications as you could potentially dictate a naive FTP server to connect to a malicious host:port, and basically this is the reasons why servers do such a "IP replacement", not clients. In pyftpdlib (which is a server) I explicitly reject PORT connections with an IP != client's IP (because it's a security concern), even though the check can be disabled: https://github.com/giampaolo/pyftpdlib/blob/9dcbf685e10906fbdf4969cda1138a25f96bf16d/pyftpdlib/handlers.py#L383-L396 I believe proftpd and vsftpd does the same by default. -- assignee: -> giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32572> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32410] Implement loop.sock_sendfile method
Change by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30579] Allow traceback objects to be instantiated/mutated/annotated
Change by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: -giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30579> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31970] asyncio debug mode is very slow
Giampaolo Rodola' <g.rod...@gmail.com> added the comment: Sorry. It looks like I completely misunderstood. =) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31970] asyncio debug mode is very slow
Giampaolo Rodola' <g.rod...@gmail.com> added the comment: >> I've a few ideas how to add 0-copy support to protocols. > I'd be interesting to hear about them. The main challenge IMHO is to find a > way to allow a readinto()-like functionality. Exposing sendfile() should be straightforward. I started implementing it years ago but I gave up pretty soon because asyncio had no solid test framework for testing an actual data transfer between two sockets and that basically represented a blocker. Basically back then all recv() / send() related tests were mocks. Not sure about the current situation but if that has changed I would be happy to contribute a PR (I was the one who contributed socket.sendfile()). As for a readinto()-like functionality: the only thing I'm aware of is splice() syscall but it's Linux only. It must be noted that also sendfile() is UNIX only. Windows achieve the same via TransmitFile. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31610] Use select.poll instead of select.select in SocketServer.BaseServer.serve_forever
Giampaolo Rodola' <g.rod...@gmail.com> added the comment: I recommend to use selectors.PollSelector and fallback on selectors.SelectSelector where not available (Windows) in order to use 1 syscall only. That's what we did already in socket.py, subprocess.py and others. -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26692] cgroups support in multiprocessing
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors
Giampaolo Rodola' added the comment: I agree that the MS Docs for this are a bit confusing. I ended up reaching out to the guy who authored the GetMaximumProcessorCount function. I had also written an implementation that iterated over GetProcessorInformationEx and he advised against it. One of the things that makes this interesting is that in 32 bit processes (wow64) your processor is simulated to fit in the confines of that old system. This method will only report 32 cores under 32 bit as that is all the program can access in 32 bit mode. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors
Giampaolo Rodola' added the comment: About GetMaximumProcessorCount, MS doc states that it returns the "maximum number of logical processors that a processor group or the system can have", so maybe it also includes "empty" CPU sockets. GetActiveProcessorCount, on the other hand, returns "the number of active processors in a processor group or in the system", which adds even more confusion. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors
Giampaolo Rodola' added the comment: MS documentation is not clear on what function should be used as there are many returning different values. Here it is being suggested to use GetLogicalProcessorInformationEx: https://stackoverflow.com/questions/31209256/reliable-way-to-programmatically-get-the-number-of-cores-on-windows -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30931] Race condition in asyncore may access the wrong dispatcher
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- assignee: -> giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30931] Race condition in asyncore may access the wrong dispatcher
Giampaolo Rodola' added the comment: +1, I would push https://github.com/python/cpython/pull/2854/ first and fix the race condition only. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29214] Standard open() does not allow to specify file permissions.
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29214> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29256] Windows select() errors out when given no fds to select on, which breaks SelectSelector
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters
Giampaolo Rodola' added the comment: AFAIK its only use case is to escape \r and \n. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters
Giampaolo Rodola' added the comment: > What about rejecting also NUL byte? I don't it would make any difference at this point. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30985] Set closing variable in asyncore at close
Giampaolo Rodola' added the comment: I would probably feel safer to use "__closed" for all python versions and adopt the same naming convention for any attribute we may want to add in the future. Kinda weird, but asyncore is probably the only case of deprecated module with bad API design which makes it risky to make any change to the class namespace. As such I consider using the ugly "__" prefix justifiable. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30985> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30985] Set closing variable in asyncore at close
Giampaolo Rodola' added the comment: On the other hand, due to the poor asyncore API, I think it's safer if we land this in 3.7 only. "closing" attribute was never documented so if there's code out there setting it to True that'll crash their app pretty quickly as sockets won't close. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30985> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30985] Set closing variable in asyncore at close
Giampaolo Rodola' added the comment: I welcome this change as it avoids tricks like this one: https://github.com/giampaolo/pyftpdlib/blob/1268bb185cd63c657d78bc33309041628e62360a/pyftpdlib/handlers.py#L537 Any app using asyncore for anything other than an echo server eventually ends up doing the same. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30985> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30931] Race condition in asyncore may access the wrong dispatcher
Giampaolo Rodola' added the comment: > Yes, this is a typical issue in asyncore if you don't protect your > subclass to handle double close. I use the same trick all over the place in pyftpdlib: https://github.com/giampaolo/pyftpdlib/blob/1268bb185cd63c657d78bc33309041628e62360a/pyftpdlib/handlers.py#L537 In practical terms, does this bug report aim to fix this issue? -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters
Giampaolo Rodola' added the comment: Reopening as it needs backports for 2.7, 3.3, 3.4, 3.5 and 3.6. -- resolution: duplicate -> stage: resolved -> backport needed status: closed -> pending versions: +Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Giampaolo Rodola' added the comment: Sorry, I accidentally picked up the wrong thread. -- resolution: -> fixed stage: backport needed -> resolved status: pending -> closed versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Giampaolo Rodola' added the comment: Reopening as it needs backports for 2.7, 3.3, 3.4, 3.5 and 3.6. -- resolution: fixed -> stage: resolved -> backport needed status: closed -> pending versions: +Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters
Giampaolo Rodola' added the comment: New changeset 2b1e6e9696cb433c0e0da11145157d54275d119f by Giampaolo Rodola (Dong-hee Na) in branch 'master': bpo-30119: fix ftplib.FTP.putline() to throw an error for a illegal command (#1214) https://github.com/python/cpython/commit/2b1e6e9696cb433c0e0da11145157d54275d119f -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Giampaolo Rodola' added the comment: > While "40x faster" is more 10x faster than "4x faster", C > implementation can boost only CPython and makes maintenance more harder. As a counter argument against "let's not do it because it'll be harder to maintain" I'd like to point out that namedtuple API is already kind of over engineered (see: "verbose", "rename", "module" and "_source") and as such it seems likely it will remain pretty much the same in the future. So why not treat namedtuple like any other basic data structure, boost its internal implementation and simply use the existing unit tests to make sure there are no regressions? It seems the same barrier does not apply to tuples, lists and sets. > Of course, 1.9x faster attribute access > (http://bugs.python.org/issue28638#msg298499) is attractive. It is indeed and it makes a huge difference in situations like busy loops. E.g. in case of asyncio 1.9x faster literally means being able to serve twice the number of reqs/sec: https://github.com/python/cpython/blob/3e2ad8ec61a322370a6fbdfb2209cf74546f5e08/Lib/asyncio/selector_events.py#L523 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Giampaolo Rodola' added the comment: > Should we consider a C-based implementation like > https://github.com/ll/cnamedtuple? > It could improve speed even more, but would be harder to maintain and > test and harder to keep compatible. My sense is that it's not worth > it unless benchmarks show a really dramatic difference. I've just filed a ticket for this: https://github.com/ll/cnamedtuple/issues/7 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19640] Dynamically generate the _source attribute of namedtuple to save memory)
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28287] Refactor subprocess.Popen to let a subclass handle IO asynchronously
Giampaolo Rodola' added the comment: Is the main goal to just make Popen.__init__ non-blocking? If not, #1191964 aims at providing non-blocking reads/writes (including on Windows). -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30624] selectors should use bare except clauses
Giampaolo Rodola' added the comment: I see that on 3.6 except BaseException: is used, so the backport should not be necessary. -- resolution: -> fixed stage: backport needed -> resolved status: open -> closed versions: -Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30624] selectors should use bare except clauses
Giampaolo Rodola' added the comment: New changeset ced36a993fcfd1c76637119d31c03156a8772e11 by Giampaolo Rodola in branch 'master': bpo-30624 remaining bare except (#2108) https://github.com/python/cpython/commit/ced36a993fcfd1c76637119d31c03156a8772e11 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30624] selectors should use bare except clauses
Giampaolo Rodola' added the comment: > But only 2 of 3 "except Exception" are fixed. My bad. New PR: https://github.com/python/cpython/pull/2108 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30624] selectors should use bare except clauses
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- pull_requests: +2161 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30624] selectors should use bare except clauses
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- pull_requests: +2146 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30624] selectors should use bare except clauses
New submission from Giampaolo Rodola': Right now it uses "except Exception: ...; raise" which does not take KeyboardInterrupt and SystemExit into account, leaving the fd in a bad state (it's not unregister()ed). -- components: asyncio messages: 295648 nosy: berker.peksag, giampaolo.rodola, gvanrossum, haypo, neologix, serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: selectors should use bare except clauses versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors
Giampaolo Rodola' added the comment: Nobody has AFAIK. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Giampaolo Rodola' added the comment: OK, https://github.com/python/cpython/pull/1030 should be good to go. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- pull_requests: +1633 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Giampaolo Rodola' added the comment: OK thanks. Fix coming. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Giampaolo Rodola' added the comment: Mmm I can't see them. Am I supposed to enable this kind of warning somehow? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30295] msvcrt SetErrorMode not documented
New submission from Giampaolo Rodola': Also SEM_FAILCRITICALERRORS and other SEM_constants. They should as setting error mode on Windows for console applications is a pretty common use case (in fact ./Lib/test/libregrtest/setup.py uses it). -- assignee: docs@python components: Documentation messages: 293189 nosy: docs@python, giampaolo.rodola priority: normal severity: normal status: open title: msvcrt SetErrorMode not documented versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30286] ctypes FreeLibrary fails on Windows 64-bit
Giampaolo Rodola' added the comment: > It's documented that the default conversion for integer arguments is a 32-bit > C int. [...] Whenever a pointer is returned, you must set the function's > restype. OK, clear. Closing this out. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30286] ctypes FreeLibrary fails on Windows 64-bit
Giampaolo Rodola' added the comment: http://stackoverflow.com/questions/23522055/error-when-unload-a-64bit-dll-using-ctypes-windll Adding "ctypes.windll.kernel32.FreeLibrary.argtypes = [wintypes.HMODULE]" fixes the issue. This works: import ctypes from ctypes import wintypes path = 'C:\\Python35-64\\vcruntime140.dll' cfile = ctypes.CDLL(path) print(cfile._handle) ctypes.windll.kernel32.FreeLibrary.argtypes = [wintypes.HMODULE] ctypes.windll.kernel32.FreeLibrary(cfile._handle) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30286] ctypes FreeLibrary fails on Windows 64-bit
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +amaury.forgeotdarc, belopolsky, meador.inge, theller ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30286] ctypes FreeLibrary fails on Windows 64-bit
New submission from Giampaolo Rodola': >>> import ctypes >>> path = 'C:\\Python35-64\\vcruntime140.dll' >>> cfile = ctypes.CDLL(path) >>> cfile._handle 140736170229760 >>> ctypes.windll.kernel32.FreeLibrary(cfile._handle) Traceback (most recent call last): ctypes.windll.kernel32.FreeLibrary(cfile._handle) ctypes.ArgumentError: argument 1: : int too long to convert Everything is fine on 32-bit. -- components: ctypes messages: 293135 nosy: giampaolo.rodola priority: normal severity: normal status: open title: ctypes FreeLibrary fails on Windows 64-bit versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux
Giampaolo Rodola' added the comment: Thanks. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters
Giampaolo Rodola' added the comment: The relevant discussion of this bug is happening in https://github.com/python/cpython/pull/1214. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Giampaolo Rodola' added the comment: New changeset 5d7a8d0c13737fd531b722ad76c505ef47aac96a by Giampaolo Rodola in branch 'master': bpo-30190: improved error msg for assertAlmostEqual(delta=...) (#1331) https://github.com/python/cpython/commit/5d7a8d0c13737fd531b722ad76c505ef47aac96a -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30204] socket.setblocking(0) changes socket.type
Giampaolo Rodola' added the comment: Woo! I completely forgot I already bumped into this and that I even filed a ticket for it. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux
Giampaolo Rodola' added the comment: The change was introduced here: https://github.com/python/cpython/commit/b10c71daa2099c450101e5854fd693a405bec49c -- nosy: +neologix versions: +Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux
New submission from Giampaolo Rodola':
>>> import socket
>>> s = socket.socket(socket.AF_UNIX)
>>> s.getsockname()
b''
>>> s.bind('foo')
>>> s.getsockname()
'foo'
--
messages: 292580
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: socket.getsockname() type mismatch with AF_UNIX on Linux
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30205>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30204] socket.setblocking(0) changes socket.type
New submission from Giampaolo Rodola': This caused me a lot of headaches (broken test) before figuring out what the heck was wrong: =) >>> import socket >>> s = socket.socket() >>> s.type >>> s.setblocking(0) >>> s.type 2049 >>> s.setblocking(1) >>> s.type getsockopt() on the other hand always tells the truth: >>> s.getsockopt(socket.SOL_SOCKET, socket.SO_TYPE) 1 ...so I suppose we can do that in the "type" property of the Python socket class. It appears the type is set in socket init: https://github.com/python/cpython/blob/1e2147b9d75a64df370a9393c2b5b9d170dc0afd/Modules/socketmodule.c#L904 ...and it's changed later in setblocking: https://github.com/python/cpython/blob/1e2147b9d75a64df370a9393c2b5b9d170dc0afd/Modules/socketmodule.c#L609 -- components: Library (Lib) messages: 292576 nosy: giampaolo.rodola priority: normal severity: normal status: open title: socket.setblocking(0) changes socket.type versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29606] urllib FTP protocol stream injection
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Giampaolo Rodola' added the comment: Done. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Giampaolo Rodola' added the comment: Thanks for chiming in. > Is it worth to output a difference when the delta argument is not passed? Yes, probably. I will change that. > Is it worth to output a signed difference rather than an absolute value? Mmmm probably not IMHO. Personally I never care about the position of left and right arguments. I just want to check whether a and b are almost equal. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual improved error message
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- title: unittest's assertAlmostEqual should show the difference -> unittest's assertAlmostEqual improved error message ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual should show the difference
Giampaolo Rodola' added the comment: PR: https://github.com/python/cpython/pull/1331/ -- stage: needs patch -> patch review ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual should show the difference
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- pull_requests: +1439 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual should show the difference
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +ezio.melotti, michael.foord, rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30190] unittest's assertAlmostEqual should show the difference
New submission from Giampaolo Rodola': When comparing 2 numbers as "self.assertAlmostEqual(a, b, delta=1000)" the error message looks like this: AssertionError: 27332885 != 27391120 within 1000 delta Especially when a and b are big numbers or differ a lot, it would be useful to see the absolute difference between the 2 numbers as in: AssertionError: 27332885 != 27391120 within 1000 delta (58235 difference) -- messages: 292477 nosy: giampaolo.rodola priority: normal severity: normal stage: needs patch status: open title: unittest's assertAlmostEqual should show the difference versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9285] Add a profile decorator to profile and cProfile
Giampaolo Rodola' added the comment: Original patch still applies. Not sure if we should continue with that one or with your new PR. The original assertion error is still there. I CCed Tim Peters as it appears he's the one who originally added it in 2001 - maybe he has some clue. -- versions: +Python 3.7 -Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26860] Make os.walk and os.fwalk yield namedtuple instead of tuple
Giampaolo Rodola' added the comment: Should we have concerns about performances? Accessing a namedtuple value is almost 4x times slower compared to a plain tuple [1] and os.walk() may iterate hundreds of times. http://stackoverflow.com/questions/2646157/what-is-the-fastest-to-access-struct-like-object-in-python -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Giampaolo Rodola' added the comment:
For the sake of experiment I'm attaching a toy echo server which uses modify()
to switch between EVENT_READ and EVENT_WRITE. Without patch I get 35000
req/sec, with patch around 39000 req/sec (11.4% faster).
To be entirely honest a smarter echo server would switch between EVENT_READ /
EVENT_WRITE only in case of BlockingIOError on send() or recv(), but
unfortunately it's a condition which (for send()) does not occur often by
testing on localhost (for recv() it naturally occurs +27000 times out of
39000). On the other hand, by experimenting with a real network it occurs quite
soon:
import socket
sock = socket.socket()
sock.connect(('google.com', 80))
sock.setblocking(False)
print(sock.send(b'x' * 5))
print(sock.send(b'x' * 5)) # raise BlockingIOError
So basically my benchmark is emulating a worst case scenario in which send()
always blocks on the first call and succeed on the next one, in order to mimic
recv() which blocks half of the times.
The whole point is that the speedup entirely depends on how many times send()
or recv() will block in a real world app connected to the internet (because
that's when modify() is supposed to be used) but that's hard to determine,
especially under heavy server loads which is hard to emulate. This also
involves the SSL handshake when it fails with WANT_READ / WANT_WRITE, which is
another circumstance where modify() is going to be used and for which I have no
benchmarks.
I personally don't mind about selectors module per-se, but given that it's the
core of important libs such as asyncio and curio I would like to hear a better
rationale than "let's reject this 1.5x speedup because DRY does not apply in
this case".
Also please consider that Tornado, Twisted and gevent use native modify()
method.
--
Added file: http://bugs.python.org/file46792/echo_server.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30014>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: Added file: http://bugs.python.org/file46793/echo_client.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Giampaolo Rodola' added the comment: @neologix: here's a PR which refactors the poll-related classes: https://github.com/python/cpython/pull/1035/files >From there, we'll be able to avoid modify() code duplication. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Giampaolo Rodola' added the comment: In certain protocols modify() is supposed to be used on every interaction between client and server. E.g. an FTP server does this: - register(fd, EVENT_READ); recv() # wait command from client - modify(fd, EVENT_WRITE); send(response) # send response - modify(fd, EVENT_READ); recv() # wait for new command ...so it's two calls for each command received. In asyncio modify() is also used in different circumstances. If you're worried about code duplication I can refactor selectors.py first, but IMO it would be a bad idea to reject this or future improvements because the current code status prevents code reuse. Right now there are already 3 classes sharing basically the same code (poll, epoll and devpoll related classes). Those can be refactored similarly to this: https://github.com/giampaolo/pyftpdlib/blob/ab699b5f89223e03593f3e004d6a370b4c2e5308/pyftpdlib/ioloop.py#L465-L565 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 1.5x
Giampaolo Rodola' added the comment: > The idea is to reuse _BaseSelectorImpl.register() and > _BaseSelectorImpl.unregister() to factorize the code. You can't factorize the logic of modify() into those as they do two different things. I also don't like repeating the same thing 3 times but given how the module is organized I'm not sure how to do that as I need to pass 3 things around: the low-level selector (epoll, poll, whatever) and the read and write constants (POLLIN, EPOLLIN) which change depending on the selector being used. The same thing applies to the devpoll class (http://bugs.python.org/issue18931). I can write a second patch which to refactor the whole module if that is desirable but I prefer to do that in another PR. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 1.5x
Giampaolo Rodola' added the comment: > My patch calls generic unregister() and register() of the base > classes, but it only uses one syscall per modify() call. Doesn't that mean doing 3 operations (unregister(), register(), modify()) instead of the current 2 (unregister(), register())? I don't see how it can be faster than a single modify() syscall. > Oh by the way, it seems like my patch changes KqueueSelector, > but your change doesn't. Am I right? You are right but it looks like you end up doing the same thing as unregister() and register(). kqueue() has no modify() method so I don't think it can benefit from this change. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Giampaolo Rodola' added the comment: PR: https://github.com/python/cpython/pull/1030 -- pull_requests: +1187 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Giampaolo Rodola' added the comment: Hey Stinner, thanks for chiming in! Your old patch uses unregister() and register() so I'm not sure what speedup that'll take as the whole point is to avoid doing that. You may want to rewrite it and benchmark it but it looks like it'll be slower. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Giampaolo Rodola' added the comment: modify() can be used often in verbose protocols such as FTP and SMTP where a lot of requests and responses are continuously exchanged between client and server, so you need to switch from EVENT_READ to EVENT_WRITE all the time. I did a similar change some years ago in pyftpdlib but I don't have another benchmark other than this one. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- components: +Library (Lib), asyncio stage: -> patch review type: -> performance ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +gvanrossum, haypo, neologix, yselivanov ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- versions: +Python 3.7 Added file: http://bugs.python.org/file46788/bench.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30014] Speedup DefaultSelectors.modify() by 2x
New submission from Giampaolo Rodola':
Patch in attachment modifies DefaultSelector.modify() so that it uses the
underlying selector's modify() method instead of unregister() and register()
resulting in a 2x speedup.
Without patch:
~/svn/cpython {master}$ ./python bench.py
0.006010770797729492
With patch:
~/svn/cpython {master}$ ./python bench.py
0.00330352783203125
--
files: selectors_modify.diff
keywords: patch
messages: 291261
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: Speedup DefaultSelectors.modify() by 2x
Added file: http://bugs.python.org/file46787/selectors_modify.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30014>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9285] Add a profile decorator to profile and cProfile
Giampaolo Rodola' added the comment: The original patch is basically blocked by the cryptic assertion error reported above. It's not clear what it means or how to work around it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28931] urllib ignores FTP 226 response, breaking further FTP requests
Giampaolo Rodola' added the comment: I can't reproduce the issue on Python 3.5 (but I can on 2.7). -- nosy: +giampaolo.rodola versions: -Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25458] ftplib: command response shift - mismatch
Giampaolo Rodola' added the comment: Maybe it's me but I still fail to understand what's the issue here. From what I understand from the last message(s) it seems there is complaint about not being able to use ftplib with threads. FTP is a "command - response" protocol which is designed to handle one request at a time, meaning you send a command then you are supposed to *wait* to get a response back. If you want to do multiple transfers in parallel then you need a separate connection, not a separate thread using the same connection. ftplib should *not* be thread-safe because of how FTP works. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28963] Use-after-free in _asyncio_Future_remove_done_callback() of _asynciomodule.c
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: -giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17038] multiprocessing only use one core when C module are imported
Giampaolo Rodola' added the comment: Ended up here by accident. For whoever bumps into this same issue, psutil allows to get an set CPU affinity, so you can avoid using taskset. >>> import psutil >>> psutil.cpu_count() 4 >>> p = psutil.Process() >>> p.cpu_affinity() # get [0, 1, 2, 3] >>> p.cpu_affinity([0]) # set; from now on, process will run on CPU #0 only >>> p.cpu_affinity() [0] >>> >>> # reset affinity against all CPUs >>> all_cpus = list(range(psutil.cpu_count())) >>> p.cpu_affinity(all_cpus) >>> -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10049] Add a "no-op" (null) context manager to contextlib
Giampaolo Rodola' added the comment: ExitStack() already covers the "null ctx mgr" use case described in the first message. Original example: with transaction or contextlib.null(): ... By using ExitStack: with transaction or ExitStack(): ... You can push this further and do this, which is even more flexible: with ExitStack() as stack: if condition: stack.enter_context(transaction) ... So ExitStack really is better than the original proposal which could have made sense 6 years ago but not anymore. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28684] [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: -giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat): write a new smtp server with asyncio
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25002] Deprecate asyncore/asynchat
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5309] distutils doesn't parallelize extension module compilation
Giampaolo Rodola' added the comment: I have 2 complaints about this: 1 - doc is missing: the only way to be aware of this is either by reading the 3.6 what's new doc or by checking the cmdline helper 2 - -j "N" parameter could be optional: if not specified os.cpu_count() can be used. -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27876] Add SSLContext.set_version_range(minver, maxver=None)
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: -giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27768] ssl: get CPU cap flags for AESNI and PCLMULQDQ
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: -giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15670] PEP 3121, 384 Refactoring applied to ssl module
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: -giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23588] Errno conflicts in ssl.SSLError
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: -giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23843] ssl.wrap_socket doesn't handle virtual TLS hosts
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: -giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26081] Implement asyncio Future in C to improve performance
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
Changes by Giampaolo Rodola' <g.rod...@gmail.com>: -- nosy: +giampaolo.rodola ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
