[issue1690840] xmlrpclib methods submit call on __str__, __repr__
Greg Hazel added the comment: How about making ServerProxy a new-style class? _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1690840> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9023] distutils relative path errors
Greg Hazel added the comment: The python setup script is for the python module, which is in a subdirectory of the C library project. I am not going to move setup.py to the root directory just to work around a a distutils bug. This distutils bug could cause it to overwrite files in other directories, since it blindly adds relative paths to the build directory. This is clearly broken. I've changed my code to use os.path.abspath() while I wait for a fix. -- ___ Python tracker <http://bugs.python.org/issue9023> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9023] distutils relative path errors
Greg Hazel added the comment: > Éric Araujo added the comment: >> I've changed my code to use os.path.abspath() while I wait for a >> fix. > Does this means that your code works with paths that go to the parent > directory? I don’t know if it’s right to allow that (I mean this literally: > I’m not the main maintainer and I don’t have much packaging experience). Yes, my code works with the os.path.abspath() change, since it creates the entire absolute path directory structure inside the build directory. This is -- ___ Python tracker <http://bugs.python.org/issue9023> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9884] The 4th parameter of method always None or 0 on x64 Windows.
Changes by Greg Hazel : -- nosy: +ghazel ___ Python tracker <http://bugs.python.org/issue9884> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3423] DeprecationWarning message applies to wrong context with exec()
New submission from Greg Hazel <[EMAIL PROTECTED]>: exec()ing a line which causes a DeprecationWarning causes the warning to quote the file exec() occurs in instead of the string. Demonstration of the issue: http://codepad.org/aMTYQgN5 -- components: None messages: 70129 nosy: ghazel severity: normal status: open title: DeprecationWarning message applies to wrong context with exec() versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4034] traceback attribute error
New submission from Greg Hazel <[EMAIL PROTECTED]>: Unrelated to this bug, I would like to have the ability to remove the reference to the frame from the traceback object. Specifically so that the traceback object could be stored for a while without keeping all the locals alive as well. So, periodically I test to see if python allows that. Python 2.6 gave some strange results compared to 2.5.2: Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> try: ... x = dskjfds ... except: ... import sys ... t, v, tb = sys.exc_info() ... >>> tb >>> dir(tb) ['tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next'] >>> tb.tb_frame >>> tb.tb_frame = None Traceback (most recent call last): File "", line 1, in TypeError: 'traceback' object has only read-only attributes (assign to .tb_frame) >>> Python 2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> try: ... x = lfdskf ... except: ... import sys ... t, v, tb = sys.exc_info() ... >>> tb >>> dir(tb) ['tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next'] >>> tb.tb_frame >>> tb.tb_frame = None Traceback (most recent call last): File "", line 1, in AttributeError: 'traceback' object has no attribute 'tb_frame' >>> -- messages: 74282 nosy: ghazel severity: normal status: open title: traceback attribute error type: behavior versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1565525] gc allowing tracebacks to eat up memory
Greg Hazel <[EMAIL PROTECTED]> added the comment: Or, being able to remove the references to the locals and globals from the traceback would be sufficient. Something like this: try: raise Exception() except: t, v, tb = sys.exc_info() tbi = tb while tbi: tbi.tb_frame.f_locals = None tbi.tb_frame.f_globals = None tbi = tbi.tb_next # now "tb" is cleaned of references ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1565525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4034] traceback attribute error
Greg Hazel <[EMAIL PROTECTED]> added the comment: There seem to be some other exception type and string inconsistencies, but they are not new to Python 2.6 >>> tb.tb_frame = None Traceback (most recent call last): File "", line 1, in TypeError: 'traceback' object has only read-only attributes (assign to .tb_frame) >>> tb.tb_frame.f_locals = None Traceback (most recent call last): File "", line 1, in AttributeError: attribute 'f_locals' of 'frame' objects is not writable >>> tb.tb_frame.f_globals = None Traceback (most recent call last): File "", line 1, in TypeError: readonly attribute >>> dict.clear = "foo" Traceback (most recent call last): File "", line 1, in TypeError: can't set attributes of built-in/extension type 'dict' Should it be an AttributeError or TypeError? Should it be "read-only", readonly", "not writable" or "can't set"? Btw, here's the other ticket for the feature request: http://bugs.python.org/issue1565525 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1565525] gc allowing tracebacks to eat up memory
Greg Hazel added the comment: But a list of strings is not re-raisable. The co_filename, co_name, and such used to print a traceback are not dependent on the locals or globals. ___ Python tracker <http://bugs.python.org/issue1565525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1565525] gc allowing tracebacks to eat up memory
Greg Hazel added the comment: STINNER Victor> Do you need the original traceback? Why not only raising the exception? If the exception was captured in one stack, and is being re-raised in another. It would be more useful to see the two stacks appended instead of just the place where it was re-raised (or the place where it was raised initially, which is what a string would get you - not to mention the inability to catch it). ___ Python tracker <http://bugs.python.org/issue1565525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1565509] Repair or Change installation error
Greg Hazel added the comment: IE renamed the file for me. So this is not uncommon. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue1565509> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3423] DeprecationWarning message applies to wrong context with exec()
Greg Hazel added the comment: Searching the file for "raise" is sort of pointless, since exec() takes a string which might have come from anywhere, and there might be any number of exec() calls in the module. See: http://codepad.org/7EBMhb0O There are at least two reasonable answers: :1: DeprecationWarning: raising a string exception is deprecated raise 'two' or: t.py:7: DeprecationWarning: raising a string exception is deprecated exec(x) Either one would be fine, but randomly choosing the first line of the module where exec() is called is just nonsense. If you want one that applies to Python 3.x, here you go: http://codepad.org/Mq1eZyoE -- status: closed -> open versions: +Python 2.6, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue3423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9023] distutils relative path errors
New submission from Greg Hazel :
Probably applies to more versions, but I only tested on 2.5.2 and 2.6.5.
Distutils incorrectly constructs paths for the build/temp directory when
relative paths are used in the "sources" list. This can result in failing to
make the build/temp directory at all, and placing files in outside of the
build/temp directory.
Consider the following example:
g...@duma:~$ mkdir libfoo
g...@duma:~$ cd libfoo
g...@duma:~/libfoo$ echo > foo.c
g...@duma:~/libfoo$ mkdir pyfoo
g...@duma:~/libfoo$ cd pyfoo
g...@duma:~/libfoo/pyfoo$ echo "from setuptools import setup, Library;
setup(name='foo', ext_modules=[Library(name='foo',sources=['../foo.c'])])" >
setup.py
g...@duma:~/libfoo/pyfoo$ python setup.py build
running build
running build_ext
building 'foo' extension
creating build
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I/usr/include/python2.5 -c ../foo.c -o
build/temp.linux-i686-2.5/../foo.o
Assembler messages:
Fatal error: can't create build/temp.linux-i686-2.5/../foo.o: No such file or
directory
error: command 'gcc' failed with exit status 1
Using os.path.abspath('../foo.c') in the sources causes distutils to create
build/temp.linux-i686-2.5/home/gah/libfoo/foo.o which is fine. However as a
user, this situation is quite surprising, since distutils is responsible for
managing the build and temp directories itself.
--
assignee: tarek
components: Distutils
messages: 108085
nosy: ghazel, tarek
priority: normal
severity: normal
status: open
title: distutils relative path errors
type: behavior
versions: Python 2.5, Python 2.6
___
Python tracker
<http://bugs.python.org/issue9023>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1565525] tracebacks eat up memory by holding references to locals and globals when they are not wanted
Greg Hazel added the comment: This is still an issue. The bug I'm reporting had been explained well, I thought, but I'll repeat it in summary: There is no way to pass around traceback objects without holding references to an excessive number of objects. Traceback raising typically does not use these references at all, so having some way to discard them would be very valuable. This allows storing and passing tracebacks between threads (or coroutines or async tasks) without dying quickly due to memory bloat. The simple-minded way to fix this is to allow the user to break the reference themselves. Fixing this bug would invalidate the need for hacks like the one Twisted has come up with in their twisted.python.Failure object which stringifies the traceback object, making it impossible to re-raise the exception. Failure has a lot of re-implementations of Exceptions and traceback objects as a result. -- status: closed -> open title: gc allowing tracebacks to eat up memory -> tracebacks eat up memory by holding references to locals and globals when they are not wanted versions: +Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue1565525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1565525] tracebacks eat up memory by holding references to locals and globals when they are not wanted
Greg Hazel added the comment:
The objects I do want in the traceback are the objects necessary to print a
traceback, but not the locals and globals of each frame.
For example:
def bar():
x = "stuff"
raise Exception("example!")
bar()
prints:
Traceback (most recent call last):
Line 4, in
bar()
Line 3, in bar
raise Exception("example!")
Exception: example!
There is no reason in that example to have a reference to "x" in the traceback,
since it's not used in the output. This becomes important when I try to save a
reference to the traceback object and raise it later:
import sys
def bar():
x = "stuff"
raise Exception("example!")
try:
bar()
except:
exc_info = sys.exc_info()
def foo(e):
raise e[0], e[1], e[2]
# sometime possibly much later...
foo(exc_info)
Traceback (most recent call last):
Line 12, in
foo(exc_info)
Line 6, in
bar()
Line 4, in bar
raise Exception("example!")
Exception: example!
During that "sometime possibly much later..." comment, a reference to "x" is
held, when it will not be used in printing the traceback later. So, I would not
like to keep a reference to "x", and currently there is no way to do that
without also dropping a reference to the data needed to print the traceback.
--
___
Python tracker
<http://bugs.python.org/issue1565525>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1565525] tracebacks eat up memory by holding references to locals and globals when they are not wanted
Greg Hazel added the comment: It seems this is partially addressed in a big red "Warning" section of the docs on sys.exc_info: http://docs.python.org/release/3.1/library/sys.html#sys.exc_info and is captured in the "Open Issue: Garbage Collection" section for PEP-3134: http://www.python.org/dev/peps/pep-3134/ Bug or feature request, this a well understood and real issue. -- ___ Python tracker <http://bugs.python.org/issue1565525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1565525] tracebacks eat up memory by holding references to locals and globals when they are not wanted
Greg Hazel added the comment: It depends on how you look at it. Those two issues describe the surprising behavior of the same references I'm talking about here, when the lifetime of the traceback reference is only inside the same frame. This ticket describes the surprising behavior of those references when the lifetime of the traceback is any number of frames. My example eat_memory.py is much closer to the issue described in those links - the lifetime of the traceback object is insignificantly one frame higher, not the lifetime of the application. Either way, a feature to discard those references would resolve both. -- ___ Python tracker <http://bugs.python.org/issue1565525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1565525] tracebacks eat up memory by holding references to locals and globals when they are not wanted
Greg Hazel added the comment: > you should *expect* all those values to persist, so that shouldn't be > "surprising". It's not something I expected, and the warnings around traceback objects are a good indication that other developers have not expected it either. One poster on python-ideas said "Working with traceback objects can easily introduce hidden circular references, so it usually better not access them at all". Since these 'hidden' references are not used in many cases, it is surprising that they would be required. > I repeat my recommendation that you take this to python-ideas for feedback, > and then work on a patch if the feedback is positive. I have, and it has been so far. > (By the way, I checked with a twisted developer, and what he wanted was a > convenient way to manually create traceback objects.) When does Twisted want to manually create traceback objects? Failure has specific functions to stringify the traceback to remove the references mentioned here. Creating a fake traceback would be one way to achieve that, but if the references did not exist I'm not sure what the goal would be. -- ___ Python tracker <http://bugs.python.org/issue1565525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9266] ctypes "ValueError: NULL pointer access" on Win7 x64
New submission from Greg Hazel :
ctypes on Windows on a 64bit Python installation gets a NULL pointer access
where one is not expected.
To reproduce the problem, run make.bat then "python ctypes_test.py"
Failure output looks like this:
Three! 1 2 <__main__.LP_Some object at 0x0209C4C8>
<__main__.Some object at 0x0209C548>
91
Four! 1 2 3 <__main__.LP_Some object at 0x0209C4C8>
Traceback (most recent call last):
File "_ctypes/callbacks.c", line 291, in 'calling callback function'
File "ctypes_test.py", line 21, in fourprinter
print(to.contents)
ValueError: NULL pointer access
Otherwise, successful output looks something like:
Three! 1 2
<__main__.Some object at 0x2acc9482ae50>
91
Four! 1 2 3
<__main__.Some object at 0x2acc9482ae50>
91
Environments exhibiting this problem:
Python 2.7 (r27:82525, Jul 4 2010, 07:43:08) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.architecture()
('64bit', 'WindowsPE')
Python 3.1.2 (r312:79149, Mar 20 2010, 22:55:39) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.architecture()
('64bit', 'WindowsPE')
Environments NOT exhibiting the problem:
Python 2.4.3 (#1, Sep 3 2009, 15:37:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.architecture()
('64bit', 'ELF')
Also Windows on a 32bit architecture seems unaffected.
--
assignee: theller
components: ctypes
files: ctypes_test.zip
messages: 110362
nosy: ghazel, theller
priority: normal
severity: normal
status: open
title: ctypes "ValueError: NULL pointer access" on Win7 x64
type: crash
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18012/ctypes_test.zip
___
Python tracker
<http://bugs.python.org/issue9266>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9266] ctypes "ValueError: NULL pointer access" on Win7 x64
Changes by Greg Hazel : Removed file: http://bugs.python.org/file18012/ctypes_test.zip ___ Python tracker <http://bugs.python.org/issue9266> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9266] ctypes "ValueError: NULL pointer access" on Win7 x64
Greg Hazel added the comment:
Ok, this issue is worse, and much easier to reproduce, than I thought. Here is
an updated ctypes_test.zip with a repro using only integers and callbacks.
Correct output:
('three', (1, 2, 3))
('four', (1, 2, 3, 4))
('five', (1, 2, 3, 4, 5))
Incorrect output:
('three', (1, 2, 3))
('four', (1, 2, 3, 0))
('five', (1, 2, 3, 0, 5))
I built Python 2.7 from source with MSVC 9. This is not reproducible in Debug
mode, or Win32 Release mode. It only happens in x64 Release mode.
One very interesting discovery is that if I set these options:
Optimization: Disabled (/Od)
Enable Instrinsic Functions: No
the error does not occur!
--
Added file: http://bugs.python.org/file18023/ctypes_test.zip
___
Python tracker
<http://bugs.python.org/issue9266>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
Changes by Greg Hazel : -- nosy: +ghazel ___ Python tracker <http://bugs.python.org/issue6792> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7171] Add inet_ntop and inet_pton support for Windows
Changes by Greg Hazel : -- nosy: +ghazel ___ Python tracker <http://bugs.python.org/issue7171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7171] Add inet_ntop and inet_pton support for Windows
Greg Hazel added the comment: In addition, inet_ntop and inet_pton can be implemented on Windows platforms prior to Vista using WSAAddressToStringA and WSAStringToAddressA. -- ___ Python tracker <http://bugs.python.org/issue7171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
