[issue43542] Add image/heif(heic) to list of media types in mimetypes.py
New submission from Ilya : Add HEIF and HEIC format to list of media types. It has IANA registration. IANA: https://www.iana.org/assignments/media-types/image/heic HEIF Github: https://github.com/nokiatech/heif -- components: Library (Lib) messages: 389012 nosy: martbln priority: normal severity: normal status: open title: Add image/heif(heic) to list of media types in mimetypes.py type: enhancement ___ Python tracker <https://bugs.python.org/issue43542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43542] Add image/heif(heic) to list of media types in mimetypes.py
Change by Ilya : -- keywords: +patch pull_requests: +23680 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24917 ___ Python tracker <https://bugs.python.org/issue43542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39202] Python shelve __del__ ignored exception
New submission from Ilya : I'm using my own implementation of the memoize by shelve module. In the attachment, there are 2 simple test cases which pass but the console there are a lot of messages like that: Exception ignored in: Traceback (most recent call last): File "C:\Miniconda2\envs\38_common\lib\shelve.py", line 162, in __del__ self.close() File "C:\Miniconda2\envs\38_common\lib\shelve.py", line 144, in close self.sync() File "C:\Miniconda2\envs\38_common\lib\shelve.py", line 172, in sync self.dict.sync() File "C:\Miniconda2\envs\38_common\lib\dbm\dumb.py", line 129, in _commit with self._io.open(self._dirfile, 'w', encoding="Latin-1") as f: PermissionError: [Errno 13] Permission denied: 'C:\\project\\tests\\test_memoize_tmp_t5tai08p\\memoize_test_file.dat.dir' Exception ignored in: Traceback (most recent call last): File "C:\Miniconda2\envs\38_common\lib\dbm\dumb.py", line 274, in close self._commit() File "C:\Miniconda2\envs\38_common\lib\dbm\dumb.py", line 129, in _commit with self._io.open(self._dirfile, 'w', encoding="Latin-1") as f: PermissionError: [Errno 13] Permission denied: 'C:\\project\\tests\\test_memoize_tmp_t5tai08p\\memoize_test_file.dat.dir' Basically, the main issue can be explained like that - Python dbm.dumb._Database should maintain self._modified the attribute in the right way(set it to False) after the _commit method. Later I will try to make changes in the dbm.dumb module and run Python internal tests for that modification to see any regression, if not will add PR here. -- components: Library (Lib) files: test_python_shelve_issue.py messages: 359242 nosy: libbkmz priority: normal severity: normal status: open title: Python shelve __del__ ignored exception type: enhancement versions: Python 3.8 Added file: https://bugs.python.org/file48826/test_python_shelve_issue.py ___ Python tracker <https://bugs.python.org/issue39202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39670] 2to3 fix_apply tries to fix user-defined apply function calls
New submission from ilya : Consider the following code: def apply(a, b): print(a) print(b) apply(1, 1) 2to3 suggests to fix it as follows: --- a.py(original) +++ a.py(refactored) @@ -2,4 +2,4 @@ print(a) print(b) -apply(1, 1) +(1)(*1) -- components: 2to3 (2.x to 3.x conversion tool) messages: 362178 nosy: ilya priority: normal severity: normal status: open title: 2to3 fix_apply tries to fix user-defined apply function calls type: behavior ___ Python tracker <https://bugs.python.org/issue39670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39670] 2to3 fix_apply tries to fix user-defined apply function calls
ilya added the comment: > apply was a builtin in Python 2 and not sure 2to3 can differentiate between > user defined functions that shadow builtins. > https://docs.python.org/3.8/library/2to3.html#2to3fixer-apply . > Removes usage of apply(). For example apply(function, *args, **kwargs) is > converted to function(*args, **kwargs). > You can skip the apply fixer: 2to3 -x apply /tmp/bar.py The problem is that the code is valid both for Python2 and Python3 (for Python3, there is even no builtin shadowing, because there is no apply builtin actually), and fix_apply breaks it. I'm testing the quality of 2to3 fixers and found this issue. I know that it's possible to switch this fixer off, but it doesn't seem to be a proper solution because any other bug could have the same answer. -- ___ Python tracker <https://bugs.python.org/issue39670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39683] 2to3 fix_exitfunc suggests duplicated import of atexit module
New submission from ilya :
Consider the following code:
import sys
def foo():
print(1)
def bar():
print(2)
if input("case: ") == 1:
sys.exitfunc = foo
else:
sys.exitfunc = bar
2to3 -f exitfunc suggests to fix it as follows:
--- a.py(original)
+++ a.py(refactored)
@@ -1,4 +1,6 @@
import sys
+import atexit
+import atexit
def foo():
print(1)
@@ -7,6 +9,6 @@
print(2)
if input("case: ") == 1:
-sys.exitfunc = foo
+atexit.register(foo)
else:
-sys.exitfunc = bar
+atexit.register(bar)
So it seems that it produces one import of atexit module per each use of
sys.exitfunc.
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 362245
nosy: ilya
priority: normal
severity: normal
status: open
title: 2to3 fix_exitfunc suggests duplicated import of atexit module
type: behavior
___
Python tracker
<https://bugs.python.org/issue39683>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6869] Embedded python crashed on 4th run, if "ctypes" is used
New submission from Ilya :
When embedding python from C, and importing "ctypes" module in embedded
script, it always crashes on Py_Finalize() on 4th cycle.
Tested with both PyRun_SimpleString(...) and PyRun_String(...).
Platform: Windows XP
IDE's: LabWindows/CVI 8.5 and Code::Blocks/gcc
Code:
--
#include
#include
int main()
{
int i;
for (i=0; i<10; i++)
{
printf("--- %d ---\n", i);
Py_Initialize();
PyRun_SimpleString("import ctypes");
Py_Finalize();
}
return 0;
}
Output:
--- 0 ---
--- 1 ---
--- 2 ---
--- 3 ---
Process returned -1073741819 (0xC005) execution time : 3.109 s
Press any key to continue.
--
assignee: theller
components: ctypes
messages: 92444
nosy: Warlock, theller
severity: normal
status: open
title: Embedded python crashed on 4th run, if "ctypes" is used
type: crash
versions: Python 2.5, Python 2.6
___
Python tracker
<http://bugs.python.org/issue6869>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6869] Embedded python crashed on 4th run, if "ctypes" is used
Ilya added the comment:
Tested
obj=PyImport_ImportModule("ctypes");
Py_DECREF(obj);
instead of PyRun_SimpleString(...) - same result
--
___
Python tracker
<http://bugs.python.org/issue6869>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43424] Document the `controller.name` field in `webbrowser` module
Ilya Grigoriev added the comment: Thank you very much, Nikita! Your patch would certainly solve my issue. As is, I checked the code I wrote, and it seems that only a lucky ordering of if-statements caused it to work on Macs. Ilya. On Wed, Dec 29, 2021 at 5:30 PM Dong-hee Na wrote: > > > Dong-hee Na added the comment: > > > New changeset d12bec69931503be78cd555cf7bc22ad6f4f2bd5 by Nikita Sobolev in > branch 'main': > bpo-43424: Deprecate `webbrowser.MacOSXOSAScript._name` attribute (GH-30241) > https://github.com/python/cpython/commit/d12bec69931503be78cd555cf7bc22ad6f4f2bd5 > > > -- > nosy: +corona10 > > ___ > Python tracker > <https://bugs.python.org/issue43424> > ___ -- ___ Python tracker <https://bugs.python.org/issue43424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46681] gzip.compress does not forward compresslevel to zlib.compress
New submission from Ilya Leoshkevich :
Started with:
commit ea23e7820f02840368569db8082bd0ca4d59b62a
Author: Ruben Vorderman
Date: Thu Sep 2 17:02:59 2021 +0200
bpo-43613: Faster implementation of gzip.compress and gzip.decompress
(GH-27941)
Co-authored-by: Łukasz Langa
The fix is quite trivial:
--- a/Lib/gzip.py
+++ b/Lib/gzip.py
@@ -587,7 +587,8 @@ def compress(data, compresslevel=_COMPRESS_LEVEL_BEST, *,
mtime=None):
header = _create_simple_gzip_header(compresslevel, mtime)
trailer = struct.pack("
<https://bugs.python.org/issue46681>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46681] gzip.compress does not forward compresslevel to zlib.compress
Change by Ilya Leoshkevich : -- keywords: +patch pull_requests: +29385 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31215 ___ Python tracker <https://bugs.python.org/issue46681> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13341] Incorrect documentation for "u" PyArg_Parse format unit
New submission from Ilya Novoselov : Documentation states that u format unit returns "buffer of 16-bit Unicode (UTF-16) data" while it returns pointer to internal buffer of unicode data, which is either UCS-16 or UCS-32 http://docs.python.org/c-api/arg.html -- assignee: docs@python components: Documentation, Unicode messages: 147002 nosy: Ilya.Novoselov, docs@python, ezio.melotti priority: normal severity: normal status: open title: Incorrect documentation for "u" PyArg_Parse format unit type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13341> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13341] Incorrect documentation for "u" PyArg_Parse format unit
Ilya Novoselov added the comment: No, I don't feel like I'm up to standard yet. -- ___ Python tracker <http://bugs.python.org/issue13341> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13120] Default nosigint option to pdb.Pdb() prevents use in non-main thread
Ilya Sandler added the comment: I confirm the bug. But I don't think disabling Ctrl-C (SIGINT) handling by default is a good idea. Proper Ctrl-C support seems like a fundamental feature for a command line debugger. However, I think the bug is easily fixable w/o changing SIGINT handling. Basically, just put try/except around signal.signal, catch the ValueError and proceed. Would this approach solve your problem? Patch attached. PS. and here is a small program demonstrating the bug (just run it and execute "c" command at pdb prompt) import threading import pdb def start_pdb(): pdb.Pdb().set_trace() x = 1 y = 1 t = threading.Thread( target=start_pdb) t.start() -- keywords: +patch nosy: +isandler Added file: http://bugs.python.org/file23791/thread_sigint.patch ___ Python tracker <http://bugs.python.org/issue13120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13120] Default nosigint option to pdb.Pdb() prevents use in non-main thread
Ilya Sandler added the comment: I think stuff like this can only be tested out-of-process. So I added an out-of-process test to test_pdb.py. The test passes with the fixed pdb.py. (and fails with the original one). Patch for the test attached. -- Added file: http://bugs.python.org/file23796/test_pdb.py.patch ___ Python tracker <http://bugs.python.org/issue13120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10478] Ctrl-C locks up the interpreter
New submission from Ilya Sandler :
The following program is misbehaving with python3.2
import signal, time
def sighandler( arg1, arg2): print("got sigint");assert 0
signal.signal( signal.SIGINT, sighandler)
for i in range(100):
print(i)
I'd expect Ctrl-C to terminate the program with AssertionError and that's
indeed what happens under python2.7.
But with python3.2a, I get "Assertion Error" 1 out ~10 times. The other 9
times, the program locks up (goes to sleep? ps shows process status as "S").
After the program locks up, it does not respond to subsequent "Ctrl-C" presses.
This is on 64-bit Ubuntu 8.04.
--
components: Interpreter Core
messages: 121860
nosy: isandler
priority: normal
severity: normal
status: open
title: Ctrl-C locks up the interpreter
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue10478>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10478] Ctrl-C locks up the interpreter
Ilya Sandler added the comment: Would avoiding PyErr_CheckSignals() while the file object is in inconsistent state be a reasonable alternative? I am guessing that it's not that uncommon for a signal handler to need IO (e.g to log a signal). If making IO safer is not an option, then I think, this limitation needs to be documented (especially, given that this seems to be a behavior change from Python 2.x). -- ___ Python tracker <http://bugs.python.org/issue10478> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)
Ilya Sandler added the comment: The patch tries to write to stdout in signal handler. This currently does not work in the python 3.x (see http://bugs.python.org/issue10478). -- ___ Python tracker <http://bugs.python.org/issue7245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7843] python-dev archives are not updated
New submission from Ilya Sandler : http://mail.python.org/pipermail/python-dev/ archives have not been updated for a couple of weeks now. A bug? -- messages: 98775 nosy: isandler severity: normal status: open title: python-dev archives are not updated ___ Python tracker <http://bugs.python.org/issue7843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7843] python-dev archives are not updated
Ilya Sandler added the comment: As of Feb 2, 2010, archives seem to be functioning as expected ;-) -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue7843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1736483] os.popen('yes | echo hello') stuck
Ilya Sandler added the comment:
I don't think this is a bug in python (see below for analysis). Furthermore,
os.popen() is deprecated, so I think this issue can be closed.
Here is my understanding of what's happening.
When you execute :
python -c 'import sys, os; sys.stdout.write(os.popen("while :; do echo yes ;
done | echo hello").read())'
popen() forks and then execs() a /bin/sh like this
/bin/sh -c "while :; do echo yes ; done | echo hello"
But exec() (on Linux at least) inherits the signal handling from the pre-exec
process for the signals which were set to SIG_IGN or SIG_DFL (see e.g here:
http://www.gnu.org/software/libc/manual/html_node/Initial-Signal-Actions.html),
so in this case shell will inherit SIG_IGN setting from python for SIGPIPE.
Furthermore, the "sh" manpage explicitly says that shell will wait for all
processes in the pipeline.
So, the sequence of events will be as follows: echo exits, SIGPIPE is delivered
to the shell and is ignored by the shell and so the shell keeps running the
while loop forever, so .read() call never reaches the eof and your script
blocks.
The original "yes|echo" example on MacOsX has likely been caused by the same
sequence of events. (if "yes" inherits signal handling from shell, then
"yes|echo"
would not block when invoked from command line, but would block when invoked
from python)
Installling your own SIGPIPE handler (or resetting SIGPIPE to SIG_DFL as ilgiz
suggested) should work around this issue.
--
nosy: +isandler
___
Python tracker
<http://bugs.python.org/issue1736483>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed)
Ilya Sandler added the comment:
I fixed some of the style issues mentioned on appspot. (I was not sure about
some of them and responded to them in appspot comments).
Also sigHandler became sighandler for consistency with the rest of pdb.py.
The new version of the patch is attached.
However, it appears that I've been a bit over-optimistic about the lack of
side-effects. In particular, the patch results in an very ugly error message
when Ctrl-C is pressed while at pdb prompt..
*** AttributeError: AttributeError("'NoneType' object has no attribute
'f_globals'",)
Everything still seems to be working, but it's definitely ugly (and behaves
differently on Windows and Linux).
I will try to summarize possible Ctrl-C scenarios in a separate post
--
Added file: http://bugs.python.org/file16288/sig.patch.v1
___
Python tracker
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed)
Ilya Sandler added the comment:
Here is a list of Ctrl-C scenarios: ("current" below means the prepatch version
of pdb).
1. program is running (last command was "c", "n", etc). Currently, Ctrl-C
throws debugger into postmortem. Desired behavior: interrupt the program. This
is the only scenario supported by the patch.
2. Program is stopped (debugger is interacting with the user). Currently,
Ctrl-C will throw debugger into postmortem. Desired behaviour: either ignore
Ctrl-C or abandon the current command (that's what gdb does).
3. Program is stopped and pdb runs one of the commands which catch exceptions
(e.g "p"). Currently, Ctrl-C will abort the command and return pdb to the
prompt. I think this behavior should be kept.
4. Program finished (debugger is in postmortem). Currently, Ctrl-C will quit
the debugger. Desired behavior: either ignore Ctrl-C or abandon the current
command.
Essentially, I think the best behavior is to have Ctrl-C to interrupt whatever
pdb is doing and return to the fresh prompt.
I am assuming that behavior on Windows and Linux should be identical/nearly
identical.
Does the above list make sense?
I would greatly appreciate any feedback/comments/guidance/etc.
--
___
Python tracker
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8015] pdb "commands" command throws you into postmortem if you enter an empty command
New submission from Ilya Sandler : Here is a sample session: cheetah:~/comp/python/trunk> ./python ./Lib/pdb.py hello > /home/ilya/comp/python/trunk/hello(1)() -> print i (Pdb) b 1 Breakpoint 1 at /home/ilya/comp/python/trunk/hello:1 (Pdb) commands 1 (com) Traceback (most recent call last): self.cmdloop() File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 142, in cmdloop stop = self.onecmd(line) File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 273, in onecmd return cmd.Cmd.onecmd(self, line) File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 219, in onecmd return func(arg) File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 330, indo_commands self.cmdloop() File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 142, in cmdloop stop = self.onecm File "/home/ilya/comp/python/trunk/Lib/bdb.py", line 66, in dispatch_line self.user_line(frame) File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 158, in user_line self.interaction(frame, None) File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 206, in interaction d(line) File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 275, in onecmd return self.handle_command_def(line) File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 293, in handle_command_def func = getattr(self, 'do_' + cmd) TypeError: cannot concatenate 'str' and 'NoneType' objects Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program > /home/ilya/comp/python/trunk/Lib/pdb.py(293)handle_command_def() -> func = getattr(self, 'do_' + cmd) -- messages: 100057 nosy: isandler severity: normal status: open title: pdb "commands" command throws you into postmortem if you enter an empty command versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue8015> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed)
Ilya Sandler added the comment: Another iteration of the patch. Now sigint_handler will generate KeyboardInterrupts when pdb is in the commandloop I think this guarantees consistent "Ctrl-C interrupts the current pdb action" behavior and the program is still resumable. The "commands" command required a bit of special handling to unroll the changes if KbdInt happens. The patch was tested on Linux and Vista. -- Added file: http://bugs.python.org/file16384/sig.patch.v2 ___ Python tracker <http://bugs.python.org/issue7245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)
Ilya Sandler added the comment: Another version of the patch is attached ( I think, I fixed all the remaining style issues). I'll answer the testing question in a separate post -- Added file: http://bugs.python.org/file16470/sig.patch.v3 ___ Python tracker <http://bugs.python.org/issue7245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)
Ilya Sandler added the comment: new version of the patch is uploaded to bugs.python.org http://codereview.appspot.com/216067/diff/2001/2002 File Lib/pdb.py (right): http://codereview.appspot.com/216067/diff/2001/2002#newcode63 Lib/pdb.py:63: def sigint_handler(self, signum, frame): On 2010/02/28 20:12:00, gregory.p.smith wrote: > Please move this below the __init__ definition. It makes classes odd to read > when __init__ isn't the first method defined when people are looking for the > constructor to see how to use it. Done. http://codereview.appspot.com/216067/diff/2001/2002#newcode64 Lib/pdb.py:64: if self.allow_kbdint: On 2010/02/28 20:12:00, gregory.p.smith wrote: > Initialize self.allow_kdbint in __init__ so that a SIGINT coming in before > _cmdloop has run doesn't cause an AttributeError. Done. http://codereview.appspot.com/216067/diff/2001/2002#newcode215 Lib/pdb.py:215: # keyboard interrupts allow for an easy way to interrupt On 2010/02/28 20:12:00, gregory.p.smith wrote: > "to cancel the current command" I changed the wording a bit, should be ok now. http://codereview.appspot.com/216067/diff/2001/2002#newcode356 Lib/pdb.py:356: #it appears that that when pdb is reading input from a pipe On 2010/02/28 20:12:00, gregory.p.smith wrote: > Space after the # please. this code > is? particular > interrupted command from the list of commands to run at the current breakpoint > but I may be misreading things as I haven't spent much time in pdb.py. Done. I've also added a comment to explain what's going on. http://codereview.appspot.com/216067/show -- ___ Python tracker <http://bugs.python.org/issue7245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)
Ilya Sandler added the comment:
> Also, can you take a look at how the pdb unittests work and see if you
can come up with a way to unittest the KeyboardInterrupt behavior?
Yes, this is doable. In fact, I already have such tests written (unix only
though). The tests are assert based but it should not be difficult to convert
them to unittest. Moreover, I have many more tests for pdb written in the same
style.
However, these tests are not easily (and possibly not at all) integratable with
existing test_pdb.py module. (See below for the problems). So would it be
acceptable to have these tests as a separate module (test_pdb2.py or some
such)? (I might also need some help with integrating the module)
Background
--
Here is the basic problem: testing/debugging a debugger is hard by itself (you
need to deal with 2 programs at once: the one being debugged and the debugger
which run intermittently), now throw in doctest and it becomes much harder (as
everything you do now gets covered by another layer). And now we need to test
signals and some of the tests will likely be platform specific which makes it
even worse.
In contrast, in my tests the snippets of code are written into a tmp file and
then are fed into debugger, the debugger itself is run as a subprocess. So if a
test fails, it can be easily rerun under debugger manually and you can test
for things like pdb exits and stalls.
Here is a snippet from my pdb tests (just to give an idea how they would look
like: essentially, send a command to pdb, check the response).
pdb=PdbTester("pdb_t_hello","""\
import time
for i in xrange(1):
time.sleep(0.05)
""")
pdb.pdbHandle.stdin.write("c\n")
time.sleep(0.01)
#pdb_t_hello running, try to interrupt it
pdb.pdbHandle.send_signal(signal.SIGINT)
pdb.waitForPrompt()
pdb.queryAndMatch("p i", "0")
pdb.query("n")
pdb.query("n")
pdb.queryAndMatch("p i", "1")
pdb.query("s")
pdb.query("s")
pdb.queryAndMatch("p i","2")
pdb.pdbHandle.stdin.write("c\n")
time.sleep(0.03)
pdb.pdbHandle.send_signal(signal.SIGINT)
pdb.waitForPrompt()
pdb.queryAndMatch("p i","3")
--
___
Python tracker
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)
Ilya Sandler added the comment: I'm attaching a test for Ctrl-C behavior on Linux (the patch itself works on Windows too, but I am not sure how to send Ctrl-C on windows programatically and subprocess does not have this functionality either). The test_pdb2.py module is generic and can be extended to test other functionality. But, as discussed earlier, it cannot be easily (if at all) integrated into existing test_pdb.py. Note that the test module will NOT work with existing pdb (as it doesnot have expected Ctrl-C) behavior, but on can specify alternative pdb location from command line: env DEBUG_PDB=./pdb.py ./test_pdb2.py -- Added file: http://bugs.python.org/file16619/test_pdb2.py ___ Python tracker <http://bugs.python.org/issue7245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)
Ilya Sandler added the comment: Is there anything else I can do for this patch? -- ___ Python tracker <http://bugs.python.org/issue7245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8309] Sin(x) is Wrong
Ilya Sandler added the comment:
I believe python is fully at mercy of underlying system math library.
And as a matter of fact, this C program
#include
#include
main() { printf("%.6f\n", sin(1e22)); }
when compiled as 64-bit app (on linux) produces "-0.852201", but when it's
compiled as a 32-bit app on the same machine (gcc -m32), it produces "0.462613".
So I don't think this is a bug in python.
--
nosy: +isandler
___
Python tracker
<http://bugs.python.org/issue8309>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)
Ilya Sandler added the comment: a note on testing: it should be possible to integrate the tests into existing test_pdb.py by simply placing subprocess based tests next to doctest-based tests. This way pdb tests will at least be in a single module. (this is an approach taken by a patch in http://bugs.python.org/issue7964) Would it be better? -- ___ Python tracker <http://bugs.python.org/issue7245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2059] OptionMenu class is defined both in Tkinter and Tix
New submission from Ilya Sandler: Given that Tix imports all names from Tkinter this is likely to result in confusion. E.g. >>> from Tix import * >>> print Button Tkinter.Button >>> print OptionMenu Tix.OptionMenu To get to Tkinter's OptionMenu, one needs to do something like import Tkinter Tkinter.OptionMenu -- components: Library (Lib) messages: 62250 nosy: isandler severity: normal status: open title: OptionMenu class is defined both in Tkinter and Tix type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2059> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2059] OptionMenu class is defined both in Tkinter and Tix
Ilya Sandler added the comment: I understand your argument. Yet, I am not sure classes with the same name are reasonable here. Tix is too intertwined with Tkinter: E.g a Tix user user can just access Tkinter widgets via Tix: >>> import Tix >>> print Tix.Canvas # This is TkInter's widget Tkinter.Canvas >> import Tix.ComboBox #whoops, we've got Tix's combobox Tix.ComboBox As a matter of fact, Tix docs seem to explicitly recommend accessing Tkinter stuff through Tix: """The former imports the latter, so to use Tix with Tkinter, all you need to do is to import one module. In general, you can just import Tix, and replace the toplevel call to Tkinter.Tk with Tix.Tk""" __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2059> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35748] urlparse library detecting wrong hostname leads to open redirect vulnerability
Ilya Konstantinov added the comment:
>From RFC-1738:
hostname = *[ domainlabel "." ] toplabel
domainlabel= alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit
alphadigit = alpha | digit
However:
py> urlparse('https://foo\\bar/baz')
ParseResult(scheme='https', netloc='foo\\bar', path='/baz', params='',
query='', fragment='')
The hostname's BNF doesn't allow for a backslash ('\\') character, so I'd
expect urlparse to raise a ValueError for this "URL".
--
nosy: +Ilya Konstantinov
___
Python tracker
<https://bugs.python.org/issue35748>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38039] Segfault when pickling dictionary with large pandas dataframes
New submission from Ilya Valmianski : Tried pickling a dictionary with multiple pandas tables and python primitive types. Pandas tables are large so full object size is ~200GB but system should not be OOM (crashed with ~300 GB system memory available). Reproduced on two machines running RHEL 7.5. Tried using Python 3.6 and 3.7. Tried pickle and dill. All python versions were installed as environments via Anaconda. All segfault in pickle. Here is a dump: Fatal Python error: Segmentation fault Current thread 0x7f724af23740 (most recent call first): File "/apps/anaconda3/lib/python3.6/pickle.py", line 496 in save File "/apps/anaconda3/lib/python3.6/pickle.py", line 805 in _batch_appends File "/apps/anaconda3/lib/python3.6/pickle.py", line 781 in save_list File "/apps/anaconda3/lib/python3.6/pickle.py", line 476 in save File "/apps/anaconda3/lib/python3.6/pickle.py", line 751 in save_tuple File "/apps/anaconda3/lib/python3.6/pickle.py", line 476 in save File "/apps/anaconda3/lib/python3.6/pickle.py", line 634 in save_reduce File "/apps/anaconda3/lib/python3.6/pickle.py", line 521 in save File "/apps/anaconda3/lib/python3.6/pickle.py", line 847 in _batch_setitems File "/apps/anaconda3/lib/python3.6/pickle.py", line 821 in save_dict File "/apps/anaconda3/lib/python3.6/site-packages/dill/_dill.py", line 893 in save_module_dict File "/apps/anaconda3/lib/python3.6/pickle.py", line 476 in save File "/apps/anaconda3/lib/python3.6/pickle.py", line 634 in save_reduce File "/apps/anaconda3/lib/python3.6/pickle.py", line 521 in save File "/apps/anaconda3/lib/python3.6/pickle.py", line 847 in _batch_setitems File "/apps/anaconda3/lib/python3.6/pickle.py", line 821 in save_dict File "/apps/anaconda3/lib/python3.6/site-packages/dill/_dill.py", line 893 in save_module_dict File "/apps/anaconda3/lib/python3.6/pickle.py", line 476 in save File "/apps/anaconda3/lib/python3.6/pickle.py", line 409 in dump File "/apps/anaconda3/lib/python3.6/site-packages/dill/_dill.py", line 286 in dump File "precompute_control_patients.py", line 220 in main File "/apps/anaconda3/lib/python3.6/site-packages/absl/app.py", line 251 in _run_main File "/apps/anaconda3/lib/python3.6/site-packages/absl/app.py", line 300 in run File "precompute_control_patients.py", line 227 in -- messages: 351213 nosy: Ilya Valmianski priority: normal severity: normal status: open title: Segfault when pickling dictionary with large pandas dataframes type: crash versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue38039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38039] Segfault when pickling dictionary with large pandas dataframes
Ilya Valmianski added the comment:
Below is the code. It segfaults with either dill or pickle on 3.6 and 3.7.
with open(output_path,'wb') as fout:
dill.dump({
'timed_dfs': timed_dfs, #large pandas
dataframe with all but one columns being strings, one column is datetime
'notime_dfs' : notime_dfs, #large pandas
dataframe with all elements being strings
'control_features' : control_features,#dictionary of
lists of 3 element tuples of strings
'config' : config, #small-ish
dictionary with ints, strings, and lists of int/str
'version' : __VERSION__ #string
},
fout,
protocol=4)
--
___
Python tracker
<https://bugs.python.org/issue38039>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38039] Segfault when pickling dictionary with large pandas dataframes
Ilya Valmianski added the comment: As a sizing clarification, timed_dfs ~ 150GB, control_features ~30 GB, notime_dfs ~ 2GB. -- ___ Python tracker <https://bugs.python.org/issue38039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38131] compile(mode='eval') uninformative error message
New submission from Ilya Kamenshchikov : While trying to construct a valid ast node programmatically, I have tried following: import ast tree = ast.BinOp(left=ast.Num(n=2), right=ast.Num(n=2), op=ast.Add()) expr = ast.Expression(body=[tree]) ast.fix_missing_locations(expr) exe = compile(expr, filename="", mode="eval") print(eval(exe)) Unfortunately this gives unhelpful error message: >>>exe = compile(expr, filename="", mode="eval") TypeError: required field "lineno" missing from expr Turns out I need to make body of ast.Expression not a list, but a node: expr = ast.Expression(body=tree) # works Confusion also comes from naming the field "body", which takes value of a list for ast.Module and some others. -- components: Library (Lib) messages: 352090 nosy: Ilya Kamenshchikov priority: normal severity: normal status: open title: compile(mode='eval') uninformative error message versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue38131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43670] Typo in 3.10 changelog
New submission from Ilya Gruzinov :
In next lines typo in function `load`:
# BUG: "rb" mode or encoding="utf-8" should be used.
with open("data.json") as f:
data = json.laod(f)
--
assignee: docs@python
components: Documentation
messages: 389825
nosy: docs@python, shagren
priority: normal
pull_requests: 23843
severity: normal
status: open
title: Typo in 3.10 changelog
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue43670>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
Change by Ilya Kulakov : -- pull_requests: +16640 pull_request: https://github.com/python/cpython/pull/17130 ___ Python tracker <https://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26467] Add async magic method support to unittest.mock.Mock
Change by Ilya Kulakov : -- pull_requests: +16639 pull_request: https://github.com/python/cpython/pull/17130 ___ Python tracker <https://bugs.python.org/issue26467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17013] Allow waiting on a mock
Change by Ilya Kulakov : -- pull_requests: +16643 pull_request: https://github.com/python/cpython/pull/17133 ___ Python tracker <https://bugs.python.org/issue17013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17013] Allow waiting on a mock
Ilya Kulakov added the comment: I have submitted an alternative implementation of this feature heavily inspired by _AwaitEvent I wrote for asynctest [0]. There was recently an interest from the community towards asynctest to the point that got some of its measures merged into CPython [1]. The key features of my implementation [2]: - Gives meaning to the existing Mock.called property, otherwise not much useful - Does not require end users to do anything: change is automatically available in every Mock (and any subclass of mock that does not override `called`) - Use of conditionals provides API that allows much richer extension: instead of hardcoding conditions as events it allows to wait until arbitrary predicate becomes true - Utilizes existing semantics of python conditionals (both asyncio and threading) Accepting this PR will allow me to bring _AwaitEvent thereby completing mock.py with waiting mechanics with identical semantics for both threading-based and asyncio-based cases. 0: https://github.com/Martiusweb/asynctest/blob/4b1284d6bab1ae90a6e8d88b882413ebbb7e5dce/asynctest/mock.py#L428 1: https://github.com/python/cpython/pull/9296 2: https://github.com/python/cpython/pull/17133 -- nosy: +Kentzo ___ Python tracker <https://bugs.python.org/issue17013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39626] random choice to delegate to sample on sets
New submission from Ilya Kamenshchikov : In a few of my projects I had this (minor) pain of having to remember which collections of elements are sets and which are [list, tuple]. It causes me to double check and have random.sample(my_set, 1)[0] in many places. To me this is not how I think and causes friction: conceptually, I know something is a collection and I want 1 random choice from it. Having to differentiate on sequences vs sets makes my code uglier :( This issue is similar to https://bugs.python.org/issue37708. -- components: Library (Lib) messages: 361954 nosy: Ilya Kamenshchikov priority: normal severity: normal status: open title: random choice to delegate to sample on sets ___ Python tracker <https://bugs.python.org/issue39626> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39760] ast.FormattedValue.format_spec unnecessarily wrapped in JoinedStr
New submission from Ilya Kamenshchikov :
Most usual usecase for format_spec is to specify it as a constant, that would
be logical to represent as ast.Constant. However, ast.parse wraps value of
ast.FormattedValue.format_spec into a JoinedStr with a single constant value,
as can be seen from example below:
import ast
code = '''f"is {x:d}"'''
tree = ast.parse(code)
for n in ast.walk(tree):
if isinstance(n, ast.FormattedValue):
print(
type(n.format_spec),
len(n.format_spec.values),
set(type(v) for v in n.format_spec.values),
)
This is confusing for programmatically analyzing the ast, and likely creates
some overhead in any modules using ast and FormattedValue.
Proposal: represent ast.FormattedValue.format_spec as ast.Constant in most
cases.
--
components: Library (Lib)
messages: 362691
nosy: Ilya Kamenshchikov
priority: normal
severity: normal
status: open
title: ast.FormattedValue.format_spec unnecessarily wrapped in JoinedStr
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue39760>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42943] singledispatchmethod should expose registry of all known overloads
New submission from Ilya Kulakov : The wrapper created by singledispatchmethod does not (trivially) expose registry of all known overloads. Consider the following example: @singledispatchmethod def on_message(message): raise NotImplementedError @on_message.register def _(message: MessageA): ... @on_message.register def _(message: MessageB): ... loop = ... condition = ... messages = [] def receive_message_on_thread(message): if ...: # only signal to asyncio if message can be handled messages.append(message) loop.call_soon_threadsafe(condition.notify_all) else: ... async def process_messages_on_asyncio(): while True: await condition.wait_for(lambda: len(messages) > 0) while len(messages): m = messages.pop(0) ... Here messages are delivered outside of asyncio in a separate thread and thus they need to be forwarded into asyncio for further processing in the app. If the flow of messages is high it is desirable to filter inside the thread handler before signaling asyncio. There are multiple approaches to describe which messages can be handled by the asyncio processor, but singledispatchmethod is the most elegant as it allows to keep everything in one place without if/else or code duplication. Having a registry (trivially) exposed would allow to write the condition as `isinstance(message, tuple(on_message.registry.keys()))`. -- components: Library (Lib) messages: 385151 nosy: Ilya.Kulakov, lukasz.langa, methane, ncoghlan priority: normal severity: normal status: open title: singledispatchmethod should expose registry of all known overloads type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43424] Document the `controller.name` field in `webbrowser` module
New submission from Ilya Grigoriev :
The object `webbrowser.get()` returns has, and had for a long time, a useful
but undocumented field `name`. I wonder if it would be OK to document it as
something like `a system-dependent name for the browser`. This would go here:
https://docs.python.org/3/library/webbrowser.html#browser-controller-objects
The reason I'd like this is so that I can write code like the following:
```python
# In Crostini Chrome OS Linux, the default browser is set to an
# intermediary called `garcon-url-handler`.
# It opens URLs in Chrome running outside the linux VM. This
# browser does not have access to the Linux filesystem. Some references:
#
https://chromium.googlesource.com/chromiumos/platform2/+/master/vm_tools/garcon/#opening-urls
# https://source.chromium.org/search?q=garcon-url-handler
if "garcon-url-handler" in webbrowser.get().name:
webbrowser.open("http://external-url.com/docs.html";)
else:
webbrowser.open("file:///usr/share/doc/docs.html")
```
This would work correctly, even if the user has installed a browser native to
the Linux VM and put it into their `BROWSER` environment variable. I don't know
a better way to achieve the same effect.
Some references to where the `name` field was introduced:
https://bugs.python.org/issue754022
https://github.com/python/cpython/commit/e8f244305ef4f257f6999b69601f4316b31faa5e
--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 388218
nosy: docs@python, ilyagr
priority: normal
severity: normal
status: open
title: Document the `controller.name` field in `webbrowser` module
type: enhancement
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue43424>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17013] Allow waiting on a mock
Change by Ilya Kulakov : -- nosy: +Ilya.Kulakov nosy_count: 11.0 -> 12.0 pull_requests: +19958 pull_request: https://github.com/python/cpython/pull/20759 ___ Python tracker <https://bugs.python.org/issue17013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17013] Allow waiting on a mock
Ilya Kulakov added the comment: Correct, it is not backward compatible in that respect. I did not check thoroughly, but a quick lookup shown no such use among public repos on GitHub. I can instead add the called_event property and make the CallEvent “public”. Best Regards Ilya Kulakov > On Jun 9, 2020, at 11:56 PM, Pablo Galindo Salgado > wrote: > > > Pablo Galindo Salgado added the comment: > > isn't PR 20759 backwards incompatible? If I understand correctly, this would > break anyone that is checking for identity as : > > assert mymock.called is True > > -- > nosy: +pablogsal > > ___ > Python tracker > <https://bugs.python.org/issue17013> > ___ -- ___ Python tracker <https://bugs.python.org/issue17013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17013] Allow waiting on a mock
Ilya Kulakov added the comment: > Unfortunately, we take backwards compatibility very seriously in the core > team and this is a big downside of this proposal. Current implementation relies on that: 1. called is almost never used in practice (people just use .assert*) 2. The is True / False is discouraged and is rarely used by itself, let alone in combination with .called > Wouldn't that also break any mock that is mocking an object with a > "called_event" attribute? It should break them in the same way as "called" breaks them now. -- ___ Python tracker <https://bugs.python.org/issue17013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17013] Allow waiting on a mock
Ilya Kulakov added the comment: As far as I understand it introduces 3 methods that may clash. It's unlikely but (I speculate) is still more likely than an identity check with called. That being said, the PR can be redone as a subclass. But that implementation will not play as nicely with the planned `awaited` property for asyncio mocks (see description in the PR). -- ___ Python tracker <https://bugs.python.org/issue17013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17013] Allow waiting on a mock
Ilya Kulakov added the comment: > That is not true, is actually encouraged to check for singletons like True, > False and None. You're right, just never used it as I never needed an identity check against True / False The PR is re-done to use an additional property call_event instead of extending called for backwards compatibility. -- ___ Python tracker <https://bugs.python.org/issue17013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41478] Empty representation of AssertionError
New submission from Ilya Kamenshchikov :
I have a high level wrapper where I am catching expection and present it in
(more) user-friendly format with a message.
try:
raise ValueError
except Exception as e:
print(f"Following happened: {e}")
>>> prints "Following happened: "
Can an exception print it's class when it has no message?
--
components: Interpreter Core
messages: 374831
nosy: Ilya Kamenshchikov
priority: normal
severity: normal
status: open
title: Empty representation of AssertionError
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41478>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41478] Empty representation of AssertionError
Ilya Kamenshchikov added the comment:
That's a solution, except you must know ahead of time this issue exists.
Best Regards,
--
Ilya Kamen
On Tue, Aug 4, 2020 at 6:59 PM Rémi Lapeyre wrote:
>
> Rémi Lapeyre added the comment:
>
> Hi, can you not use its repr:
>
>
> >>> try: raise ValueError
> ... except Exception as e: print(f"Following happened: {e!r}")
> ...
> Following happened: ValueError()
>
> ?
>
> --
> nosy: +remi.lapeyre
>
> ___
> Python tracker
> <https://bugs.python.org/issue41478>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue41478>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41478] Empty representation of AssertionError
Ilya Kamenshchikov added the comment: Changing behavior and it's impact on existing code is, without a doubt, a big deal here. Maybe it's a reason not to do anything about it. Just to understand guiding design principle, what is expected from __str__ in more general case? I thought about it as "user-friendly string representation", therefore expected an Exception without a message to identify itself by it's class. Best Regards, -- Ilya Kamen On Thu, Aug 6, 2020 at 6:05 PM Rémi Lapeyre wrote: > > Rémi Lapeyre added the comment: > > > That's a solution, except you must know ahead of time this issue exists. > > If we changed str(e) to make it the same as repr(e), there would be no way > to get only the message. str(e) returns the message so if the message given > was empty (or no message was given) you get an empty string. This cannot be > changed without breaking a lot of code. > > -- > versions: +Python 3.10, Python 3.9 > > ___ > Python tracker > <https://bugs.python.org/issue41478> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37182] ast - handling new line inside a string
New submission from Ilya Kamenshchikov : parsing two different strings produces identical ast.Str nodes: import ast txt1 = '"""\\n"""' txt2 = '"""\n"""' tree1 = ast.parse(txt1) tree2 = ast.parse(txt2) print(tree1.body[0].value.s == tree2.body[0].value.s) print(bytes(tree1.body[0].value.s, encoding='utf-8')) print(bytes(tree2.body[0].value.s, encoding='utf-8')) >>> True >>> b'\n' >>> b'\n' Expected result: I should be able to distinguish between the nodes created from two different strings. -- components: Library (Lib) messages: 344861 nosy: Ilya Kamenshchikov priority: normal severity: normal status: open title: ast - handling new line inside a string type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue37182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37182] ast - handling new line inside a string
Ilya Kamenshchikov added the comment: Same problem holds for tabs (\\t vs \t). For \\r vs \r, it is even more fun: txt1 = '"""\\r"""' txt2 = '"""\r"""' >>> b'\r' >>> b'\n' -- ___ Python tracker <https://bugs.python.org/issue37182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37352] Typo in documentation: "to making it easy"
Change by Ilya Kamenshchikov : -- keywords: +patch pull_requests: +14525 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14730 ___ Python tracker <https://bugs.python.org/issue37352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37352] Typo in documentation: "to making it easy"
Ilya Kamenshchikov added the comment: The wording from Carol Willing makes it read simpler. Also in the next sentence, 'test-directed development' goes under the name 'test-driven development' as of 2019 (search in google -> https://en.wikipedia.org/wiki/Test-driven_development). I have created a pull request with simpler wording and 'test-driven development'. CLA is signed, will take time to propagate. -- nosy: +Ilya Kamenshchikov ___ Python tracker <https://bugs.python.org/issue37352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Ilya Kamenshchikov added the comment:
Py3.6+ f-strings support any indexing as they actually evaluate python
expressions.
>>> a = ['Java', 'Python']
>>> var = f"Hello {a[-1]}"
Hello Python
--
nosy: +Ilya Kamenshchikov
___
Python tracker
<https://bugs.python.org/issue7951>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
Ilya Kulakov added the comment: I'm not sure about type() to get a class object and calling __aenter__, __aexit__ through it: that makes it hard to mock these classes as Mock's spec= relies on __class__ and type() seem to ignore it (learned it a hard way. Yury, I could take a second look and try to change this into a patch if that's OK. -- nosy: +Ilya.Kulakov ___ Python tracker <http://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
Ilya Kulakov added the comment: > but at the same time rejected by the 'async with' statement. Perhaps unittest.mock (or type) needs to be adjusted to allow mocking via spec= without subclassing? > By all means you can submit a PR! I'll take a look then. -- ___ Python tracker <http://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31363] __PYVENV_LAUNCHER__ breaks calling another venv's interpreter
New submission from Ilya Kulakov:
There are 2 venvs. One has the pkg_resources (pkgr_venv) package installed,
another (venv) doesn't.
Venv without pkg_resources is currently active.
Works: $ /python -c "import pkg_resources"
Doesn't work: $ python -c "import subprocess;
subprocess.check_call(['/python', '-c', 'import pkg_resources'])"
Works: $ python -c "import os, subprocess; env = os.environ.copy();
env.pop('__PYVENV_LAUNCHER__'); subprocess.check_call(['< pkgr_venv>/python',
'-c', 'import pkg_resources'], env=env)"
--
messages: 301454
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: __PYVENV_LAUNCHER__ breaks calling another venv's interpreter
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue31363>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs
Ilya Kulakov added the comment: Christian, If you have windows under your hand and can try an alike path, you should see the problem right away if it's still there. I think the original problem was unnecessary PyUnicode_FSConverter: it failed to encode string into mbcs, while OpenSSL did not have any problems understanding a UTF-8 on Windows. -- ___ Python tracker <https://bugs.python.org/issue27354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs
Ilya Kulakov added the comment: > On Python 3.5, PyUnicode_FSConverter() uses MBCS, which is CP-1552 on your > system. Will the behavior of Python 3.6 be different? Could you point me to relevant notes or code? > If I understood correctly, it's possible to work around the issue by encoding > the filename manually to utf-8. That's correct. I'm not sure that this is true for all versions though. -- ___ Python tracker <https://bugs.python.org/issue27354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31489] Signal delivered to a subprocess triggers parent's handler
New submission from Ilya Kulakov:
It looks like a signal delivered to multiprocessing's process implicitly
created by ProcessPoolExecutor triggers signal handler in the parent:
```
from concurrent.futures import ProcessPoolExecutor
import asyncio
import os
import signal
import sys
import time
def background_task():
print(f"Running background task {os.getpid()}", file=sys.stderr)
time.sleep(15)
print("Exiting background task", file=sys.stderr)
async def task():
print("Running task")
executor = ProcessPoolExecutor()
with executor:
loop = asyncio.get_event_loop()
try:
await loop.run_in_executor(executor, background_task)
except asyncio.CancelledError:
print("Cancelling task 1", file=sys.stderr)
try:
await asyncio.sleep(15)
except asyncio.CancelledError:
print("Cancelling task 2", file=sys.stderr)
raise
raise
def main():
def terminate(coro):
print(f"Terminating {os.getpid()}")
coro.cancel()
loop = asyncio.get_event_loop()
t = asyncio.ensure_future(task())
loop.add_signal_handler(signal.SIGTERM, terminate, t)
try:
print(f"Running {os.getpid()}", file=sys.stderr)
loop.run_until_complete(t)
finally:
loop.run_until_complete(loop.shutdown_asyncgens())
loop.close()
if __name__ == '__main__':
main()
```
1. Normal execution:
> Running 1000
> Running task
> Running background task
> Exiting background task
2. Sending SIGTERM to parent once:
> Running 1000
> Running task
> Running background task
< kill -s SIGTERM
> Terminating 1000
> Cancelling task 1
> Exiting background task
3. Sending SIGTERM to parent twice:
> Running 1000
> Running task
> Running background task
< kill -s SIGTERM 1000
> Terminating 1000
> Cancelling task 1
< kill -s SIGTERM 1000
> Terminating 1000
> Cancelling task 2
> Exiting background task
4. Sending SIGTERM to once to parent and once to child:
> Running 1000
> Running task
> Running background task
< kill -s SIGTERM 1000
> Terminating 1000
> Cancelling task 1
< kill -s SIGTERM
> Terminating 1000
> Cancelling task 2
> Exiting background task
As you can see, sending SIGTERM into a subprocess somehow triggered a signal
handler inside a parent. This is unexpected.
--
components: asyncio
messages: 302321
nosy: Ilya.Kulakov, yselivanov
priority: normal
severity: normal
status: open
title: Signal delivered to a subprocess triggers parent's handler
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue31489>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31489] Signal delivered to a subprocess triggers parent's handler
Ilya Kulakov added the comment: I think either loop's signal handler should not be called from a subprocess or at the very least, os.getpid / os.getpgrp should report correctly. -- ___ Python tracker <https://bugs.python.org/issue31489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35548] memoryview needlessly (?) requires represented object to be hashable
New submission from Ilya Kulakov : Implementation of memoryview's hashing method [1] imposes the following constraints in order to be hashable (per documentation): > One-dimensional memoryviews of hashable (read-only) types with formats ‘B’, > ‘b’ or ‘c’ are also hashable. The hash is defined as hash(m) == > hash(m.tobytes()): However it's not clear why original type needs to be hashable given that memoryview deals with 1-dimensional read-only bytes representation of an object. Not only it requires the developer to make an extra copy of C-bytes, but also calls __hash__ of a represented object without using the result other than to detect an error. My particular use case involves a memory view of a readonly numpy's ndarray. My view satisfies the following constraints: >>> print(data.format, data.readonly, data.shape, data.c_contiguous) b True (25,) True But nevertheless the hashing fails because ndarray itself is not hashable. Stefan Krah wrote [2]: > Note that memory_hash() raises an error if the exporter *itself* is not hashable, so it only hashes immutable objects by design. But while __hash__ indeed tells that object is (supposed to be) immutable, there is no requirement for all immutable objects to have __hash__. Both threads I have found ([3], [4]) are quite lengthy and show certain discord in opinions regarding the issue. Perhaps after 6 years since the release of the feature the view on the problem has changed? 1: https://github.com/python/cpython/blob/d1e717588728a23d576c4ead775f7dbd68149696/Objects/memoryobject.c#L2829-L2876 2: https://bugs.python.org/issue15814#msg169510 3: https://bugs.python.org/issue15573 4: https://bugs.python.org/issue15573 -- components: Library (Lib) messages: 332280 nosy: Kentzo, skrah priority: normal severity: normal status: open title: memoryview needlessly (?) requires represented object to be hashable versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue35548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35548] memoryview needlessly (?) requires represented object to be hashable
Ilya Kulakov added the comment: True, but perhaps it's too strict to require both memoryview and the represented object to be immutable? The logic is as follows: Every object in Python can be seen as a view of some outside data (in memory, on disk etc.). And while Python's runtime may attempt to guarantee immutability of its objects, it cannot guarantee immutability of the outside data. Therefore a hashable object is an object immutable from the perspective of Python's runtime. Memory views connect Python objects with outside data. They can be marked as immutable by Python's runtime. Therefore it should be sufficient to be hashable regardless of volatility of outside data. In your example the immutability of the ndarray is indeed bypassed via a view created beforehand. But that's implementation detail and may actually be a flaw (i.e. being unable to propagate the change). The documentation [1] somewhat warns your that this behavior might change: > However, **currently**, locking a base object does not lock any views that > already reference it, so under that circumstance it is possible to alter the > contents of a locked array via a previously created writeable view onto it. 1: https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/numpy.ndarray.flags.html -- ___ Python tracker <https://bugs.python.org/issue35548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35548] memoryview needlessly (?) requires represented object to be hashable
Ilya Kulakov added the comment: Perhaps another path is optionally allow hashing of memoryviews (all current conditions - hashability of the original object) via a parameter? Like unsafe_hash like in dataclass. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue35548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22962] ipaddress: Add optional prefixlen argument to ip_interface and ip_network
Ilya Kulakov added the comment: You can initialize ip_interface via a tuple of 2 elements: IP address and a prefix (prefixlen or string representation of a netmask). I believe the issue can be closed now. -- nosy: +Ilya.Kulakov ___ Python tracker <http://bugs.python.org/issue22962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29890] Constructor of ipaddress.IPv*Interface does not follow documentation
New submission from Ilya Kulakov:
As per documentation, it should understand the same arguments as IPv*Network.
Unfortunately it does not recognize netmask in string form. Hence the following
code will fail:
ipaddress.ip_interface(('192.168.1.10', '255.255.255.0'))
while the following will work:
ipaddress.ip_network(('192.168.1.10', '255.255.255.0'), strict=False)
--
messages: 290062
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: Constructor of ipaddress.IPv*Interface does not follow documentation
type: behavior
versions: Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue29890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30078] "-m unittest --help" says nothing about direct script exection
New submission from Ilya Kazakevich: In Py3 it is possible to run test filelike "python -m unittest tests/test_something.py" (it is *not* possible in Py2!) Here is doc: https://docs.python.org/3/library/unittest.html But "--help" seems to be simply copied from Py2 because it does not have information nor examples about such execution. Please add it to "examples" section at least because this type of usage is very useful. -- assignee: docs@python components: Documentation messages: 291729 nosy: Ilya Kazakevich, docs@python priority: normal severity: normal status: open title: "-m unittest --help" says nothing about direct script exection versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue30078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36529] Python from WindowsStore: can't install package using "-m pip"
New submission from Ilya Kazakevich : No packages could be installed with "-m pip" because of "Access Denied". It seems that it tries to install package to "site-packages' instead of "local-packages". However, "pip.exe" works. Does it mean "pip.exe" is patched somehow, but not python itself? c:\>"c:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\python" -m pip install flask Collecting flask Using cached https://files.pythonhosted.org/packages/7f/e7/08578774ed4536d3242b14dacb4696386634607af824ea997202cd0edb4b/Flask-1.0.2-py2.py3-none-any.whl ... Installing collected packages: flask Could not install packages due to an EnvironmentError: [WinError 5] Access is denied: 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\\Lib\\site-packages\\flask' Consider using the `--user` option or check the permissions. But: c:\>"c:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\pip" install flask Collecting flask Using cached https://files.pythonhosted.org/packages/7f/e7/08578774ed4536d3242b14dacb4696386634607af824ea997202cd0edb4b/Flask-1.0.2-py2.py3-none-any.whl Installing collected packages: flask The script flask.exe is installed in 'C:\Users\SomeUser\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\Scripts' which is not on PATH. Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location. Successfully installed flask-1.0.2 -- components: Installation messages: 339460 nosy: Ilya Kazakevich priority: normal severity: normal status: open title: Python from WindowsStore: can't install package using "-m pip" type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29890] Constructor of ipaddress.IPv*Interface does not follow documentation
Ilya Kulakov added the comment: Can this be included into the next bugfix release? -- ___ Python tracker <https://bugs.python.org/issue29890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
New submission from Ilya Kulakov : Python 3.5 and 3.6 in their corresponding configure.ac try to detect presence of sys_getrandom. The result is written into the `HAVE_GETRANDOM_SYSCALL` definition. libexpact checks for `HAVE_SYSCALL_GETRANDOM` and since it's not defined, does not use it. This fails compilation with up to date libexpact due to a new condition [1]. [1] https://github.com/python/cpython/blob/master/Modules/expat/xmlparse.c#L87-L91 -- components: Build messages: 305270 nosy: Ilya.Kulakov priority: normal severity: normal status: open title: Missing definition of HAVE_SYSCALL_GETRANDOM versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
Ilya Kulakov added the comment: Just compiling Python 3.6.3 from sources on Ubuntu 16.04 Is there any reason to fall back to XML_POOR_ENTROTPY when proper source is actually available? -- ___ Python tracker <https://bugs.python.org/issue31909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
Ilya Kulakov added the comment: nvm my last question. My process is as per README: ./configure && make I'll take a further look at what's wrong. -- ___ Python tracker <https://bugs.python.org/issue31909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
Ilya Kulakov added the comment: Not a bug in Python. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31968] exec(): method's default arguments from dict-inherited globals
New submission from Ilya Polyakovskiy :
I'm using exec() to run code with globals object inherited from dict. The
problem is overloaded __getitem__ doesn't called to load default argument for
class methods.
Here the example. Let's assume we create some variable storage for code
execution
class Env(dict):
def __init__(self, external_storage):
super().__init__()
self._external_storage = external_storage
def __setitem__(self, key, value):
print('__setitem__: {}'.format(key))
self._external_storage[key] = value
def __getitem__(self, key):
print('__getitem__: {}'.format(key))
return self._external_storage[key]
storage = {}
env = Env(storage)
env['var'] = 2
exec("""
class A:
def foo(self, x=var):
print('foo(): {}'.format(x))
a = A()
a.foo()
""", env)
This code will fail with output:
__setitem__: var
Traceback (most recent call last):
File "inheri-test.py", line 29, in
""", env)
File "", line 2, in
File "", line 3, in A
NameError: name 'var' is not defined
As far as I understand the problem is Python/ceval.c:2120. There is only
PyDict_GetItem used to load variable from f_globals, instead of
PyObject_GetItem in case of f_globals is not exact dict.
--
components: Interpreter Core
messages: 305746
nosy: Ilya Polyakovskiy
priority: normal
severity: normal
status: open
title: exec(): method's default arguments from dict-inherited globals
versions: Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issue31968>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31968] exec(): method's default arguments from dict-inherited globals
Change by Ilya Polyakovskiy : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue31968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31968] exec(): method's default arguments from dict-inherited globals
Change by Ilya Polyakovskiy : -- keywords: +patch pull_requests: +4272 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31968] exec(): method's default arguments from dict-inherited globals
Change by Ilya Polyakovskiy : -- pull_requests: +4274 ___ Python tracker <https://bugs.python.org/issue31968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32041] Cannot cast '\0' to c_void_p
New submission from Ilya Kulakov :
Happens on 3.6.3 only:
>>> import ctypes
>>> ctypes.cast('\0', ctypes.c_void_p)
ctypes.ArgumentError: argument 1: : embedded null character
--
components: ctypes
messages: 306307
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: Cannot cast '\0' to c_void_p
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue32041>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'
Ilya Kulakov added the comment: Victor, Does this change imply that no python-traceback-for-every-thread will be printed upon both handled and unhandled C++ exception? -- nosy: +Ilya.Kulakov ___ Python tracker <https://bugs.python.org/issue31701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32041] Cannot cast '\0' to c_void_p
Ilya Kulakov added the comment: That's the change that introduced the bug: https://github.com/python/cpython/pull/2285 -- ___ Python tracker <https://bugs.python.org/issue32041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32041] Cannot cast '\0' to c_void_p
Ilya Kulakov added the comment: I have fixed that problem by ensuring that ctypes-facing code passes bytes, not strings. -- ___ Python tracker <https://bugs.python.org/issue32041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'
Ilya Kulakov added the comment: May I ask why AddVectoredExceptionHandler is used instead of SetUnhandledExceptionFilter? -- ___ Python tracker <https://bugs.python.org/issue31701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'
Ilya Kulakov added the comment: I think faulthandler should use both. E.g. in [1] you can read about an exception that can be handled by AddVectoredExceptionHandler but not SetUnhandledExceptionFilter. Perhaps implementation should use SetUnhandledExceptionFilter for everything and AddVectoredExceptionHandler only for those exceptions that cannot be handled by the former, like c374. I couldn't find a list, so guess it will be an ongoing WIP. 1: https://stackoverflow.com/questions/19656946/why-setunhandledexceptionfilter-cannot-capture-some-exception-but-addvectoredexc -- ___ Python tracker <https://bugs.python.org/issue31701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'
Ilya Kulakov added the comment: Another option is to use AddVectoredContinueHandler [1]. It seems to be called if both VEH and SEH failed to handle the error. 1: https://msdn.microsoft.com/en-us/library/windows/desktop/ms679273(v=vs.85).aspx -- ___ Python tracker <https://bugs.python.org/issue31701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'
Ilya Kulakov added the comment: Steve, the difficulty with SetUnhandledExceptionFilter is that it can replace filter installed by the user (e.g. one of loaded libraries). The information about AddVectoredContinueHandler is scarce, but according to what I found at [1]: If the exception is still not handled after all your frame based SEH handlers are called, vectored continue handler will be called. This gives you the last opportunity to handle the exception in a way you want. 1: https://blogs.msdn.microsoft.com/zhanli/2010/06/24/c-tips-addvectoredexceptionhandler-addvectoredcontinuehandler-and-setunhandledexceptionfilter/ -- ___ Python tracker <https://bugs.python.org/issue31701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'
Ilya Kulakov added the comment: Please ignore everything I said about AddVectoredContinueHandler. I finally got a chance to test the code on Windows and the way it's called is not suitable for faulthandler. -- ___ Python tracker <https://bugs.python.org/issue31701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'
Ilya Kulakov added the comment: Victor, it's very helpful to analyze which Python stack caused exceptions in native code on user's machines. -- ___ Python tracker <https://bugs.python.org/issue31701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32162] typing.Generic breaks __init_subclass__
New submission from Ilya Kulakov :
When superclass inherits from Generic, attributes set for a subclass are
incorrectly propagated to its superclass.
Without Generic attribute access raises an exception:
class X:
def __init_subclass__(cls, **kwargs):
super().__init_subclass__(**kwargs)
cls.attr = 42
class Y(X):
pass
Y.attr # 42
X.attr # AttributeError
With Generic it does not:
import typing
T = typing.TypeVar('T')
class X(typing.Generic[T]):
def __init_subclass__(cls, **kwargs):
super().__init_subclass__(**kwargs)
cls.attr = 42
class Y(X):
pass
Y.attr # 42
X.attr # 42
--
messages: 307182
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: typing.Generic breaks __init_subclass__
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue32162>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32162] typing.Generic breaks __init_subclass__
Ilya Kulakov added the comment: This issue is more server that I expected: it doesn't just propagate value to superclasses, but overrides them. The last subclass created by Python runtime will overwrite value for the whole chain. -- ___ Python tracker <https://bugs.python.org/issue32162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32162] typing.Generic breaks __init_subclass__
Ilya Kulakov added the comment: Current workaround is class X(typing.Generic[T] if typing.TYPE_CHECKING else object): -- ___ Python tracker <https://bugs.python.org/issue32162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32162] typing.Generic breaks __init_subclass__
Ilya Kulakov added the comment: Nah, that's a bad one: you cannot use Generic classes as intended by specifying types. It looks like it happens because cls._grog is not yet set properly by the time __init_subclass__ is called. -- ___ Python tracker <https://bugs.python.org/issue32162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32162] typing.Generic breaks __init_subclass__
Ilya Kulakov added the comment:
That's a better workaround:
class X(typing.Generic[T]):
def __init_subclass__(cls, **kwargs):
super(typing.GenericMeta, cls).__setattr__('_gorg', cls)
super().__init_subclass__(**kwargs)
--
___
Python tracker
<https://bugs.python.org/issue32162>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29302] add contextlib.AsyncExitStack
Change by Ilya Kulakov : -- keywords: +patch pull_requests: +4690 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue29302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
