[issue12998] Memory leak with CTypes Structure
New submission from M :
When using Python 2.5.4 on Windows (and potentially other versions and
platforms), usage of CTypes like the following cause a memory leak. The memory
leak can be verified with ProcessExplorer, as the memory Python takes up keeps
increasing until eventually Python will get a MemoryError.
import ctypes
def hi():
class c1(ctypes.Structure):
_fields_=[('f1',ctypes.c_uint8)]
class c2(ctypes.Structure):
_fields_=[('g1',c1*2)]
while True:
test=hi()
This is true even if the garbage collector is called explicitly:
import gc
import ctypes
def hi():
class c1(ctypes.Structure):
_fields_=[('f1',ctypes.c_uint8)]
class c2(ctypes.Structure):
_fields_=[('g1',c1*2)]
while True:
test=hi()
test2=gc.collect()
It is also true if "del" is called on the return value of the function.
In order to get the memory leak, it appears to be necessary to have two
Structure classes, with one of them containing a "multiple" of the other one as
a field.
In a code project where functions returning Structure classes similarly to this
example are being used, MemoryError has been encountered.
See: http://stackoverflow.com/users/553702/user553702
--
components: ctypes
messages: 144170
nosy: a01
priority: normal
severity: normal
status: open
title: Memory leak with CTypes Structure
type: resource usage
___
Python tracker
<http://bugs.python.org/issue12998>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12998] Memory leak with CTypes Structure
M added the comment: Correction to the above link: See: http://stackoverflow.com/questions/7452625/python-ctypes-memory-leak-with-structure -- ___ Python tracker <http://bugs.python.org/issue12998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12998] Memory leak with CTypes Structure
M added the comment: If it is a cache, shouldn't it be garbage-collected or limited in size? Why does it grow without bounds? -- ___ Python tracker <http://bugs.python.org/issue12998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25104] Wrong documentation for "chr(i)" function.
New submission from m: The documentation of the "chr(i)" function is not correct, it states that The valid range for the argument is from 0 through 1,114,111 (0x10 in base 16). Correction: The valid range for the argument is from 0 through 255 (0xFF in base 16). -- assignee: docs@python components: Documentation messages: 250630 nosy: docs@python, m priority: normal severity: normal status: open title: Wrong documentation for "chr(i)" function. type: compile error ___ Python tracker <http://bugs.python.org/issue25104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46206] Crash when editing emoji containing strings
New submission from M Z <[email protected]>: Reproduction steps: 0. start rpel. command: ``python`` 1. enter into '___😀' 2. use arrow keys and backspace to delete an underscore 3. press enter. 4. observe segfault - insertion of chars before emoji can also cause crash back trace (gdb): ``` (gdb) bt #0 0x77495d22 in raise () from /lib/libc.so.6 #1 0x7747f862 in abort () from /lib/libc.so.6 #2 0x7747f747 in __assert_fail_base.cold () from /lib/libc.so.6 #3 0x7748e616 in __assert_fail () from /lib/libc.so.6 #4 0x777e7b6e in get_error_line (p=p@entry=0x76e53b80, lineno=lineno@entry=0) at Parser/pegen.c:438 #5 0x77b3660d in _PyPegen_raise_error_known_location (p=p@entry=0x76e53b80, errtype=errtype@entry=0x77e7ac00 <_PyExc_SyntaxError>, lineno=0, col_offset=0, end_lineno=0, end_col_offset=-1, errmsg=0x77c84bcd "(%s) %U", va=0x7fffdcb0) at Parser/pegen.c:491 #6 0x77b36d33 in _PyPegen_raise_error (p=p@entry=0x76e53b80, errtype=0x77e7ac00 <_PyExc_SyntaxError>, errmsg=errmsg@entry=0x77c84bcd "(%s) %U") at Parser/pegen.c:422 #7 0x77b37213 in raise_decode_error (p=p@entry=0x76e53b80) at Parser/pegen.c:271 #8 0x77bbed14 in initialize_token (token_type=60, end=0x0, start=, token=0x76ffb330, p=0x76e53b80) at Parser/pegen.c:712 #9 _PyPegen_fill_token (p=p@entry=0x76e53b80) at Parser/pegen.c:785 #10 0x77c5eca1 in statement_newline_rule (p=0x76e53b80) at Parser/parser.c:1521 #11 interactive_rule (p=0x76e53b80) at Parser/parser.c:994 #12 _PyPegen_parse (p=p@entry=0x76e53b80) at Parser/parser.c:33180 #13 0x77bd5784 in _PyPegen_run_parser (p=p@entry=0x76e53b80) at Parser/pegen.c:1343 #14 0x77bd8e72 in _PyPegen_run_parser_from_file_pointer (fp=fp@entry=0x77619800 <_IO_2_1_stdin_>, start_rule=start_rule@entry=256, filename_ob=filename_ob@entry=0x77155490, enc=enc@entry=0x7714bdb0 "utf-8", ps1=ps1@entry=0x77155c40 ">>> ", ps2=ps2@entry=0x76ffafa0 "... ", flags=0x7fffe0f8, errcode=0x7fffdfe4, arena=0x76feb820) at Parser/pegen.c:1440 #15 0x77bd903e in _PyParser_ASTFromFile (fp=fp@entry=0x77619800 <_IO_2_1_stdin_>, filename_ob=filename_ob@entry=0x77155490, enc=enc@entry=0x7714bdb0 "utf-8", mode=mode@entry=256, ps1=ps1@entry=0x77155c40 ">>> ", ps2=ps2@entry=0x76ffafa0 "... ", flags=0x7fffe0f8, errcode=0x7fffdfe4, arena=0x76feb820) at Parser/peg_api.c:26 #16 0x77bd9205 in PyRun_InteractiveOneObjectEx (fp=fp@entry=0x77619800 <_IO_2_1_stdin_>, filename=filename@entry=0x77155490, flags=flags@entry=0x7fffe0f8) at Python/pythonrun.c:257 #17 0x77bda02d in _PyRun_InteractiveLoopObject (fp=0x77619800 <_IO_2_1_stdin_>, filename=0x77155490, flags=0x7fffe0f8) at Python/pythonrun.c:148 #18 0x77bdbbc7 in _PyRun_AnyFileObject (fp=0x77619800 <_IO_2_1_stdin_>, filename=0x77155490, closeit=0, flags=0x7fffe0f8) at Python/pythonrun.c:84 #19 0x77bdbdf3 in PyRun_AnyFileExFlags (fp=0x77619800 <_IO_2_1_stdin_>, filename=, closeit=0, flags=0x7fffe0f8) at Python/pythonrun.c:116 #20 0x77bddf60 in pymain_run_stdin (config=0xf910) at Modules/main.c:502 #21 pymain_run_python (exitcode=0x7fffe0f0) at Modules/main.c:590 #22 Py_RunMain () at Modules/main.c:666 #23 0x77bde683 in pymain_main (args=args@entry=0x7fffe250) at Modules/main.c:696 #24 0x77bde7f9 in Py_BytesMain (argc=argc@entry=1, argv=argv@entry=0x7fffe3a8) at Modules/main.c:720 #25 0x60af in main (argc=1, argv=0x7fffe3a8) at ./Programs/python.c:15 (gdb) ``` -- components: Unicode messages: 409379 nosy: 10maurycy10, ezio.melotti, vstinner priority: normal severity: normal status: open title: Crash when editing emoji containing strings versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46206] Crash when editing emoji containing strings
M Z <[email protected]> added the comment: FYI: My platform is arch linux on amd64. -- ___ Python tracker <https://bugs.python.org/issue46206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46450] namedtuple leaks data between instances when field's default value is empty list
New submission from Curtis M <[email protected]>: Example code to replicate issue on python 3.10.2 is attached. How to replicate issue: 1. Define a namedtuple where all fields have default values. At least one field's default value will be an empty list: [] 2. Instantiate 2 instances of the namedtuple. 3. In the first instance, use namedtuple._replace() to add a replacement list into a field that defaults to []. 4. Now look at the contents of both namedtuples. *Both* of them are modified, even though the code only modified the first object. *** Output from attached example code: g.P5 1: myNamedTuple(P1='hello', P2='world', P3=None, P4='', P5=[], P6=[]) h.P5 1: myNamedTuple(P1='good', P2='morning', P3=None, P4='', P5=[], P6=[]) Expected: g.P5: [] Actual: g.P5: [] Expected: h.P5: [] Actual: h.P5: [] g.P5 2: myNamedTuple(P1='hello', P2='world', P3=None, P4='', P5=['a', 'b'], P6=[]) h.P5 2: myNamedTuple(P1='good', P2='morning', P3=None, P4='', P5=['a', 'b'], P6=[]) Expected: g.P5: ['a', 'b'] Actual: g.P5: ['a', 'b'] Expected: h.P5: [] Actual: h.P5: ['a', 'b'] g.P5 3: myNamedTuple(P1='hello', P2='world', P3=None, P4='', P5=['a', 'b', 'c', 'd'], P6=[]) h.P5 3: myNamedTuple(P1='good', P2='morning', P3=None, P4='', P5=['a', 'b', 'c', 'd'], P6=[]) Expected: g.P5: ['a', 'b', 'c', 'd'] Actual: g.P5: ['a', 'b', 'c', 'd'] Expected: h.P5: [] Actual: h.P5: ['a', 'b', 'c', 'd'] -- components: Library (Lib) files: namedtuple_example.py messages: 411079 nosy: user027.7 priority: normal severity: normal status: open title: namedtuple leaks data between instances when field's default value is empty list type: behavior versions: Python 3.10 Added file: https://bugs.python.org/file50568/namedtuple_example.py ___ Python tracker <https://bugs.python.org/issue46450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1362] Simple mistake in http://docs.python.org/tut/node6.html
New submission from Dan M: In section 4.6 it says: Writing the value None is normally suppressed by the interpreter if it would be the only value written. When it should say: Writing the value None is normally displayed by the interpreter if it would be the only value written. Or less wordy: The value None is (normally) displayed by the interpreter when it would be the only value written. -- components: Documentation messages: 56948 nosy: dmazz severity: minor status: open title: Simple mistake in http://docs.python.org/tut/node6.html __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1362> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1362] Simple mistake in http://docs.python.org/tut/node6.html
Dan M added the comment: Yes, it is normally suppressed. The problem is the condition when it is suppressed. The documentation states that it's suppressed when it's the only value to be written. It is suppressed when it's *not* the only value to be written. -or- (removing the double negative of suppressed(not displayed) and not) It is displayed when it would be the only value written. The example immediately following this mistake is correct, which makes the actual behavior obvious even if this particular statement is wrong. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1362> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13119] Newline for print() is \n on Windows, and not \r\n as expected
New submission from M. Zilmer : In 3.2.2 the newline for print() is \n on Windows, and not \r\n as expected. In 3.1.4 the newline is \r\n. OS is Win 7, and tried on both 32 and 64 bit. Small example with output is attached. -- components: Windows files: newline.py messages: 145039 nosy: M..Z. priority: normal severity: normal status: open title: Newline for print() is \n on Windows, and not \r\n as expected type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file23330/newline.py ___ Python tracker <http://bugs.python.org/issue13119> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13119] Newline for print() is \n on Windows, and not \r\n as expected
Changes by M. Zilmer : Added file: http://bugs.python.org/file23331/newline_3.1.txt ___ Python tracker <http://bugs.python.org/issue13119> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13119] Newline for print() is \n on Windows, and not \r\n as expected
Changes by M. Zilmer : Added file: http://bugs.python.org/file23332/newline_3.2.txt ___ Python tracker <http://bugs.python.org/issue13119> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13119] Newline for print() is \n on Windows, and not \r\n as expected
M. Zilmer added the comment: Hi Amaury, The two text files were obtained through redirection in Windows, so I simply ran the newline.py file with: ...> C:\Python31\python.exe newline.py > newline_3.1.txt ...> C:\Python32\python.exe newline.py > newline_3.2.txt Best regards, Morten Zilmer -- ___ Python tracker <http://bugs.python.org/issue13119> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13119] Newline for print() is \n on Windows, and not \r\n as expected
M. Zilmer added the comment: Just to make it clear: I have not observed any problems on the Windows terminal (cmd) with \n newline, but at least Notepad does not break lines correctly if only \n is used. -- ___ Python tracker <http://bugs.python.org/issue13119> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5305] imaplib should support international mailbox names
Babak M added the comment: There's a working implementation of this in PloneMailList. http://svn.plone.org/svn/collective/mxmImapClient/trunk/imapUTF7.py -- nosy: +BabakM ___ Python tracker <http://bugs.python.org/issue5305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12223] Datamodel documentation page: 'operator' where 'operand' should be
New submission from Vladimir M. : The page at (http://docs.python.org/reference/datamodel.html) says: "In x * y, if one operator is a sequence that implements sequence repetition". Obviuosly, it should be changed to: "In x * y, if one operand is a sequence that implements sequence repetition". -- assignee: docs@python components: Documentation messages: 137352 nosy: Vladimir.M., docs@python priority: normal severity: normal status: open title: Datamodel documentation page: 'operator' where 'operand' should be versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4028] Problem compiling the multiprocessing module on sunos5
Sebastian M added the comment:
One more thing, as I tried to rebuild whole python I've encountered on
following problem:
building '_multiprocessing' extension
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1
-DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I.
-IInclude -I./Include -I/usr/local/include
-I/home/malyska/bld/python_sol10/Python-2.7.1/Include
-I/home/malyska/bld/python_sol10/Python-2.7.1 -c
/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.c
-o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.o
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1
-DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I.
-IInclude -I./Include -I/usr/local/include
-I/home/malyska/bld/python_sol10/Python-2.7.1/Include
-I/home/malyska/bld/python_sol10/Python-2.7.1 -c
/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.c
-o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.o
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1
-DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I.
-IInclude -I./Include -I/usr/local/include
-I/home/malyska/bld/python_sol10/Python-2.7.1/Include
-I/home/malyska/bld/python_sol10/Python-2.7.1 -c
/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.c
-o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.o
gcc -shared
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.o
-L/home/malyska/bld/python_sol10/install/lib -L/usr/local/lib -o
build/lib.solaris-2.9-sun4u-2.7/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.9-sun4u-2.7/_multiprocessing.so: symbol sem_timedwait:
referenced symbol not found
so I had to commented out HAVE_SEM_TIMEDWAIT from setup.py, see:
elif platform.startswith('sunos5'):
macros = dict(
HAVE_SEM_OPEN=1,
HAVE_FD_TRANSFER=1
)
#HAVE_SEM_TIMEDWAIT=0,
libraries = ['rt']
thanks
--
___
Python tracker
<http://bugs.python.org/issue4028>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8713] multiprocessing needs option to eschew fork() under Linux
Changes by Matt M : -- nosy: +numbernine ___ Python tracker <http://bugs.python.org/issue8713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10297] decimal module documentation is misguiding
Changes by Baiju M : -- nosy: +baijum ___ Python tracker <http://bugs.python.org/issue10297> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10801] zipfile.ZipFile().extractall() header mismatch for non-ASCII characters
New submission from M. Z. : Trying to unpack a ZIP file where some packet files contain danish letters results in: zipfile.BadZipFile: File name in directory 'filename_with_æoå.txt' and header b'filename_with_\x91o\x86.txt' differ. Using Py 3.2b2 on Win7. Unpack the attached ZIP file and run the Py script, which will show the problem using the enclosed two ZIP files. -- components: Library (Lib) files: bug_zipfile_extractall.zip messages: 124964 nosy: M..Z. priority: normal severity: normal status: open title: zipfile.ZipFile().extractall() header mismatch for non-ASCII characters type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file20204/bug_zipfile_extractall.zip ___ Python tracker <http://bugs.python.org/issue10801> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10909] thread hang, possibly related to print
New submission from Scott M : New to Python; be gentle if I've simply missed something. i'M running on Windows XP, using a recently downloaded 2.7.1. I'm running by hitting F5 in IDLE. The attached .py creates 2 threads, one which updates a Tkinter label 10 times a second forever, and one which sleeps for a second and then thrashes the CPU for ~4 seconds, forever. I wrote this to see how Python dealt with CPU-pig threads, and was pleased to see both threads got to run in a decently interleaved way, even in the face of a tight loop. But at a random point, one of the threads (which one varies) stops running. The other continues fine. The problem manifests in less then 5 minutes (often less than 1). At least once, but not ever time, the thread that stopped gave a traceback: Exception in thread Thread-1: Traceback (most recent call last): File "D:\Python27\lib\threading.py", line 530, in __bootstrap_inner self.run() File "F:\Python27\MyProjects\e.py", line 24, in run print "evil!" #<--- point 1 File "D:\Python27\lib\idlelib\rpc.py", line 595, in __call__ value = self.sockio.remotecall(self.oid, self.name, args, kwargs) File "D:\Python27\lib\idlelib\rpc.py", line 211, in remotecall return self.asyncreturn(seq) File "D:\Python27\lib\idlelib\rpc.py", line 240, in asyncreturn response = self.getresponse(seq, wait=0.05) File "D:\Python27\lib\idlelib\rpc.py", line 280, in getresponse response = self._getresponse(myseq, wait) File "D:\Python27\lib\idlelib\rpc.py", line 305, in _getresponse cvar = self.cvars[myseq] KeyError: 8680 BUT in some cases there wasn't a traceback (the last time there wasn't, it was BThread that had stopped running; the label was no longer updating.) If you comment out the print at point 2, or point 1, it seems to work fine, at least for as long as I cared to watch it. Also, I've noticed that if I close the app's window, that at least one thread keeps running and writing to the Python shell console. (One generally dies because the Tkinter label has gone away). They are both marked as daemonic; shouldn't they stop more or less instantly? -- components: Interpreter Core files: e.py messages: 126282 nosy: PythonInTheGrass priority: normal severity: normal status: open title: thread hang, possibly related to print type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file20409/e.py ___ Python tracker <http://bugs.python.org/issue10909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10909] thread hang, possibly related to print
Scott M added the comment: It hasn't failed yet when run "straight". Here's the issue, though. I'm going to be introducing Python as the scripting language of choice, to a bunch of people who are less than fluent in programming. Because debugging is not an obvious concept to them, they are going to hunt for problems by sticking in print statements everywhere, and the environment is inherently multithreaded, so it's hard for me to imagine they won't experience this bug. I hit it in my very first multithreaded experiment. And I can't possibly ask them not to use IDLE - without syntax coloring and a friendly editor to show them which line is wrong, they will never get off the ground. It would be tolerable if there was at least a traceback, but if threads vanish silently, they will not realize it's a environment problem; they will either assume that they did something inexplicably wrong and that "scripting is too hard", or it will get around that I provided a "broken" solution. So even if it's "just the IDE", it's still life and death for this project. "Won't fix" probably means I have to abandon Python. -- ___ Python tracker <http://bugs.python.org/issue10909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10909] thread hang, possibly related to print
Scott M added the comment: Moving to 3.x means redoing large swaths of the extension I just wrote. It's only a couple thousand lines, but it was my first extension and it cost me a week of my life in Google, and it does a lot with strings. I haven't pulled down the source code for Python's internals yet, but from the one trace back I did get in the failing thread test app, the problem was inside print and it looked like it was inside the mechanism where print gets redirected. I hope the problem isn't anything as fundamental as the GIL, because that throws the stability of all of 2.7 into question (and it's been solid in all my tests; I do a lot with threads in my extension, all going after the GIL and diving into Python code.) -- ___ Python tracker <http://bugs.python.org/issue10909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
New submission from Scott M :
Running on dual core Windows XP.
The function should draw a parabolicish shape for each click on launch. But if
you click Launch over and over, very fast, you get bizarre crashes instead:
Python.exe has encoutered a problem, yadda. tcl85.dll. It rarely takes many
clicks.
Apologies for the coding style; this has been hacked down from a larger app.
In the console window:
Exception in thread Thread-5:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 47, in run
self.app.arrival_122((self.target, y, z))
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 100, in arrival_122
self.label.config(text= str(message[0])+ " " + str(message[1]))
File "C:\Python27\lib\lib-tk\Tkinter.py", line 1202, in configure
return self._configure('configure', cnf, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 1193, in _configure
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
TclError: invalid command name "source C:/Python27/tcl/tk8.5/menu.tcl"
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 47, in run
self.app.arrival_122((self.target, y, z))
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 125, in arrival_122
self.graph.create_line(self.trackCoordinates[tn], new_yz)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: invalid command name "line"
Also saw:
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: bad option "665.44997": must be addtag, bbox, bind, canvasx,
canvasy, cget, configure, coords, create, dchars, delete, dtag, find, focus,
gettags, icursor, index, insert, itemcget, itemconfigure, lower, move,
postscript, raise, scale, scan, select, type, xview, or yview
--
components: Tkinter
files: TkinterCrash.py
messages: 127201
nosy: PythonInTheGrass
priority: normal
severity: normal
status: open
title: Crash, 2.7.1, Tkinter and threads and line drawing
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20549/TkinterCrash.py
___
Python tracker
<http://bugs.python.org/issue11029>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Scott M added the comment: To make this more interesting, I'm trying to push for adoption of Python at a scripting tool where I work, and I uncovered this crasher in example code I was about to hand out, under the heading of "look how easy Python is". For obvious reasons I'm holding off on handing out the example; I won't get far selling Python if it crashes when drawing lines... if this is a result of something boneheaded I did, please slap me upside the head ASAP. Conversely if there's a quick fix possible, that will speed Python adoption where I work... thanks. -- ___ Python tracker <http://bugs.python.org/issue11029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Scott M added the comment:
OK, now all calls to Tkinter are funneled to a single thread, through a queue.
(Technically there are two threads in Tkinter - one is parked in .mainloop(),
the other makes a call to Canvas.create_line and a call to Label.config.)
Different crash, but still a crash. This one seems to be mostly consistent; see
below and new attached code.
If you're going to tell me that Tkinter simply can never be called by any
thread other than the one animating mainloop - in other words, Tkinter calls
are only safe within Tkinter callbacks like a Button's command function - then
please suggest an alternative library that is sturdier. There's nothing I can
do about the fact that multiple threads produce independent data that has to go
onto a single graph.
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and
Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py", line 68, in run
self.graph.create_line(element[0], element[1], element[2], element[3])
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
ValueError: invalid literal for int() with base 10: 'None'
But once I got:
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and
Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash2.py", line 68, in run
self.graph.create_line(element[0], element[1], element[2], element[3])
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: can not find channel named "Nonefile13cad48"
--
Added file: http://bugs.python.org/file20576/TkinterCrash2.py
___
Python tracker
<http://bugs.python.org/issue11029>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Scott M added the comment: Alright. More digging turned up the Tkinter "after" function, aka WM_TIMER for Windowy people like me, and that plus a nonblocking queue get() gets all my drawing operations back into the mainLoop() thread. Voilà, no more crashes. Let me suggest that page one, sentence one of any Tkinter documentation should begin "Tkinter is not thread safe", with a link to an example of after() and nonblocking get(). I've changed the component to Documentation. This would save a few days for poor sods like me -- I'm used to low level Windows C++ GUI work, where any thread can call any SDK function at any time, and Windows sorts it all out. Having to force everything into a single thread, and then poll for my data (*GAG*), is something I thought died in the 80's. Is anyone looking at thread safe GUI libraries? -- assignee: -> docs@python components: +Documentation -Tkinter nosy: +docs@python ___ Python tracker <http://bugs.python.org/issue11029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe. This is a bug.
New submission from Scott M : The more I look at GUI support in Python, the more I realize that the lack of basic thread safety in GUI support is simply a bug. I know Java's Swing has the same thread limitation, but that doesn't make it right. Xlib is thread safe. The Windows SDK is thread safe. Python is supposed to be the language that's easy to use, and there is nothing easy about teaching new programmers that they have to mess with queues and timers just to get a basic set of displays running, just because when threads are in use. I'm in the position of teaching folk with little-to-no programming experience, how to script simple applications in Python. The modules they have to use are inherently threaded, and delivery hunks of data from multiple sources to them. The most natural instinct is to put up some graphs and other widgits to display the data, and all of it is completely trivial right up until I have to explain that drawing a line isn't canvas.line(from, to), but becomes an exercise in Queue.Queue and theRoot.after(n, myself), before you even get to learn about widgits. Threading is supposed to simplify problems, not add to them. Having to hack around with special timers and polling, just to get some simple graphs up, is plain unpythonic. Please consider this a bug, a glaring misfeature, in a language that is otherwise a very reasonable choice to get technical but non-programmerish people into toolmaking self-sufficiency. -- components: Tkinter messages: 127604 nosy: PythonInTheGrass priority: normal severity: normal status: open title: Tkinter is not thread safe. This is a bug. type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe (and that's... bad)
Scott M added the comment: I don't have an opinion on 1252236. I'm not certain it would help. I have an extension that runs a bunch of (alien) threads into Python code. The threads deliver information for all sorts of real world events, asynchronously. Multiple threads are used, because people occasionally want to do blocking operations in these alien threads, but still want to be able to handle other incoming information at full speed, with the other threads. If any of these threads attempts to update a Tkinter widgit - and this is the first thing I tried to do - then tkinter will except or crash in some horrible way, sooner or later. The attached .py (in Python 2.7.1) does it without any extensions. Click on Launch quickly 10-15 times; if it doesn't crash, kill and restart. It rarely takes more than 4-5 runs to get a traceback, or occasionally python itself just crashes. Bottom line, one thread in .mainloop() and another thread calling virtually any Tkinter function, even something as simple as .after(), is an invitation a crash. -- title: Tkinter is not thread safe -> Tkinter is not thread safe (and that's... bad) Added file: http://bugs.python.org/file20630/TkinterCrash2.py ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Scott M added the comment: I'll look into making the crash easier to reproduce this coming week. Is Tkinter's thread safety new? Because after I started getting crashes, I did my due diligence in Google and found a number of people writing about how it was necessary to use a Queue and Tkinter's after() timer, to draw from multiple threads. And in experiments in 2.7.1 on Windows, it turned out that it wasn't just the drawing calls from a thread other than the mainloop() thread, that invited a crash; even just trying to set an .after() timer from a different thread caused tracebacks, randomly. At any rate this is less of an issue now, for me at least. I'm putting together a small graphic library for my coworkers. It will have a tiny fraction of Tkinter's capabilities, it will be Windows-only and won't even have native Windows look and feel; but it will be completely, rock-solid, idiot-proof thread safe - any operation (including widget deletes), any thread, any time, with no polling or timers needed. My coworkers are not technical and will get instantly lost if I have to describe queues and timers just to draw a line on a screen. -- ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Scott M added the comment:
The new version runs 40 parabolas, then quits. I usually have to run this
version 20 times or so to get the crash, so be patient. In general if it's
going to crash it does so in the first 6 or so parabolas. Caveat: creates up to
40 threads, so a bit of a CPU pig. You may want to change the 40 in
(self.tracks > 40) to 8.
Here's one crash. I got this by double clicking the .py file from Windows
explorer, but I can get them with F5 in IDLE too.
---
UpdateStringProc should not be invoked for type cmdName
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Exception in thread Thread-6:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "H:\PMT2\MyProjects\TkinterCrash2.py", line 47, in run
self.deliverToQueue((self.target, z, y))
File "H:\PMT2\MyProjects\TkinterCrash2.py", line 129, in arrival_122
new_yz[1])
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: bad screen distance "create"
--
versions: +Python 2.7 -Python 3.3
Added file: http://bugs.python.org/file20684/TkinterCrash2.py
___
Python tracker
<http://bugs.python.org/issue11077>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Scott M added the comment: If it helps, over the many iterations of this test code, there have been two kinds of issues: 1. pythonw.exe crashes with the Windows variant of a SEGV. No traceback, just a crash. These are rare. 2. Evidence of confusion over which string the code should be looking at, and it's always down in the create function of Tkinter. Variations of this confusion have been Int() complaining that it can't translate "None", strings like ".667748474.7464" not being recognized as parameter names... all of it sounds like Tkinter has somehow managed to be looking at the wrong string. Even when the only Tkinter call I do outside the mainloop thread is .after(), the crashes would happen when I went to draw a line. My (trivial) experience in extending Python makes me wonder if some reference count, somewhere, didn’t get mismanaged. The only times I ever got a hard crash out pythonw.exe in my own projects is when I mishandled a count. As a side note, if Tkinter is intended to be thread safe, the documentation should say so. Clearly, and in the first paragraph. Once I started having problems, I started Googling, and everything I read lead me to conclude that neither Tkinter nor wx were even intended to be thread safe, so I've started to write my own GUI code. This is a project I might have skipped if it has been clear that Tkinter is at least intended to be thread safe. -- ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2940] Building Python fails on SunOS
New submission from Adrian M <[EMAIL PROTECTED]>: $ uname -a SunOS ro1estw 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Fire-880 gcc 2.6.3 When running ./configure I'm getting warnings like: configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence This happens for many other headers as well (dlfcn.h, fcntl.h, and many others - i'll attach the whole list of messages). Then, the ./configure step ends with the following message : checking size of int... configure: error: cannot compute sizeof (int) -- components: Build files: config_logs.zip messages: 67183 nosy: syraxes severity: normal status: open title: Building Python fails on SunOS type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file10397/config_logs.zip __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2940> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2940] Building Python fails on SunOS
Adrian M <[EMAIL PROTECTED]> added the comment: Also, please check: http://bugs.python.org/issue1544306 (exactly the same issue that has just been closed because of the lack of feedback from the original reporter) Here is another (old) report referring to the very same issue happening on Solaris: http://bugs.python.org/issue1234473 (an issue that doesn't seem to be solved) I have no idea whether this is a real "Python bug" or not. I'm just reporting a build "issue" that I'm experiencing when trying to compile python on this particular (non-typical) platform. So, I have the access to this SunOS machine and the you (the Python developers) have the knowledge. Let's just work together and try to discover why the building process is not working out-of-the-box on SunOS, rather that imply that it's not a real python bug. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2940> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4017] IDLE 2.6 broken on OSX (Leopard)
Leo M <[EMAIL PROTECTED]> added the comment: Hello. First time here, beginner at Python. I have verified that the Google tip link in the previous to fix IDLE works for me. Post in question: ** [Kevin's post of 6.Oct, 02:58] You can avoid this problem by building Python yourself and putting /Library/Frameworks first on the search path for Tcl/Tk. Look in setup.py in the source code, around line 1438 (in the 'detect_tkinter_darwin' function), and either comment out /System/Library or put it underneath /Library/Frameworks. This is what the official build from Python.org should do--look first in /Library/Frameworks and then fall back on /System/Library/Frameworks. I'm not sure why it doesn't. ** In setup.py, I simply put /Library/Frameworks/ first as outlined above, and then did a config-make-install of the Framework version of Python. IDLE now does not silently fail now, but runs as 'expected'. -Leo Marihart Python Newb, Somewhat more experienced shell guy -- nosy: +leoofborg ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4017> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4017] Tkinter cannot find Tcl/Tk on Mac OS X
Changes by Leo M : -- nosy: -leoofborg ___ Python tracker <http://bugs.python.org/issue4017> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46954] Awaiting multiple times on same task increases memory usage unboundedly
New submission from David M. : Awaiting multiple times on a single task that failed with an exception results in an unbounded increase in memory usage. Enough repeated "await"s of the task can result in an OOM. The same pattern on a task that didn't raise an exception behaves as expected. The attached short script ends up using more than 1GB of memory in less than a minute. -- components: asyncio files: multi_await_exception.py messages: 414739 nosy: asvetlov, davidmanzanares, yselivanov priority: normal severity: normal status: open title: Awaiting multiple times on same task increases memory usage unboundedly versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file50664/multi_await_exception.py ___ Python tracker <https://bugs.python.org/issue46954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47216] adding mtime option to gzip open()
New submission from Marin M : init of class GzipFile has mtime as an optional argument, but open() function does not. When using open(), mtime will always be set to the current time and so far there was no way of fixing it to a specific timestamp. In case two people would tar.gz the same file and take its sha, the shas would be different. With an option to fix the mtime, they could have a unique sha. PR containing code change and the tests is already ready. -- components: Library (Lib) messages: 416685 nosy: ellaellela priority: normal severity: normal status: open title: adding mtime option to gzip open() type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47216> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47216] adding mtime option to gzip open()
Change by Marin M : -- keywords: +patch pull_requests: +30371 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32310 ___ Python tracker <https://bugs.python.org/issue47216> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47217] adding name to BZ2File
New submission from Marin M : BZ2File doesn't have attribute name, unlike GzipFile which has it. Trying to access that attribute results in error. PR is ready with code changes and tests which mimics what is already available for GzipFile (e.g. we do not take name from BytesIO() objects because they do not have it). A similar PR is ready for LZMAFile as well (a different enhancement). -- components: Library (Lib) messages: 416690 nosy: ellaellela priority: normal severity: normal status: open title: adding name to BZ2File type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47217] adding name to BZ2File
Change by Marin M : -- keywords: +patch pull_requests: +30373 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32311 ___ Python tracker <https://bugs.python.org/issue47217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47218] adding name to lzmafile
New submission from Marin M : LZMAFile doesn't have attribute name, unlike GzipFile which has it. Trying to access that attribute results in error. PR is ready with code changes and tests which mimics what is already available for GzipFile (e.g. we do not take name from BytesIO() objects because they do not have it). A similar PR is ready for BZ2File as well (a different enhancement). -- components: Library (Lib) messages: 416691 nosy: ellaellela priority: normal severity: normal status: open title: adding name to lzmafile type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47218] adding name to lzmafile
Change by Marin M : -- keywords: +patch pull_requests: +30374 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32312 ___ Python tracker <https://bugs.python.org/issue47218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem()
Raphaël M added the comment: I stumbled upon this issue while reading Python 3.8 and this made me curious. I've tried writing some Python code to reproduce this bug, but I'm unable to -- I should be missing something. Is there a simple snippet showing the issue? Also, the changelog states that "The CPython interpreter can swallow exceptions in some circumstances". Are there other documented cases of those circumstances? -- nosy: +raphaelm ___ Python tracker <https://bugs.python.org/issue35459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43784] [Windows] interpreter hangs indefinitely on subprocess.communicate during __del__ at script exit
New submission from Kevin M :
I've noticed an issue (or user error) in which Python a call that otherwise
usually works in the __del__ step of a class will freeze when the Python
interpreter is exiting.
I've attached sample code that I've ran against Python 3.9.1 on Windows 10.
The code below runs a process and communicates via the pipe.
class SubprocTest(object):
def run(self):
print("run")
proc_args = ["cmd.exe"]
self._process = subprocess.Popen(proc_args,
stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
def __del__(self):
print("__del__")
if self._process is not None:
self.terminate()
def terminate(self):
print("terminate")
self._process.communicate(input=b"exit\n", timeout=1)
print("kill")
self._process.kill()
self._process = None
if __name__ == "__main__":
s = SubprocTest()
s.run()
del s
print("s done")
t = SubprocTest()
t.run()
print("t done")
Current output:
run
__del__
terminate
kill
s done
run
t done
__del__
terminate
<<<<<< hangs indefinitely here, even though timeout=1
Expected output:
run
__del__
terminate
kill
s done
run
t done
__del__
terminate
kill
In normal circumstances, when you del the object and force a run of __del__(),
the process ends properly and the terminate() method completes.
When the Python interpreter exits, Python calls the __del__() method of the
class. In this case, the terminate() never completes and the script freezes
indefinitely on the communicate()
--
components: Library (Lib), Windows
files: win_subprocess_hang.py
messages: 390587
nosy: paul.moore, steve.dower, sylikc, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] interpreter hangs indefinitely on subprocess.communicate
during __del__ at script exit
versions: Python 3.9
Added file: https://bugs.python.org/file49947/win_subprocess_hang.py
___
Python tracker
<https://bugs.python.org/issue43784>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43784] starting a thread in __del__ hangs at interpreter shutdown
Kevin M added the comment: eryksun, wow, that's speedy analysis, but there might be more to it. I went and tested a bunch of test cases. my subrocess code doesn't seem to hang on Linux where the thread example code does? Linux - Python 3.6.8 - your threading example DOESN'T hang Linux - Python 3.6.8 - My subprocess code also DOESN'T hang Linux - Python 3.8.5 - thread example HANGs Linux - Python 3.8.5 - My subprocess code also DOESN'T hang Windows - Python 3.9.1 - thread example HANGs Windows - Python 3.9.1 - subprocess code HANGs -- ___ Python tracker <https://bugs.python.org/issue43784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44162] importlib.resources.path no longer supports directories
New submission from T M : In Python 3.7 and 3.8, importlib.resources.path worked perfectly with a directory. For example: with importlib.resources.path(__package__, "dir") as dir: os.listdir(dir) In Python 3.9, this is raised: IsADirectoryError: [Errno 21] Is a directory: 'dir' I haven't seen this change documented. I don't know if the behavior in 3.7 and 3.8 was a bug, it sure was useful. In this case, we have web files which we want to serve statically from that folder. Naming them file by file could work, but would be tedious and isn't preferable for us. Thank you! -- messages: 393831 nosy: gitpushdashf priority: normal severity: normal status: open title: importlib.resources.path no longer supports directories type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44162] importlib.resources.path no longer supports directories
T M added the comment: importlib_resources 1.1.X also behaves this way: https://github.com/python/importlib_resources/issues/85 -- ___ Python tracker <https://bugs.python.org/issue44162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44162] importlib.resources.path no longer supports directories
T M added the comment: That's fine. I couldn't find anything official on it, but that change is working for me. Thank you! -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45818] socketserver.BaseRequestHandler inherited class
New submission from Sergey M. :
Due to
```python
try:
self.handle()
finally:
self.finish()
```
construct in `socketserver.BaseRequestHandler.__init__()` method inherited
classes with `overrided __init__()` method may suffer from incomplete
initialization.
For example, in the following snippet
```python
def __init__(self, request, client_address, server):
super().__init__(request, client_address, server)
self.foo = 1
```
in some cases all the code after `super()` call will not be executed.
This is a MWE of the server with partially initialized Handler class
```python
from socketserver import UnixStreamServer, StreamRequestHandler, ForkingMixIn
class Handler(StreamRequestHandler):
def __init__(self, request, client_address, server):
super().__init__(request, client_address, server)
self.foo = 1
def handle(self):
print(self.foo)
class ThreadedUnixStreamServer(ForkingMixIn, UnixStreamServer):
pass
with ThreadedUnixStreamServer("/tmp/test.socket", Handler) as server:
server.serve_forever()
```
--
components: Library (Lib)
messages: 406413
nosy: matsievskiysv
priority: normal
severity: normal
status: open
title: socketserver.BaseRequestHandler inherited class
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue45818>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem()
Raphaël M added the comment: Any pointer would also be welcome, and a piece of code showing the bug would help me a lot. Thank you. -- ___ Python tracker <https://bugs.python.org/issue35459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem()
Raphaël M added the comment: Thank you very much! -- ___ Python tracker <https://bugs.python.org/issue35459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39431] Mention nonlocal too in assignment quirk
New submission from Shanavas M : Doc says "A special quirk of Python is that -- if no :keyword:`global` statement is in A special quirk of Python is that -- if no :keyword:`global` or :keyword:`nonlocal` effect -- assignments to names always go into the innermost scope." nonlocal should also be mentioned along with global -- assignee: docs@python components: Documentation messages: 360553 nosy: docs@python, shanavasm priority: normal pull_requests: 17528 severity: normal status: open title: Mention nonlocal too in assignment quirk versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39597] sorting the String
New submission from Shani M : It showing the wrong string order. 'sss' is to be appear at 3rd place but it comes at last place. 'qwe' is to appear at last place but it comes at 3rd place. -- files: Screenshot from 2020-02-10 14-08-52.png messages: 361675 nosy: Shani M priority: normal severity: normal status: open title: sorting the String versions: Python 2.7 Added file: https://bugs.python.org/file48886/Screenshot from 2020-02-10 14-08-52.png ___ Python tracker <https://bugs.python.org/issue39597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40339] Instead of skipping, IPV6 test(s) fail on a non-IPV6 machine
New submission from M T :
I have no use for IPv6 and, when recompiling my OS, disable the feature
completely. Python compiles nicely despite of this, but the IPv6-related tests
fail instead of being skipped:
ERROR: test_create_server_ipv6
(test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests)
--
Traceback (most recent call last):
File
"/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/test/test_asyncio/test_base_events.py",
line 1149, in test_create_server_ipv6
self.loop.run_until_complete(main())
File
"/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/base_events.py",
line 488, in run_until_complete
return future.result()
File
"/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/coroutines.py",
line 129, in throw
return self.gen.throw(type, value, traceback)
File
"/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/test/test_asyncio/test_base_events.py",
line 1141, in main
lambda: None, '::1', 0, loop=self.loop)
File
"/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/streams.py",
line 119, in start_server
return (yield from loop.create_server(factory, host, port, **kwds))
File
"/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/base_events.py",
line 1041, in create_server
infos = yield from tasks.gather(*fs, loop=self)
File
"/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/asyncio/base_events.py",
line 990, in _create_server_getaddrinfo
flags=flags, loop=self)
File
"/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/concurrent/futures/thread.py",
line 56, in run
result = self.fn(*self.args, **self.kwargs)
File "/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/socket.py", line
745, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 8] hostname nor servname provided, or not known
==
FAIL: test_ipaddr_info (test.test_asyncio.test_base_events.BaseEventTests)
--
Traceback (most recent call last):
File
"/spare/usr/ports/lang/python36/work/Python-3.6.10/Lib/test/test_asyncio/test_base_events.py",
line 104, in test_ipaddr_info
base_events._ipaddr_info('::3', 1, INET6, STREAM, TCP))
AssertionError: (, https://bugs.python.org/file49077/config.log
___
Python tracker
<https://bugs.python.org/issue40339>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43427] Possible error on the descriptor howto guide
New submission from Marcos M : > To recap, functions have a __get__() method so that they can be converted to > a method when accessed as attributes. The non-data descriptor transforms an > obj.f(*args) call into f(obj, *args). Calling cls.f(*args) becomes f(*args). I THINK it should say cls.f(*args) becomes f(cls, *args) as stated in the table that follows that paragraph. -- assignee: docs@python components: Documentation messages: 388239 nosy: docs@python, marcosmodenesi priority: normal severity: normal status: open title: Possible error on the descriptor howto guide type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43427] Possible error on the descriptor howto guide
Marcos M added the comment: Let me provide a link to ease finding this piece of documentation https://docs.python.org/3/howto/descriptor.html#static-methods -- ___ Python tracker <https://bugs.python.org/issue43427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43458] Tutorial should mention about variable scope in try/except/finally
New submission from Marek M : It can be helpful to mention that variables defined in try block are visible in except/finally block as well. I did not find this info in Python tutorial and for me (having C++ background) this is quite unexpected feature. -- assignee: docs@python components: Documentation messages: 388407 nosy: deekox, docs@python priority: normal severity: normal status: open title: Tutorial should mention about variable scope in try/except/finally type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40860] Exception in multiprocessing/context.py under load
New submission from Arkady M :
I am running an HTTP server (socketserver.ThreadingMixIn,
http.server.HTTPServer) in a Docker container (FROM ubuntu:19.10)
Occasionally I get an exception:
Exception happened during processing of request from ('172.17.0.1', 35756)
Traceback (most recent call last):
File "/usr/lib/python3.7/socketserver.py", line 650, in process_request_thread
self.finish_request(request, client_address)
File "/usr/lib/python3.7/socketserver.py", line 360, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "service.py", line 221, in __init__
super(UrlExtractorServer, self).__init__(*args, **kwargs)
File "/usr/lib/python3.7/socketserver.py", line 720, in __init__
self.handle()
File "/usr/lib/python3.7/http/server.py", line 426, in handle
self.handle_one_request()
File "/usr/lib/python3.7/http/server.py", line 414, in handle_one_request
method()
File "service.py", line 488, in do_POST
self._post_extract(url)
File "service.py", line 459, in _post_extract
extracted_links, err_msg = self._extract_links(transaction_id,
attachment_id, zip_password, data)
File "service.py", line 403, in _extract_links
error, results = call_timeout(process_deadline,
extractor.extract_links_binary_multiprocess, args=data)
File "service.py", line 175, in call_timeout
manager = multiprocessing.Manager()
File "/usr/lib/python3.7/multiprocessing/context.py", line 56, in Manager
m.start()
File "/usr/lib/python3.7/multiprocessing/managers.py", line 563, in start
self._process.start()
File "/usr/lib/python3.7/multiprocessing/process.py", line 111, in start
_cleanup()
File "/usr/lib/python3.7/multiprocessing/process.py", line 56, in _cleanup
if p._popen.poll() is not None:
AttributeError: 'NoneType' object has no attribute 'poll'
I am in the process of preparingof of a reasonably simple piece of code
demonstrating the problem.
Meanwhile the following can be important. In the code below I ma getting the
elapse < timeout (20 times from 70K). In all case psutil.Process() returned
psutil.NoSuchProcess
time_start = time.time()
job = multiprocessing.Process(target=func, args=(args, results),
kwargs=kwargs)
job.start()
job.join(timeout)
elapsed = time.time()-time_start
if job.is_alive():
try:
process = psutil.Process(job.pid)
process_error = f"pid {job.pid} status {process.status} {process}"
except Exception as e:
process_error = f"psutil.Process() failed {e}"
if elapsed < timeout:
print("elapsed < timeout")
--
messages: 370695
nosy: Arkady M
priority: normal
severity: normal
status: open
title: Exception in multiprocessing/context.py under load
type: crash
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue40860>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39603] [security] http.client: HTTP Header Injection in the HTTP method
Change by M W : -- assignee: -> christian.heimes components: +SSL nosy: +M W2, christian.heimes ___ Python tracker <https://bugs.python.org/issue39603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9625] argparse: Problem with defaults for variable nargs
Michał M. added the comment: Of course I've made a mistake: "list for user provided or list for default" should be: "list for user provided or STRING for default" -- ___ Python tracker <http://bugs.python.org/issue9625> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14179] Test coverage for lib/re.py
New submission from Florian M : I added one small test in lib/test/test_re.py for complete coverage of 're._compile' method. -- components: Tests files: re_coverage.patch keywords: patch messages: 154785 nosy: flomm priority: normal severity: normal status: open title: Test coverage for lib/re.py versions: Python 3.3 Added file: http://bugs.python.org/file24710/re_coverage.patch ___ Python tracker <http://bugs.python.org/issue14179> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14179] Test coverage for lib/re.py
Changes by Florian M : Added file: http://bugs.python.org/file24728/re_coverage.patch ___ Python tracker <http://bugs.python.org/issue14179> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14202] The docs of xml.dom.pulldom are almost nonexistent
Florian M added the comment: I wrote some documentation with the information I found on http://wiki.python.org/moin/PullDom and some custom examples. -- nosy: +flomm Added file: http://bugs.python.org/file24750/xml.dom.pulldom.rst ___ Python tracker <http://bugs.python.org/issue14202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37106] python re.escape doesn't escape some special characters.
New submission from MANI M : Recently I figured out an issue in python3 re which doesn't escape some special characters. Not sure whether this bug has been reported already. Have attached screenshots for your reference. Steps to reproduce: 1. wget https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tar.xz 2. tar -xvzf Python-3.7.3.tar.xz 3. cd Python-3.7.3 4. ./configure 5. make 6. make install. GCC version: gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36) OS: CentOS Linux release 7.6.1810 (Core) -- components: Regular Expressions files: python_3.7.3_bug.png messages: 344020 nosy: MANI M, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: python re.escape doesn't escape some special characters. type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48377/python_3.7.3_bug.png ___ Python tracker <https://bugs.python.org/issue37106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37106] python re.escape doesn't escape some special characters.
MANI M added the comment: Thanks a lot for the info. May I know in what version of python the patches are applied? Because still 3.7.3 seems to have the issue. -- ___ Python tracker <https://bugs.python.org/issue37106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37106] python re.escape doesn't escape some special characters.
MANI M added the comment:
I've scripts which insert data into MySQL database. The values may contain
symbols. Hence in order to escape that I use re.escape(). @erik.smith isn't
re.escape() supposed to escape all the symbols. If not why is this introduced
in 3.7 whereas previous versions behave differently.
Example snippet:
import pymysql
from re import escape
def db_connection():
..
..
..
# This throws error.
query = " insert into table(column)
values('{}'.format(escape("Hello'`~world")))
--
___
Python tracker
<https://bugs.python.org/issue37106>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37106] python re.escape doesn't escape some special characters.
MANI M added the comment:
sorry my bad
query = "insert into table(column) values('{}')".format(escape("Hello'`~world"))
--
___
Python tracker
<https://bugs.python.org/issue37106>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32077] Documentation: Some Unicode object functions don't indicate whether they return a new reference
Change by Mathew M. : -- pull_requests: +10473 ___ Python tracker <https://bugs.python.org/issue32077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29921] datetime validation is stricter in 3.6.1 than previous versions
New submission from m-parry:
The change in issue #29100 - intended AFAICS simply to fix a regression in 3.6
- seems to have made datetime validation via certain code paths stricter than
it was in 2.7 or 3.5. I think it's the case that some routes via the C API now
reject out of range values that were previously permitted. Even if this
previous behaviour was incorrect, was it intentional to alter that in a
maintenance release?
Here's a quick example using pywin32:
---
> import getpass, sspi, sspicon, win32security
> client_name = getpass.getuser()
> auth_info = (client_name, 'wherever.com', None)
> pkg_info = win32security.QuerySecurityPackageInfo('Kerberos')
> win32security.AcquireCredentialsHandle(
> client_name, pkg_info['Name'],
> sspicon.SECPKG_CRED_OUTBOUND,
> None, auth_info)
ValueError: year 30828 is out of range
---
Of course, this is probably a mishandling of the 'never expires' value returned
by the Windows API in this case, and indeed I have also created a pywin32
ticket. However, I'm guessing that the linked issue wasn't supposed to break
such code.
--
components: Library (Lib)
messages: 290609
nosy: m-parry
priority: normal
severity: normal
status: open
title: datetime validation is stricter in 3.6.1 than previous versions
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue29921>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29921] datetime validation is stricter in 3.6.1 than previous versions
m-parry added the comment: >From my opening comment (with new emphasis): "I think it's the case that **some routes via the C API** now reject out of range values that were previously permitted." The pywin32 repro I gave above eventually calls PyDateTimeAPI->DateTime_FromDateAndTime(): http://pywin32.hg.sourceforge.net/hgweb/pywin32/pywin32/file/85c1c99b1cb8/win32/src/PyTime.cpp#l980 AFAICT, under Python < 3.6.1 such out of range values were tolerated there. Under Python 2.7, for example, the datetime that results from this call is somewhere in 1899. I am not claiming that these invalid values should be tolerated forever more, or that this was ever the correct behaviour, but I would have expected a backwards incompatible change like this to happen in, say, Python 3.7, rather than a maintenance release. (Particularly when it breaks a library that's practically standard on Windows.) -- ___ Python tracker <http://bugs.python.org/issue29921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29921] datetime validation is stricter in 3.6.1 than previous versions
m-parry added the comment: That's just a Python C API call. It looks like it eventually resolves to new_datetime_ex(30828, 9, 13, 3, 48, 5, 48, Py_None, PyDateTime_DateTimeType). We also have some internal code that sees a similar problem from calling PyTime_FromTime(), that was similarly affected by this change. In one example, that appears to resolve to new_time_ex(24, 0, 0, 0, Py_None, PyDateTime_TimeType). Again, under <3.6.1, that was accepted. (And again, I am making no argument about the validity of this code, just with regards to backwards compatibility.) -- ___ Python tracker <http://bugs.python.org/issue29921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29921] datetime validation is stricter in 3.6.1 than previous versions
m-parry added the comment: pywin32 is not my code. It is a ubiquitous Python library on Windows that cannot be used under Python 3.6.1. -- ___ Python tracker <http://bugs.python.org/issue29921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32956] python 3 round bug
New submission from M Hsia : import sys print(sys.version) for i in range(10): test=i+0.5 print (test,round(test,0)) 3.6.3 |Anaconda custom (64-bit)| (default, Nov 8 2017, 15:10:56) [MSC v.1900 64 bit (AMD64)] 0.5 0.0 1.5 2.0 2.5 2.0 3.5 4.0 4.5 4.0 5.5 6.0 6.5 6.0 7.5 8.0 8.5 8.0 9.5 10.0 - 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 bit (Intel)] (0.5, 1.0) (1.5, 2.0) (2.5, 3.0) (3.5, 4.0) (4.5, 5.0) (5.5, 6.0) (6.5, 7.0) (7.5, 8.0) (8.5, 9.0) (9.5, 10.0) -- messages: 312931 nosy: MJH priority: normal severity: normal status: open title: python 3 round bug type: behavior versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue32956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32956] python 3 round bug
M Hsia added the comment: import sys print(sys.version) for i in range(10): test=i+0.5 print (test,round(test,0)) 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit (Intel)] 0.5 0.0 1.5 2.0 2.5 2.0 3.5 4.0 4.5 4.0 5.5 6.0 6.5 6.0 7.5 8.0 8.5 8.0 9.5 10.0 3.6.3 |Anaconda custom (64-bit)| (default, Nov 8 2017, 15:10:56) [MSC v.1900 64 bit (AMD64)] 0.5 0.0 1.5 2.0 2.5 2.0 3.5 4.0 4.5 4.0 5.5 6.0 6.5 6.0 7.5 8.0 8.5 8.0 9.5 10.0 - 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 bit (Intel)] (0.5, 1.0) (1.5, 2.0) (2.5, 3.0) (3.5, 4.0) (4.5, 5.0) (5.5, 6.0) (6.5, 7.0) (7.5, 8.0) (8.5, 9.0) (9.5, 10.0) -- ___ Python tracker <https://bugs.python.org/issue32956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33257] Race conditions in Tkinter with non-threaded Tcl
Change by Scott M : -- nosy: +PythonInTheGrass ___ Python tracker <https://bugs.python.org/issue33257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33257] Race conditions in Tkinter with non-threaded Tcl
Scott M added the comment: 7 years and counting... My need for a fix is long gone, but I'd like to be able to tell the original group I worked with whether it's now safe to use tkinter from threads. It looks like my original guesses were validated and a fix has been made, but I can't tell if it's universally available. What version of Python would they need to be on, and are any platforms still misbehaved "out of the box"? They will not be willing to rebuild python itself. TIA. -- ___ Python tracker <https://bugs.python.org/issue33257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31951] import curses is broken on windows
New submission from joe m : Importing curses on Windows install calls the following: Traceback (most recent call last): File "", line 1, in File "C:\Users\user name\AppData\Local\Programs\Python\Python36-32\lib\curses\__init__.py", line 13, in from _curses import * ModuleNotFoundError: No module named '_curses' Importing curses as "_curses" does the same thing. I have tried the "repair" function and it has not worked. -- components: Windows messages: 305610 nosy: joe m2, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: import curses is broken on windows versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue31951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31951] import curses is broken on windows
joe m added the comment: I would much prefer the curses module to be supported in newer versions since I believe that curses is installed as a built in module (not sure about that). Anyhow, thank you for your help but I have found a replacement module called "asciimatics" which for fills all the functions that I really need. -- ___ Python tracker <https://bugs.python.org/issue31951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32013] _pickle: Py_DECREF seems to be missing from a failure case in fast_save_enter()
New submission from Mathew M. : Hey there! I'm fairly new to the development process for Python, so I figured I'd start off with something tiny and then work on up from there. I'm not sure if this sort of minor fix warrants an issue being created, but I made this just to err on the safe side of things. So, as far as I understand (by all means correct me if I'm wrong), a 'Py_DECREF(key);' should be present before the return in the conditional within fast_save_enter() (https://github.com/python/cpython/blob/d7d4fea4a39da4bfdea1de22fe040023eb4ddc17/Modules/_pickle.c#L1792) -- components: Extension Modules messages: 306139 nosy: Mathew M. priority: normal severity: normal status: open title: _pickle: Py_DECREF seems to be missing from a failure case in fast_save_enter() versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue32013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32013] _pickle: Py_DECREF seems to be missing from a failure case in fast_save_enter()
Change by Mathew M. : -- keywords: +patch pull_requests: +4331 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32020] arraymodule: Missing Py_DECREF in failure case of make_array()
New submission from Mathew M. : Similar to issue 32013, just in a different location. For reference: https://github.com/python/cpython/blob/28b624825eb92cb8c96fbf8da267d8d14a61a841/Modules/arraymodule.c#L1932 -- components: Extension Modules messages: 306183 nosy: Mathew M. priority: normal severity: normal status: open title: arraymodule: Missing Py_DECREF in failure case of make_array() type: resource usage versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue32020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32020] arraymodule: Missing Py_DECREF in failure case of make_array()
Change by Mathew M. : -- keywords: +patch pull_requests: +4339 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32077] Documentation: Some Unicode object functions don't indicate whether they return a new reference
New submission from Mathew M. : This is just something I've noticed when browsing the C API documentation for Unicode objects. For example, the documentation entry for PyUnicode_DecodeMBCSStateful lacks the "Return value: New reference", etc. -- assignee: docs@python components: Documentation messages: 306516 nosy: Mathew M., docs@python priority: normal severity: normal status: open title: Documentation: Some Unicode object functions don't indicate whether they return a new reference type: enhancement ___ Python tracker <https://bugs.python.org/issue32077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32077] Documentation: Some Unicode object functions don't indicate whether they return a new reference
Change by Mathew M. : -- keywords: +patch pull_requests: +4407 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34665] Py_FinalizeEx() - Bugs & caveats - Add info that NumPy and Pandas don't support reinitialization
New submission from Johannes M. : Since about a decade, it's a know problem that NumPy and Pandas initialization function crashes on reinitialization after a call to Py_Finalize() + Py_Initialize(). [https://github.com/numpy/numpy/issues/8097] [https://github.com/numpy/numpy/issues/11925] It seems to be unlikely that this problem gets fixed soon. Due to the popularity of the modules, it would be good to add this information to the documentation of Py_FinalizeEx(), such that developers, who are planning to embed Python get this information already at the moment when they read the documentation. I would suggest to change the following sentence: Some extensions may not work properly if their initialization routine is called more than once; to Some extensions, like NumPy and Pandas, may not work properly if their initialization routine is called more than once; -- assignee: docs@python components: Documentation messages: 325275 nosy: docs@python, jcmuel priority: normal severity: normal status: open title: Py_FinalizeEx() - Bugs & caveats - Add info that NumPy and Pandas don't support reinitialization type: enhancement versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18671] enhance formatting in logging package
New submission from M. Dietrich: in logging/__init__.py line 328 there is a simple line: msg = msg % self.args if that line fails this failure will be logged, not the line itself. i suggest to change the line to something like: try: msg = msg % self.args except TypeError: msg = 'logging formatting error with "%s" %% %s' % ( msg, self.args, ) to be able to pinpoint the actual wrong formatting string (the stack trace doesnt help here). -- components: Extension Modules messages: 194559 nosy: mdt priority: normal severity: normal status: open title: enhance formatting in logging package type: enhancement ___ Python tracker <http://bugs.python.org/issue18671> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18671] enhance formatting in logging package
M. Dietrich added the comment: yes, seeing the erranous line where the wrong formatstring comes from is nice but sometimes (for myself: often) i need to know what actually was tried to be logged. this information is lost in both cases. this is especially sad if you have long-running processes that encounter an error after a long time and that error is logged but the logging itself fails due to formatting issues. i suggest to log whatever is avaiable in the suggested way to at least see this valuable information. the additional information where it comes from for further fixing is apreaciated as well. btw: the stackstrace of the logging internals could be left out in my oppinion, it just pollutes the output with no means to the programer. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue18671> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18671] enhance formatting in logging package
M. Dietrich added the comment: for a logging library the important thing would be to not loose the information that was meant to log. as i said i do alot of long-running huge-data-processing scripts in py using the library. if the logging breaks but doesnt log what was intended to log i judge this a major problem. and furthermore: it is so simple to add both information: the data that was to be logged plus the state that an error occured while formatting and where the log-call was made. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue18671> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18671] enhance formatting in logging package
M. Dietrich added the comment: thanks, it will be really helpful for me to have this fixed. as i consider this a "bug" it would be possible to "fix" this for 2.7 and yes you are right, i talked about 2.7 as we are still using this version in production. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue18671> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15079] pickle: Possibly misplaced test
New submission from Stefan M : After issue7455 was fixed, a test was created to reflect the fix (Lib/test/pickletester.py @ AbstractPickleModuleTests.test_bad_input). The test makes sure that an UnpicklingError is raised whenever pickled data attempts to pop on an empty stack. Although tests on AbstractPickleModuleTests normally only run on the C implementation of pickle (on which UnpicklingError is thrown), they may also run on the Python implementation if the C implementation of pickle is not available (which throws IndexError). I'm not sure if it's still reasonable to assume that it's possible for the C implementation of pickle not to exist (the python module does), as I've discovered this by forcefully disabling the C implementation. >>> pickle.Unpickler(io.BytesIO(b'0')).load() _pickle.UnpicklingError: unpickling stack underflow >>> pickle._Unpickler(io.BytesIO(b'0')).load() IndexError: list assignment index out of range The current fix involves adding IndexError to the list of exceptions that may be raised and moving the testcase to AbstractPickleTests (where the tests are ran against both the C and Python impl). As I'm working on improving pickle in protocol v4, it might be worth considering adding more consistency to the exceptions that are being raised by the Python unpickler. -- components: Tests files: pickletester.py.patch keywords: patch messages: 162919 nosy: alexandre.vassalotti, collinwinter, mstefanro priority: normal severity: normal status: open title: pickle: Possibly misplaced test type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file26019/pickletester.py.patch ___ Python tracker <http://bugs.python.org/issue15079> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20135] FAQ need list mutation answers
M. Volz added the comment: Thanks David, I've updated the patch to move the default values question into the programming FAQ where you recommended it go, and also changed the title of the mutable list question. -- Added file: http://bugs.python.org/file34604/sortFAQ_defaultval.patch ___ Python tracker <http://bugs.python.org/issue20135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2818] pulldom cannot handle xml file with large external entity properly
Changes by M. Volz : -- nosy: +mvolz ___ Python tracker <http://bugs.python.org/issue2818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18456] Documentation for PyDict_Update is incorrect
Changes by Jill M : -- nosy: +Jill.M ___ Python tracker <http://bugs.python.org/issue18456> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18624] Add alias for iso-8859-8-i which is the same as iso-8859-8
Changes by M. Volz : -- nosy: +mvolz ___ Python tracker <http://bugs.python.org/issue18624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3430] httplib.HTTPResponse documentations inconsistent
Changes by M. Volz : -- nosy: +mvolz ___ Python tracker <http://bugs.python.org/issue3430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7159] Urllib2 authentication memory.
Changes by M. Volz : -- nosy: +mvolz ___ Python tracker <http://bugs.python.org/issue7159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3849] FUD in documentation for urllib.urlopen()
Changes by M. Volz : -- nosy: +mvolz ___ Python tracker <http://bugs.python.org/issue3849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16508] include the "object" type in the lists of documented types
Changes by M. Volz : -- nosy: +mvolz ___ Python tracker <http://bugs.python.org/issue16508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20135] FAQ need list mutation answers
Changes by M. Volz : -- nosy: +mvolz ___ Python tracker <http://bugs.python.org/issue20135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
