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.p
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://gith
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 t
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 pra
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 b
Change by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: -giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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
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
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.
-
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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
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
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
assignee: -> giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
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/i
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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/i
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.or
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
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
w
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
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/pyf
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, P
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, P
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, P
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
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
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
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 <
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, P
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
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
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
pull_requests: +2161
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30624>
___
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
pull_requests: +2146
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30624>
___
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: ber
Giampaolo Rodola' added the comment:
Nobody has AFAIK.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30581>
___
___
Python-bugs-
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/i
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
pull_requests: +1633
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30190>
___
Giampaolo Rodola' added the comment:
OK thanks. Fix coming.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30190>
___
___
Pyth
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/i
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
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:
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
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, theller
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
Giampaolo Rodola' added the comment:
Thanks.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30205>
___
___
Python-bugs-list
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/i
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
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.pytho
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>
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
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.setblo
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Giampaolo Rodola' added the comment:
Done.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30190>
___
___
Python-bugs-list
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
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
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.or
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
pull_requests: +1439
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30190>
___
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +ezio.melotti, michael.foord, rbcollins
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 usef
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
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
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
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
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 &
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
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
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
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/i
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
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
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.
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +gvanrossum, haypo, neologix, yselivanov
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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
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.p
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>
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 i
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: -giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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()
>>>
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 furt
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: -giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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() ca
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: -giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: -giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: -giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: -giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: -giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Giampaolo Rodola' <g.rod...@gmail.com>:
--
nosy: +giampaolo.rodola
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
301 - 400 of 1713 matches
Mail list logo
