Changes by Greg Hazel gha...@users.sourceforge.net:
--
nosy: +ghazel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9884
___
___
Python-bugs-list
Greg Hazel gha...@users.sourceforge.net 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
Greg Hazel gha...@users.sourceforge.net added the comment:
Éric Araujo mer...@netwok.org 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
Changes by Greg Hazel gha...@users.sourceforge.net:
--
nosy: +ghazel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7171
___
___
Python-bugs-list
Greg Hazel gha...@users.sourceforge.net 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 rep...@bugs.python.org
Changes by Greg Hazel gha...@users.sourceforge.net:
--
nosy: +ghazel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6792
___
___
Python-bugs-list
New submission from Greg Hazel gha...@users.sourceforge.net:
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
Changes by Greg Hazel gha...@users.sourceforge.net:
Removed file: http://bugs.python.org/file18012/ctypes_test.zip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9266
Greg Hazel gha...@users.sourceforge.net 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
Greg Hazel gha...@users.sourceforge.net 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
Greg Hazel gha...@users.sourceforge.net 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
Greg Hazel gha...@users.sourceforge.net 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
Greg Hazel gha...@users.sourceforge.net 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
Greg Hazel gha...@users.sourceforge.net 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
New submission from Greg Hazel gha...@users.sourceforge.net:
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
Greg Hazel gha...@users.sourceforge.net 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
Greg Hazel gha...@users.sourceforge.net added the comment:
IE renamed the file for me. So this is not uncommon.
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1565509
Greg Hazel gha...@users.sourceforge.net 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 rep...@bugs.python.org
http
Greg Hazel gha...@users.sourceforge.net 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
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 stdin, line 1, in module
TypeError: 'traceback' object has only read-only
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
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
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
23 matches
Mail list logo
