[issue39118] Variables changing values on their own
New submission from Leonardo : in this code the variable o changes on its own: x=[[-1, 7, 3], [12, 2, -13], [14, 18, -8], [17, 4, -4]] x1=[[-8, -10, 0], [5, 5, 10], [2, -7, 3], [9, -8, -3]] y=[[0,0,0],[0,0,0],[0,0,0],[0,0,0]] k=True f=0 z=[] d=[] while k: print(k) o=x print(o) for i in range(len(x)): for n in range(len(x)): if i!=n: for g in range(3): if x[i][g]>x[n][g]: y[i][g]-=1 if x[i][g] <https://bugs.python.org/issue39118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9670] Exceed Recursion Limit in Thread
Leonardo Santagada added the comment: Why not make it bigger so it doesn't crash for much bigger functions? -- nosy: +santagada ___ Python tracker <http://bugs.python.org/issue9670> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9670] Exceed Recursion Limit in Thread
Leonardo Santagada added the comment: The default stack size in osx is 8MB. I think it is a safer bet, and no one is supposed to be using more than like 40-50 threads anyway (specially in 32 bit only systems limited to 8 cores). Is there a user case for hundreds/thousands of threads in python? -- ___ Python tracker <http://bugs.python.org/issue9670> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3261] Lib/test/test_cookielib declares utf-8 encoding, but contains non-valid bytes
New submission from Leonardo Soto <[EMAIL PROTECTED]>: http://svn.python.org/projects/python/branches/release25-maint/Lib/test/test_cookielib.py contains non-utf8 bytes. Currently, That confuses Jython. -- messages: 69115 nosy: leosoto severity: normal status: open title: Lib/test/test_cookielib declares utf-8 encoding, but contains non-valid bytes versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3261> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3261] Lib/test/test_cookielib declares utf-8 encoding, but contains non-valid bytes
Leonardo Soto <[EMAIL PROTECTED]> added the comment: Thanks, that was fast! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3261> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4242] Classify language vs. impl-detail tests, step 1
Changes by Leonardo Soto : -- nosy: +leosoto ___ Python tracker <http://bugs.python.org/issue4242> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33384] Build does not work with closed stdin on NetBSD
Leonardo Taccari added the comment: Hello Victor, I can confirm that I can no longer reproduce this problem with Python 3.7.5 on NetBSD and according a double-check to Python/pylifecycle.c:is_valid_fd() now fstat() is always used on NetBSD. Thanks for the update and for looking at it! -- ___ Python tracker <https://bugs.python.org/issue33384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38263] [Windows] multiprocessing: DupHandle.detach() race condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)
Leonardo Rick added the comment: Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python39\lib\multiprocessing\spawn.py", line 116, in spawn_main exitcode = _main(fd, parent_sentinel) File "C:\Program Files\Python39\lib\multiprocessing\spawn.py", line 126, in _main self = reduction.pickle.load(from_parent) File "C:\Program Files\Python39\lib\multiprocessing\connection.py", line 967, in rebuild_pipe_connection handle = dh.detach() File "C:\Program Files\Python39\lib\multiprocessing\reduction.py", line 131, in detach return _winapi.DuplicateHandle( PermissionError: [WinError 5] Acesso negado -- nosy: +leonardo2 versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue38263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44074] patchcheck checks against branch "master" not "main"
Change by Leonardo Lai : -- keywords: +patch nosy: +leoll2 nosy_count: 1.0 -> 2.0 pull_requests: +24644 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25991 ___ Python tracker <https://bugs.python.org/issue44074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44074] patchcheck checks against branch "master" not "main"
Leonardo Lai added the comment: I've just created a patch for this. Now it can automatically detect the default branch name (`main`, `master` or whatever) -- ___ Python tracker <https://bugs.python.org/issue44074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44573] Organize some data files in the Lib/test directory
New submission from Leonardo Freua : I noticed that some data files (used to perform some specific tests) are not organized in specific directories of their categories. Some files that I found are audiotest.au, badcert.pem, badkey.pem, cfgparser.1, cfgparser.2, etc (some are even .py files). I'm working on an organization so they don't get mixed up with the test files, but how the rest of the data files are organized (audiodata, capath, cjkencodings, etc.). -- components: Tests messages: 397056 nosy: Leonardofreua priority: normal severity: normal status: open title: Organize some data files in the Lib/test directory versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44573] Organize some data files in the Lib/test directory
Change by Leonardo Freua : -- stage: -> resolved status: open -> closed type: -> enhancement ___ Python tracker <https://bugs.python.org/issue44573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44573] Organize some data files in the Lib/test directory
Change by Leonardo Freua : -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue44573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44612] inspect module points that could be using f-String
New submission from Leonardo Freua : There are some points in inspect module (I counted 48 since version 3.7) that could be using f-String formatting instead of format(). Changing these points will improve code readability, it will also decrease the complexity at these points and not to mention the fact that f-String formatting has better performance. Obs.: Many other points could receive this improvement in other modules. This would provide the improvements I mentioned earlier, especially in older snippets of code. -- components: Library (Lib) messages: 397343 nosy: Leonardofreua priority: normal severity: normal status: open title: inspect module points that could be using f-String type: enhancement versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44612] inspect module points that could be using f-String
Change by Leonardo Freua : -- keywords: +patch pull_requests: +25648 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27100 ___ Python tracker <https://bugs.python.org/issue44612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44612] inspect module points that could be using f-String
Leonardo Freua added the comment: Understood. Anyway, it was good to try to help at this point. -- ___ Python tracker <https://bugs.python.org/issue44612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44612] inspect module points that could be using f-String
Leonardo Freua added the comment: Thanks, Ammar. I'll look. -- ___ Python tracker <https://bugs.python.org/issue44612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44628] Remove the broken link for issue #445902 in unixcompiler.py (distutils)
New submission from Leonardo Freua : There is a broken link in the docstring of the runtime_library_dir_option() method of the UnixCCompiler class. See the broken link below: http://sourceforge.net/tracker/index.php?func=detail&aid=445902&group_id=5470&atid=105470 And the link that is working for this same issue: https://bugs.python.org/issue445902 I will send a PR removing the link, leaving without it, as there is already exists the issue ID in the docstring. -- components: Library (Lib) messages: 397436 nosy: Leonardofreua priority: normal severity: normal status: open title: Remove the broken link for issue #445902 in unixcompiler.py (distutils) versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44628] Remove the broken link for issue #445902 in unixcompiler.py (distutils)
Change by Leonardo Freua : -- keywords: +patch pull_requests: +25666 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27121 ___ Python tracker <https://bugs.python.org/issue44628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44629] Some files from distutils module are importing all exceptions unnecessarily
New submission from Leonardo Freua : Some files from the distutils module are importing all the exceptions from the errors.py file unnecessarily, when in fact only a few of the Exception classes are used. Could I open a PR by fixing the files that are making these unnecessary imports? Or is this problem in the same category as f-String refactorings? -- components: Library (Lib) messages: 397441 nosy: Leonardofreua priority: normal severity: normal status: open title: Some files from distutils module are importing all exceptions unnecessarily type: enhancement versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44629> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44631] Refactoring the repr() of the _Environ class (os module)
New submission from Leonardo Freua : Currently, the repr() code of the _Environ class does many things in a bunched way, making it difficult to read and difficult to determine the result returned by the method. Therefore, I propose an adjustment in the code to make it more readable, as well as your test. -- components: Library (Lib) messages: 397448 nosy: Leonardofreua priority: normal severity: normal status: open title: Refactoring the repr() of the _Environ class (os module) type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44631] Refactoring the repr() of the _Environ class (os module)
Change by Leonardo Freua : -- keywords: +patch pull_requests: +25671 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27128 ___ Python tracker <https://bugs.python.org/issue44631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10572] Move test sub-packages to Lib/test
Leonardo Freua added the comment: After so long a reason came up that prevents the movement of tests of ctypes, lib2to3, and idlelib (which even continues in the same folder, only the nomenclature was changed)? -- nosy: +Leonardofreua ___ Python tracker <https://bugs.python.org/issue10572> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44650] Move test_futures files* into a subdirectory of Lib/test
New submission from Leonardo Freua : There are currently 6 files referring to __future__ tests, these are in the root directory Lib/test. It would be interesting to move them to a directory called Lib/test/test_future. This change could contribute to the organization of the tests that have already been discussed in other issues (e.g https://bugs.python.org/issue15907). I wait for the ok to send the PR. -- messages: 397581 nosy: Leonardofreua priority: normal severity: normal status: open title: Move test_futures files* into a subdirectory of Lib/test ___ Python tracker <https://bugs.python.org/issue44650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44650] Move test_futures files*.py into a subdirectory of Lib/test
Change by Leonardo Freua : -- title: Move test_futures files* into a subdirectory of Lib/test -> Move test_futures files*.py into a subdirectory of Lib/test ___ Python tracker <https://bugs.python.org/issue44650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44650] Move test_futures files* into a subdirectory of Lib/test
Change by Leonardo Freua : -- components: +Library (Lib), Tests type: -> enhancement versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue44650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44650] Move test_futures files*.py into a subdirectory of Lib/test
Leonardo Freua added the comment: List of files: test_future.py test_future3.py test_future4.py test_future5.py Obs.: In fact there are 5 files, since the number 2 doesn't exist. -- ___ Python tracker <https://bugs.python.org/issue44650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44650] Move test_futures files*.py into a subdirectory of Lib/test
Leonardo Freua added the comment: Definitely not the same kind of reorganization! In issue44573 what was proposed was the reorganization of the data files used in the tests. And what I'm proposing now is equivalent to what was proposed in issue15907 (and there it was accepted, there is even an open PR awaiting review.) -- ___ Python tracker <https://bugs.python.org/issue44650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44629] Some files from distutils module are importing all exceptions unnecessarily
Leonardo Freua added the comment: Hi Éric, thanks for the info. I'm still learning about all the processes and how things work around here in order to avoid opening issues that no longer make sense. Thanks you again. -- ___ Python tracker <https://bugs.python.org/issue44629> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44701] Create a @deprecated decorator (annotation)
New submission from Leonardo Freua :
Would it be interesting to create a @deprecated decorator to avoid adding
warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in
methods body?
Using the decorator approach to indicate depreciation would make the methods
cleaner (leaving only their responsibilities in the body) and would be easier
to identify, as the cue would be close to the method signature and not mixed
with the logic inside the body.
If everyone agrees, I could submit a PR (as a draft) for us to evaluate this
functionality.
--
components: Library (Lib)
messages: 397958
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: Create a @deprecated decorator (annotation)
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue44701>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35728] Tkinter font nametofont requires default root
Leonardo Freua added the comment: Has the PR already solved the problem? If yes, could this issue not be closed? -- nosy: +Leonardofreua ___ Python tracker <https://bugs.python.org/issue35728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44701] Create a @deprecated decorator (annotation)
Leonardo Freua added the comment: Ok thanks, I'll do it. -- ___ Python tracker <https://bugs.python.org/issue44701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39149] False positive using operator 'AND' while checking keys on dict()
New submission from Leonardo Galani :
using Python 3.7.6 (default, Dec 27 2019, 09:51:07) @ macOs
dict = { 'a': 1, 'b': 2, 'c': 3 }
if you `if 'a' and 'b' and 'c' in dict: print('ok')` you will get a True, since
everything is true.
if you `if 'a' and 'g' and 'c' in dict: print('ok')` you also get a True
because the last statement is True but the mid statement is false.
To avoid this false positive, you need to be explicit:
`if 'a' in dict and 'g' in dict and 'c' in dict: print('ok')` you will get a
false.
--
components: macOS
messages: 358954
nosy: leonardogalani, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: False positive using operator 'AND' while checking keys on dict()
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue39149>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39149] False positive using operator 'AND' while checking keys on dict()
Leonardo Galani added the comment: I would totally agree if it wasn't for this: >>> 'a' and 'b' and 'g' in dict False The last evaluation is False, making the whole statement False. but thanks for the documentation link and stackoverflow suggestion. it sure does make the code more readable. Happy new year! -- ___ Python tracker <https://bugs.python.org/issue39149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36395] Add deferred single-threaded/fake executor to concurrent.futures
Leonardo Santagada added the comment: I have a single example: Profiling. As most python profilers don't support threads or processes, it would be very convenient to have a in process executor in those cases. -- nosy: +santagada ___ Python tracker <https://bugs.python.org/issue36395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19809] Doc: subprocess should warn uses on race conditions when multiple threads spawn child processes
Leonardo Santagada added the comment: This is still the case on windows as the pipes created to talk to the process might be inherited by two or more simultaneous CreateProcess calls. I've found a suggested solution to this: https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873 By only inheriting the stdout/err/in handles and them supporting close_fds for windows. Would more users be interested in a proper patch for this? For us now we have a lock around Popen.__init__ but that obviously doesn't suport subinterpreters and other calls to CreateProcess that might happen. -- nosy: +santagada versions: +Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue19809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31378] Missing documentation for sqlite3.OperationalError
New submission from Leonardo Taglialegne: sqlite3.OperationalError has no documentation whatsoever in docs.python.org -- assignee: docs@python components: Documentation messages: 301575 nosy: Leonardo Taglialegne, docs@python priority: normal severity: normal status: open title: Missing documentation for sqlite3.OperationalError type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31378> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
New submission from Leonardo Francalanci:
the script below (a python process is called, which calls a waitfor cmd with a
timeout of 4 seconds) is supposed to end after 4 seconds. But instead
proc.communicate stops after the 20 seconds timeout.
Everything works 100% ok if I remove the stdin/stderr/stdout parameters...
if __name__ == "__main__":
#start a python process which will wait for 4 seconds and then exit (waitfor
is set to 200):
proc_str = ["C:\\Program Files (x86)\\Anaconda3\\Python.exe",
"-c", "import
subprocess;subprocess.run('cmd /S /C waitfor g /t 200', shell=False,
timeout=4)"]
proc = subprocess.Popen(proc_str,
stdin=subprocess.PIPE,
stderr=subprocess.PIPE,
stdout=subprocess.PIPE,
shell=False,
universal_newlines=True)
#this should exit in 4 seconds (when the called process exits), but instead
exits after 20 seconds:
(proc_out, proc_err) = proc.communicate(timeout=20)
--
messages: 302051
nosy: Leonardo Francalanci
priority: normal
severity: normal
status: open
title: proc communicate not exiting on python subprocess timeout using PIPES
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue31447>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
Changes by Leonardo Francalanci : -- components: +Interpreter Core type: -> behavior ___ Python tracker <https://bugs.python.org/issue31447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
Leonardo Francalanci added the comment: The called "C:\\Program Files (x86)\\Anaconda3\\Python.exe" process exits after 4 seconds. The reason why it ends shouldn't matter, right? I expect that a call to communicate should exit as soon as the called process is not running anymore. I don't hold a pipe with "waitfor", I hold it with python.exe. -- ___ Python tracker <https://bugs.python.org/issue31447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
Leonardo Francalanci added the comment: thank you for your replies! I used waitfor because it's the simplest and shortest way to have reproducible code. The issue I'm having is obviously not with waitfor, but with another exe, but this doesn't change the fact that I need a way to exit as soon as the called process exits or the timeout ends. I don't care what the called process does. I know that the process exited, and the docs for proc.communicate say "Wait for process to terminate". Well, the process terminates, but "communicate" doesn't exit. It doesn't say "communicate will hang as long as the pipes are open". Plus: the "python.exe" process doesn't actually timeout!!! It just exits (with exception, but that's not important), and I would like to get the error from stderr! While I can't get it because "communicate" raises an exception... -- ___ Python tracker <https://bugs.python.org/issue31447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
Leonardo Francalanci added the comment: (forgot: Issue 26534 is about shell=True, I use shell=False, right?) -- ___ Python tracker <https://bugs.python.org/issue31447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
Leonardo Francalanci added the comment: I have a workaround, and I guess this means there's a bug in the current implementation of stdout/stderr=subprocess.PIPE; if I open my own pipes instead of using subprocess.PIPE everything seems to work (provided I close the pipe before reading from it): (errPipeR, errPipeW) = os.pipe(); (outPipeR, outPipeW) = os.pipe(); proc = subprocess.Popen(proc_str, stdin=subprocess.PIPE, stderr=errPipeW, stdout=outPipeW,shell=False, universal_newlines=True) proc.communicate(timeout=20) os.close(outPipeW) os.close(errPipeW) Now I can read from the "R" pipes with 0 problems (getting the error and output streams), and proc.communicate exits as soon as the called process exits (4 seconds). So, since I can use my own pipes without any problems, I don't see why the regular "subprocess.PIPE" shouldn't be working... -- ___ Python tracker <https://bugs.python.org/issue31447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
Leonardo Francalanci added the comment: I'm really sorry, you are 100% correct: it blocks on the pipe (my tests killed the process tree before reading from the pipes). Still, I think there should be a way to actually read the output also in this case... works for me when I kill the whole process stack. -- ___ Python tracker <https://bugs.python.org/issue31447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
Leonardo Francalanci added the comment:
can I at least change the call to:
subprocess.run('cmd /S /C waitfor g /t 200', shell=False, timeout=4)
in any way to avoid the problem?
I tried with
stdin=subprocess.DEVNULL,stdout=subprocess.DEVNULL,stderr=subprocess.DEVNULL;
also with close_fds=True, but nothing changes...
--
___
Python tracker
<https://bugs.python.org/issue31447>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
Leonardo Francalanci added the comment: That works! But when I said "also with close_fds=True", I meant that I tried WITHOUT overriding stdin, stdout, and stderr AND setting close_fds=True, but it didn't work. What worked was not overriding stdin/out/err and adding os.set_inheritable(0, False) os.set_inheritable(1, False) os.set_inheritable(2, False) before the call (no need to set close_fds) -- ___ Python tracker <https://bugs.python.org/issue31447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux)
New submission from Leonardo Mörlein :
The tuple (host, port) is ("fe80::5054:01ff:fe04:3402%node4_client", 22) in
https://github.com/python/cpython/blob/master/Lib/asyncio/base_events.py#L918.
The substring "node4_client" identifies the interface, which is needed for link
local connections.
The function self._ensure_resolved() is called and resolves to
infos[0][4] = ("fe80::5054:01ff:fe04:3402", 22, something, 93), where 93 is the
resolved scope id (see sin6_scope_id from struct sockaddr_in6 from man ipv6).
Afterwards the self.sock_connect() is called with address = infos[0][4]. In
self.sock_connect() the function self._ensure_resolved() is called again. In
https://github.com/python/cpython/blob/master/Lib/asyncio/base_events.py#L1282
the scope id is stripped from the tuple. The tuple (host, port) is now only
("fe80::5054:01ff:fe04:3402", 22) and therefore the scope id is lost.
I wrote this quick fix, which is not really suitable as a real solution for the
problem:
lemoer@orange ~> diff /usr/lib/python3.7/asyncio/base_events.py{.bak,}
--- /usr/lib/python3.7/asyncio/base_events.py.bak 2019-02-21
18:42:17.060122277 +0100
+++ /usr/lib/python3.7/asyncio/base_events.py 2019-02-21 18:49:36.886866750
+0100
@@ -942,8 +942,8 @@
sock = None
continue
if self._debug:
-logger.debug("connect %r to %r", sock, address)
-await self.sock_connect(sock, address)
+logger.debug("connect %r to %r", sock, (host, port))
+await self.sock_connect(sock, (host, port))
except OSError as exc:
if sock is not None:
sock.close()
--
components: asyncio
messages: 336253
nosy: Leonardo Mörlein, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: create_connection cannot handle IPv6 link-local addresses
anymore (linux)
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue36069>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux)
Leonardo Mörlein added the comment: The generated error is: OSError: [Errno 22] Invalid argument -- ___ Python tracker <https://bugs.python.org/issue36069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux)
Leonardo Mörlein added the comment: It seems to be a regression, as my python 3.6 version is not affected: lemoer@orange ~> python3.6 --version Python 3.6.8 My python 3.7 version is affected: lemoer@orange ~> python3.7 --version Python 3.7.2 -- ___ Python tracker <https://bugs.python.org/issue36069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux)
Change by Leonardo Mörlein : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux)
Leonardo Mörlein added the comment: Oh, you are correct. So this can be closed. -- ___ Python tracker <https://bugs.python.org/issue36069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33384] Build does not work with closed stdin
Leonardo Taccari added the comment: A simpler way to reproduce that (probably this problem is not limited to building but to sys module): (sleep 10; python3.6 -c 'import sys' >/tmp/log 2>&1) & exit And in `/tmp/log': Fatal Python error: Py_Initialize: can't initialize sys standard streams OSError: [Errno 9] Bad file descriptor Current thread 0x7226e0ab3800 (most recent call first): -- nosy: +leot ___ Python tracker <https://bugs.python.org/issue33384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33384] Build does not work with closed stdin
Leonardo Taccari added the comment:
And here the backtrace of the corresponding core (this is on
NetBSD/amd64 8.99.15 with lang/python36 package of today pkgsrc-current):
% gdb -core python3.6.core `which python3.6`
Reading symbols from /usr/pkg/bin/python3.6...done.
[New process 1]
Core was generated by `python3.6'.
Program terminated with signal SIGABRT, Aborted.
#0 0x76255932924a in _lwp_kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0x76255932924a in _lwp_kill () from /usr/lib/libc.so.12
#1 0x762559328e65 in abort () at /usr/src/lib/libc/stdlib/abort.c:74
#2 0x76255a749d33 in Py_FatalError (msg=msg@entry=0x76255a7dea20
"Py_Initialize: can't initialize sys standard streams")
at Python/pylifecycle.c:1462
#3 0x76255a74af4c in _Py_InitializeEx_Private (install_sigs=1,
install_importlib=1) at Python/pylifecycle.c:450
#4 0x76255a764902 in Py_Main (argc=argc@entry=3,
argv=argv@entry=0x76255ab01060) at Modules/main.c:700
#5 0x00400e2f in main (argc=3, argv=) at
./Programs/python.c:69
(gdb) f 4
#4 0x76255a764902 in Py_Main (argc=argc@entry=3,
argv=argv@entry=0x76255ab01060) at Modules/main.c:700
700 Py_Initialize();
(gdb) f 3
#3 0x76255a74af4c in _Py_InitializeEx_Private (install_sigs=1,
install_importlib=1) at Python/pylifecycle.c:450
450 Py_FatalError(
(gdb) list
445 if (_PyTraceMalloc_Init() < 0)
446 Py_FatalError("Py_Initialize: can't initialize
tracemalloc");
447
448 initmain(interp); /* Module __main__ */
449 if (initstdio() < 0)
450 Py_FatalError(
451 "Py_Initialize: can't initialize sys standard streams");
452
453 /* Initialize warnings. */
454 if (PySys_HasWarnOptions()) {
Please let me know if any further information is needed and I will try
to help!
Thank you!
--
___
Python tracker
<https://bugs.python.org/issue33384>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33384] Build does not work with closed stdin
Leonardo Taccari added the comment: After testing is_valid_fd() (from Python/pylifecycle.c) separately (an `is_valid_fd.c' file will be attached to ease reproduction) I think that also NetBSD is affected by bpo-30225. Using dup(2) (at is currently done in NetBSD): % cc -o ivf is_valid_fd.c % sleep 5 && ./ivf > /tmp/log & exit [... the terminal is closed via ^D ...] % cat /tmp/log 0: 1 1: 1 2: 1 Using fstat(2): % cc -DUSE_FSTAT -o ivf is_valid_fd.c % sleep 5 && ./ivf > /tmp/log & exit [... the terminal is closed via ^D ...] % cat /tmp/log 0: 0 1: 1 2: 0 The possible attached patch seems to fix the problem reported by Martin. -- Added file: https://bugs.python.org/file47604/patch-Python_pylifecycle.c ___ Python tracker <https://bugs.python.org/issue33384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33384] Build does not work with closed stdin
Change by Leonardo Taccari : Added file: https://bugs.python.org/file47605/is_valid_fd.c ___ Python tracker <https://bugs.python.org/issue33384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16749] Fatal Python Error
Leonardo DaVinci added the comment: Ok thanks for the quick reply. I'll check with them. Regards Ciro On Fri, Dec 21, 2012 at 9:09 PM, R. David Murray wrote: > > R. David Murray added the comment: > > Given the error message, my guess would be that there is a bug in the > Solidoodle Python extension module. That is, it is unlikely to be a bug in > Python. > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue16749> > ___ > -- ___ Python tracker <http://bugs.python.org/issue16749> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16749] Fatal Python Error
Leonardo DaVinci added the comment: Hi David, I keep trying to unsuccessfully. Here's the problem details Problem signature: Problem Event Name: APPCRASH Application Name: python.exe Application Version: 0.0.0.0 Application Timestamp: 4f84a6c8 Fault Module Name: python27.dll Fault Module Version: 2.7.3150.1013 Fault Module Timestamp: 4f84a6c7 Exception Code: 4015 Exception Offset: 0006016a OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 3084 Additional Information 1: 8c07 Additional Information 2: 8c07c320598b1e31bf5de83aa7155e8f Additional Information 3: 8e83 Additional Information 4: 8e835205385ec5be9858c1342251f482 Hope this helps Regards Ciro On Fri, Dec 21, 2012 at 9:09 PM, R. David Murray wrote: > > R. David Murray added the comment: > > Given the error message, my guess would be that there is a bug in the > Solidoodle Python extension module. That is, it is unlikely to be a bug in > Python. > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue16749> > ___ > -- ___ Python tracker <http://bugs.python.org/issue16749> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16749] Fatal Python Error
Leonardo DaVinci added the comment: Ok I'll try booting and installing in Mac to see if the issue reappears. Thanks for your time. Happy holidays. Ciro On Sat, Dec 22, 2012 at 9:46 AM, R. David Murray wrote: > > R. David Murray added the comment: > > Not really, I'm afraid. You'd have to look at the crash dump in a > debugger to get more useful information. Perhaps one of the windows devs > will have more concrete advice, I don't use Windows myself. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue16749> > ___ > -- ___ Python tracker <http://bugs.python.org/issue16749> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16749] Fatal Python error: PyEval_RestoreThread: NULL tstate
Leonardo DaVinci added the comment: Terry, I've tried installing on Mac at least 6 times and I still get error messages. I'm dealing with Solidoodle with no success. I have an appointment with a 3d Print Lab on Jan 3rd (50 miles away) to help me resolve my issues. Regards Ciro On Fri, Dec 28, 2012 at 5:07 PM, Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > Antoine: do you know anything about this message? > Fatal Python error: PyEval_RestoreThread: NULL tstate > Is there a serious possibility that it could indicate a CPython error, as > opposed to an extension author error? Could running Windows on Mac hardware > make a difference? > > Leonardo: You should have quoted the full error message instead of making > each person search the image. > > Also, Please don't quote entire messages in your replies (which means > deleting them if replying with a mail program). They are already visible > above your reply and constitute noise that makes scrolling in the web > interface more tedious. > > We will likely close this, at least for now, because there is currently no > basis for action on our part. > > 1. From years of experience with such reports, we can be fairly certain > that the problem is with the third party extension code. It is known that > such code can crash CPython if it misuses the C API. We cannot prevent that > without adding unacceptible overhead. > > 2. If there is a bug in CPython, then to do anything, we would need either > Python code or proper C code that causes the crash. The latter would likely > require cooperation of the Solidoodle extension authors. > > For us to do anything, we need evidence in the form of (minimal) code we > can run that there is a CPython bug. > > Retrying under OS X is a good idea. > > You could try testing the windows python installation with the test suite > (python -m test.regrtest in a command window) but there are two problems > when doing this with a user installation, as opposed to the test buildbots: > there will be (expected) error boxes that you have to dismiss by hitting > ; and there will be a few reported errors that are not really errors > in python itself. > > -- > nosy: +pitrou, terry.reedy > title: Fatal Python Error -> Fatal Python error: PyEval_RestoreThread: > NULL tstate > versions: +Python 2.7 > > ___ > Python tracker > <http://bugs.python.org/issue16749> > ___ > -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue16749> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16749] Fatal Python error: PyEval_RestoreThread: NULL tstate
Leonardo DaVinci added the comment: Actually Antoine, Solidoodle has sent 2 email replies, 1 was a video link to some British guy opening his box which wasn't packed like mine and had missing parts. and the second email was just as useless stating that maybe I'm running both platforms at the same time which I ain't... In any case I went ahead and booked my appointment, I just want it to work. Thanks for your time. Happy Holidays! Best Regards Ciro On Fri, Dec 28, 2012 at 7:15 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > I've tried installing on Mac at least 6 times and I still get error > > messages. I'm dealing with Solidoodle with no success. > > > > I have an appointment with a 3d Print Lab on Jan 3rd (50 miles away) to > > help me resolve my issues. > > Ciro, it seems you should wait a bit for Solidoodle's answer if you > asked them a question. I don't know about them, but if they're a > volunteer-run project you can't expect them to answer all requests very > quickly. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue16749> > ___ > -- ___ Python tracker <http://bugs.python.org/issue16749> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)
New submission from Leonardo Santagada : Python 2.6.2 (and the maint branch if using old mimetypes.py) crash (with a bus error) on mac os x (10.5.7 & 10.5.8) with the file I posted. The problem appears to be in the allocation of memory by the GC. What I do is I call mimetypes.guess_type in more than one thread at the same time, then I guess what is happening is this: 1. The first thread to run notices mimetypes.inited is false so it call its init funtion. 2. Somehow the first thread loses the gil while still executing the init 3. Another thread tries to execute guess_type as it is already inited it calls itself, in vain as the init still hasn't exchanged it value for the new function so it goes into recursion 4. Somehow the allocator fails during the recursion here is the final pieces of my stack trace (its a very long sequence of recursions into guess_type): Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0xbffc [Switching to process 61544 thread 0x117] 0x96912122 in szone_malloc () #0 0x96912122 in szone_malloc () #1 0x969120d8 in malloc_zone_malloc () #2 0x9691206c in malloc () #3 0x0006f32c in PyObject_Malloc (nbytes=376) at Objects/obmalloc.c:913 913 return (void *)malloc(nbytes); #4 0x0006fe61 in _PyObject_DebugMalloc (nbytes=360) at Objects/obmalloc.c:1347 1347p = (uchar *)PyObject_Malloc(total); #5 0x00149b13 in _PyObject_GC_Malloc (basicsize=344) at Modules/gcmodule.c:1351 1351g = (PyGC_Head *)PyObject_MALLOC( #6 0x00149c24 in _PyObject_GC_NewVar (tp=0x193500, nitems=5) at Modules/gcmodule.c:1383 1383PyVarObject *op = (PyVarObject *) _PyObject_GC_Malloc(size); #7 0x00048a06 in PyFrame_New (tstate=0x33df30, code=0x473148, globals=0x48e380, locals=0x0) at Objects/frameobject.c:642 642 f = PyObject_GC_NewVar(PyFrameObject, &PyFrame_Type, #8 0x00100816 in PyEval_EvalCodeEx (co=0x473148, globals=0x48e380, locals=0x0, args=0x374fb4, argcount=2, kws=0x374fbc, kwcount=0, defs=0x4a6f9c, defcount=1, closure=0x0) at Python/ceval.c:2755 2755f = PyFrame_New(tstate, co, globals, locals); -- components: Interpreter Core messages: 91876 nosy: santagada severity: normal status: open title: Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc) type: crash versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6763> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)
Leonardo Santagada added the comment: Well, the mimetypes module from 2.6 maintenance branch make this problem not show up with mimetypes.guess_type, but I still think this is a bug because pure python code should not crash the interpreter right? I'm attaching the file I mentioned, I hope this counts as a test (it needs the mimetypes module from python 2.6.2). I can probably extract just the needed functions from the old mimetypes module if requested. -- Added file: http://bugs.python.org/file14774/threadboom.py ___ Python tracker <http://bugs.python.org/issue6763> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)
Leonardo Santagada added the comment: I'm on os x 10.6 where threadboom.py doesn't segfault anymore at least on the system provided python. The problem that I see is that it shouldn't be segfaulting on mac os x 10.5 with the default recursion limit (I think it is 1000) with 2 threads. IIRC in a simple recursive function (not on object __init__ like you did) I could put 1 or more as a recursion limit and still get a traceback, so I thought that 2 threads each with 1000 recursion limit should not be using the whole stack. Also I think I did try to raise the stack limit with ulimit, but I could be wrong. Nick Coghlan, did you do your experments on os x 10.5? Can you try threadboom.py on a python before the corrected mimetype lib landed (somewhere between 2.6.2 and 2.6.3) or with an old version of the mimetype lib? I got the same errors both on my old white macbook core duo machine and with a macbook pro core 2 duo and with both python 2.6.2 or 2.6.3 with the old mimetypes lib. I was worried with this bug because I guessed that maybe there is a race condition of some sort on object creation on python 2.6. If someone can reproduce the bug and understand the bug tell me it is a problem of stack size I would rest my case and be happy with the segfault :). ps: I will try to compile python2.6.2 here and reproduce the errors, if I can I will reply with more info. -- ___ Python tracker <http://bugs.python.org/issue6763> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24304] Documentation broken link to license
New submission from Leonardo Tada: In this page https://docs.python.org/3.4/faq/general.html#are-there-copyright-restrictions-on-the-use-of-python the link for "the PSF license page" is broken. -- assignee: docs@python components: Documentation messages: 244217 nosy: Leonardo Tada, docs@python priority: normal severity: normal status: open title: Documentation broken link to license ___ Python tracker <http://bugs.python.org/issue24304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26110] Speedup method calls 1.2x
Changes by Leonardo Santagada : -- nosy: +santagada ___ Python tracker <http://bugs.python.org/issue26110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23516] requests: parse_url() mishandles special characters when the URL specifies authentication credentials
New submission from Leonardo Tancredi:
I was running pip install with the --proxy switch to authenticate to a proxy
server with user "user" and password "pass?word", when I noticed it fails. It
seems to fail when the password contains some special characters, v.g., ? and #.
Here's the exception I saw:
Exception:
Traceback (most recent call last):
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/basecommand.py",
line 232, in main
status = self.run(options, args)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/commands/install.py",
line 339, in run
requirement_set.prepare_files(finder)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/req/req_set.py",
line 333, in prepare_files
upgrade=self.upgrade,
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/index.py", line
305, in find_requirement
page = self._get_page(main_index_url, req)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/index.py", line
783, in _get_page
return HTMLPage.get_page(link, req, session=self.session)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/index.py", line
872, in get_page
"Cache-Control": "max-age=600",
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/sessions.py",
line 473, in get
return self.request('GET', url, **kwargs)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/download.py",
line 365, in request
return super(PipSession, self).request(method, url, *args, **kwargs)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/sessions.py",
line 461, in request
resp = self.send(prep, **send_kwargs)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/sessions.py",
line 573, in send
r = adapter.send(request, **kwargs)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/cachecontrol/adapter.py",
line 43, in send
resp = super(CacheControlAdapter, self).send(request, **kw)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/adapters.py",
line 337, in send
conn = self.get_connection(request.url, proxies)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/adapters.py",
line 245, in get_connection
proxy_manager = self.proxy_manager_for(proxy)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/adapters.py",
line 155, in proxy_manager_for
**proxy_kwargs)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/packages/urllib3/poolmanager.py",
line 265, in proxy_from_url
return ProxyManager(proxy_url=url, **kw)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/packages/urllib3/poolmanager.py",
line 210, in __init__
proxy = parse_url(proxy_url)
File
"/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/packages/urllib3/util/url.py",
line 185, in parse_url
raise LocationParseError(url)
pip._vendor.requests.packages.urllib3.exceptions.LocationParseError: Failed
to parse: user:pass
AFAICT the problem lies in function parse_url() in url.py because it assumes
that there cannot exist neither a ? nor a # between the :// and the next / .
This does not hold, because a URL can include a username and a password right
there, as in http://user:pass?word@host/path. Here's the offending piece of
code:
if '://' in url:
scheme, url = url.split('://', 1)
# Find the earliest Authority Terminator
# (http://tools.ietf.org/html/rfc3986#section-3.2)
url, path_, delim = split_first(url, ['/', '?', '#'])
It's funny that this snippet violates precisely the specification given in that
comment (RFC3986 section 3.2), because it clearly states that this string can
contain a userinfo field:
authority = [ userinfo "@" ] host [ ":" port ]
For some reason, urlencoding the password did not help either, the error
message did not change.
--
components: Extension Modules
messages: 236550
nosy: leotan
priority: normal
severity: normal
status: open
title: requests: parse_url() mishandles special characters when the URL
specifies authentication credentials
type: behavior
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue23516>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22038] Implement atomic operations on non-x86 platforms
Changes by Leonardo Bianconi : -- nosy: +lbianc ___ Python tracker <http://bugs.python.org/issue22038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23644] swig compile fails with ‘_Atomic’ does not name a type
Changes by Leonardo Bianconi : -- nosy: +lbianc ___ Python tracker <http://bugs.python.org/issue23644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23644] g++ module compile fails with ‘_Atomic’ does not name a type
Leonardo Bianconi added the comment:
@haypo
For adding compatibility for atomics based on @Joshua.J.Cogliati change, I
propose:
#ifndef Py_LIMITED_API
#ifndef Py_ATOMIC_H
#define Py_ATOMIC_H
#include "dynamic_annotations.h"
#include "pyconfig.h"
#if defined(HAVE_STD_ATOMIC)
#ifdef __cplusplus
#include
#define _Atomic(T) atomic
using namespace std;
#else
#include
#endif
#endif
#ifdef __cplusplus
extern "C" {
#endif
/* This is modeled after the atomics interface from C1x, according to
* the draft at
* http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1425.pdf.
* Operations and types are named the same except with a _Py_ prefix
* and have the same semantics.
*
* Beware, the implementations here are deep magic.
*/
#if defined(HAVE_STD_ATOMIC)
typedef enum _Py_memory_order {
_Py_memory_order_relaxed = memory_order_relaxed,
_Py_memory_order_acquire = memory_order_acquire,
_Py_memory_order_release = memory_order_release,
_Py_memory_order_acq_rel = memory_order_acq_rel,
_Py_memory_order_seq_cst = memory_order_seq_cst
} _Py_memory_order;
typedef struct _Py_atomic_address {
_Atomic (void) *_value;
} _Py_atomic_address;
typedef struct _Py_atomic_int {
atomic_int _value;
} _Py_atomic_int;
... (rest same)
--
keywords: +patch
Added file: http://bugs.python.org/file38508/atomicfix.patch
___
Python tracker
<http://bugs.python.org/issue23644>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23644] g++ module compile fails with ‘_Atomic’ does not name a type
Leonardo Bianconi added the comment:
> #define _Atomic(T) std::atomic
Does not work, since there are definitions like "memory_order_relaxed" that are
in std.
I tested the other one, and it works fine:
>#ifdef __cplusplus
>extern "C" {
>#if defined(HAVE_STD_ATOMIC)
>using namespace std;
>#endif
>#endif
@haypo, what do you think?
--
___
Python tracker
<http://bugs.python.org/issue23644>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30464] gammavariate has a wrong comment
New submission from Leonardo De Marchi: The gammavariate function in random.py has a wrong comment. It says that when alpha is one it's equivalent to call expovariate(1). We can see that is not true (see graphs) and it should be expovariate(1/beta). It's not a big deal but it can cause confusion. -- files: unnamed.png messages: 294403 nosy: leodema priority: normal severity: normal status: open title: gammavariate has a wrong comment Added file: http://bugs.python.org/file46895/unnamed.png ___ Python tracker <http://bugs.python.org/issue30464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30464] gammavariate has a wrong comment
Changes by Leonardo De Marchi : -- pull_requests: +1896 ___ Python tracker <http://bugs.python.org/issue30464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30561] sync-up gammavariate and expovariate code
New submission from Leonardo De Marchi: As suggested by rhettinger in http://bugs.python.org/msg294438: I agree that the comment should be changed. While we at it, perhaps sync-up with expovariate() code and eliminate the ``u <= 1e-7`` test: Instead of: elif alpha == 1.0: # expovariate(1) u = random() while u <= 1e-7: u = random() return -_log(u) * beta Use this instead: elif alpha == 1.0: # expovariate(1.0 / beta) return -_log(1.0 - random()) * beta -- messages: 295102 nosy: leodema priority: normal severity: normal status: open title: sync-up gammavariate and expovariate code type: performance ___ Python tracker <http://bugs.python.org/issue30561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30561] sync-up gammavariate and expovariate code
Changes by Leonardo De Marchi : -- pull_requests: +2011 ___ Python tracker <http://bugs.python.org/issue30561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30464] gammavariate has a wrong comment
Changes by Leonardo De Marchi : -- pull_requests: +2012 ___ Python tracker <http://bugs.python.org/issue30464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30561] sync-up gammavariate and expovariate code
Changes by Leonardo De Marchi : -- pull_requests: +2014 ___ Python tracker <http://bugs.python.org/issue30561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7535] logging: Filters on Loggers can't actually filter messages on lower levels of the logging hierarchy
New submission from Leonardo Rochael Almeida :
A filter added to, say, logging.getLogger('a').addFilter() never gets
the chance to filter messages logged into logging.getLogger('a.b').
On logging.Logger.handle() the current logger filters are called to
check if the message should be processed or not, but the logger parent
filters are not consulted (and this is ok, IMHO, more generic filters
shouldn't clobber messages of more specific loggers).
However, if none of the current filters block the message,
Logger.handle() then calls Logger.callHandlers(), which calls the
handlers of the current logger and of all the parent loggers as long as
each logger in the hierarchy allows the message to propagate. This is
done without consulting the parent loggers filters.
This means parent handlers get called to process log records even if the
parent logger filters would have otherwise blocked them.
Attached is a very crude patch that allows the parent loggers to filter
events before handling them. I'd prefer to simply call the "handle()"
or "callHandler()" method of the parent loggers recursively, but
couldn't find a way to do this while still preserving the method
signatures AND properly reporting when no handler could be found.
My preference would be to have callHandlers() do the filtering AND
return a number of handlers invoked, including the parent handlers, so
that handle() could report if no handlers could be found.
--
components: Library (Lib)
files: logging-allow-parent-filtering.diff
keywords: patch
messages: 96524
nosy: leorochael
severity: normal
status: open
title: logging: Filters on Loggers can't actually filter messages on lower
levels of the logging hierarchy
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15583/logging-allow-parent-filtering.diff
___
Python tracker
<http://bugs.python.org/issue7535>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7535] logging: Filters on Loggers can't actually filter messages on lower levels of the logging hierarchy
Leonardo Rochael Almeida added the comment: At the very least this is a documentation bug. By reading the std docs on the logging module [1] one gets the impression that if a log record gets to a certain logger, even if percolated from more specific loggers, then the filters to that logger should be involved and even get the chance to change the log record. [1] http://docs.python.org/library/logging.html This is reinforced by the documentation and the implementation of the logging.Filter class, which is supposed to filter-out messages of more specific loggers, but which would never actually filter out anything if applied to a Logger of the same "name" (as opposed to a Handler, since filter handlers do get called for log records of more specific loggers). -- ___ Python tracker <http://bugs.python.org/issue7535> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
