Greg Hazel added the comment:
How about making ServerProxy a new-style class?
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1690840>
_
___
Python-bugs-
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
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 t
Changes by Greg Hazel :
--
nosy: +ghazel
___
Python tracker
<http://bugs.python.org/issue9884>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
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:
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 wel
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
whi
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: 'traceb
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/issue1565
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
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/issue1
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 an
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 direct
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 typicall
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
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:
h
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
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. O
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_S
Changes by Greg Hazel :
Removed file: http://bugs.python.org/file18012/ctypes_test.zip
___
Python tracker
<http://bugs.python.org/issue9266>
___
___
Python-bugs-list m
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,
Changes by Greg Hazel :
--
nosy: +ghazel
___
Python tracker
<http://bugs.python.org/issue6792>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Greg Hazel :
--
nosy: +ghazel
___
Python tracker
<http://bugs.python.org/issue7171>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
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/issue7
24 matches
Mail list logo
