[issue10025] random.seed not initialized as advertised
New submission from Tom Goddard :
In Python 2.7, random.seed() with a string argument is documented as being
equivalent to random.seed() with argument equal to the hash of the string
argument. This is not the actual behavior. Reading the _random C code reveals
it in fact casts the signed hash value to unsigned long. This also appears to
be the situation with Python 2.5.2. Rather than fix this in 2.7.1 it seems
preferable to just correct the documentation in 2.7.1 to preserve backward
compatibility. Bug #7889 has already addressed this problem in Python 3.2 by
eliminating the use of hash() for non-integer random.seed() arguments. I
encountered this problem while trying to produce identical sequences of random
numbers on 64-bit architectures as on 32-bit architectures.
Here is a demonstration of the bug in Python 2.7, 32-bit.
random.seed('1pov')
random.uniform(0,1)
0.713827305919223
random.seed(hash('1pov'))
random.uniform(0,1)
0.40934677883730686
hash('1pov')
-747753952
random.seed(hash('1pov') + 2**32) # unsigned long cast
random.uniform(0,1)
0.713827305919223
--
components: Library (Lib)
messages: 117988
nosy: goddard
priority: normal
severity: normal
status: open
title: random.seed not initialized as advertised
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue10025>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42514] Relocatable framework for macOS
Change by Tom Goddard : -- nosy: +tomgoddard ___ Python tracker <https://bugs.python.org/issue42514> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16177] Typing left parenthesis in IDLE causes intermittent Cocoa Tk crash on OS X
Tom Goddard added the comment: This Mac Tk bug was supposedly fixed in 2016 or 2017. Details are in the following Tk ticket. http://core.tcl.tk/tk/tktview/c84f660833546b1b84e7 The previous URL to the Tk ticket no longer works. In case the above URL also goes bad, the id number for the Tk ticket is c84f660833546b1b84e7fd3aef930c2f17207461 -- ___ Python tracker <https://bugs.python.org/issue16177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16177] Typing left parenthesis in IDLE causes intermittent Cocoa Tk crash on OS X
Tom Goddard added the comment: I've seen this crash about 50 times in the UCSF Chimera molecular visualization package, same traceback, and it is caused when a tooltip is raised, but not from IDLE. The key observation is that it only happens on dual display systems where the second display is positioned partly or entirely above or to the left of the primary display. An attempt to raise a tooltip on that second display causes a crash. This seems almost certain to be a Mac Tk bug. At first I thought it was caused by the x,y screen position of the tool tip being negative. But when the second screen is arranged above the primary screen (in Mac display system preferences) the y position is which increases from bottom to top is something like 2000, not negative. Currently my hunch is that the tooltip popup window was created for the primary display, and trying to position it on the secondary display is for some reason an error. I don't know enough about the native Mac NSWindow to say anything definitive. Hope this helps you to at least consistently reproduce the crash. -- nosy: +goddard ___ Python tracker <http://bugs.python.org/issue16177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16177] Typing left parenthesis in IDLE causes intermittent Cocoa Tk crash on OS X
Tom Goddard added the comment: More testing shows that this Mac Tk crash with dual displays only happens when the second display is partly or entirely above the primary display in the Mac display system preferences. An attempt to show the tooltip on the second display above the top of the primary display a crash happens. Contrary to my previous comment it does not appear to depend on whether the secondary display is to the right or to the left of the primary display. Possibly the key factor is that the tooltip is being displayed above Mac top of (primary) screen menu bar. It is possible that that is an Apple bug, rather than a Mac Tk bug. -- ___ Python tracker <http://bugs.python.org/issue16177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16177] Typing left parenthesis in IDLE causes intermittent Cocoa Tk crash on OS X
Tom Goddard added the comment: Ok I reported this as a Mac Tk bug and gave a very simple way to reproduce it. http://core.tcl.tk/tk/tktview?name=3Dc84f660833 -- ___ Python tracker <http://bugs.python.org/issue16177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5557] Byte-code compilation uses excessive memory
New submission from Tom Goddard :
Bytecode compiling large Python files uses an unexpectedly large amount
of memory. For example, compiling a file containing a list of 5 million
integers uses about 2 Gbytes of memory while the Python file size is
about 40 Mbytes. The memory used is 50 times the file size. The
resulting list in Python consumes about 400 Mbytes of memory, so
compiling the byte codes uses about 5 times the memory of the list
object. Can the byte-code compilation can be made more memory efficient?
The application that creates simlilarly large Python files is a
molecular graphics program called UCSF Chimera that my lab develops. It
writes session files which are Python code. Sessions of reasonable size
for Chimera for a given amount of physical memory cannot be
byte-compiled without thrashing, crippling the interactivity of all
software running on the machine.
Here is Python code to produce the test file test.py containing a list
of 5 million integers:
print >>open('test.py','w'), 'x = ', repr(range(500))
I tried importing the test.py file with Python 2.5, 2.6.1 and 3.0.1 on
Mac OS 10.5.6. In each case when the test.pyc file is not present the
python process as monitored by the unix "top" command took about 1.7 Gb
RSS and 2.2 Gb VSZ on a MacBook Pro which has 2 Gb of memory.
--
components: Interpreter Core
messages: 84108
nosy: goddard
severity: normal
status: open
title: Byte-code compilation uses excessive memory
type: performance
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue5557>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5557] Byte-code compilation uses excessive memory
Tom Goddard added the comment: I agree that having such large Python code files is a rare circumstance and optimizing the byte-code compiler for that should be a low priority. Thanks for the cpickle suggestion. The Chimera session file Python code is mostly large nested dictionaries and sequences. I tested cPickle and repr() to embed data structures in the Python code getting rather larger file size because the 8-bit characters became 4 bytes in the text file string (e.g. "\xe8"). Using cPickle, and base64 encoding dropped the file size by about a factor of 2.5 and cPickle, bzip2 or zlib compression, and base64 dropped the size another factor of 2. The big win is that the byte code compilation used 150 Mbytes and 5 seconds instead of 2 Gbytes and 15 minutes of thrashing for a 40 Mbyte python file. I think our reason for not using pickled data originally in the session files was because we like users to be able to look at and edit the session files in a text editor. (This is research software where such hacks sometimes are handy.) But the especially large data structures in the sessions can't reasonably be meddled with by users so pickling should be fine. Pickling adds about 15% to the session save time, and reduces session opening by about the same amount. Compression slows the save down another 15% and probably is not worth the factor of 2 reduction in file size in our case. -- ___ Python tracker <http://bugs.python.org/issue5557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
