[issue42197] Disable automatic update of frame locals during tracing
Fabio Zadrozny added the comment: > > So, it's expected that `some_module` and `v` would be in the locals at this > > point. > If a function does not have the local variables `some_module` and `v`, then > the change wouldn't be visible to the debugee. So what difference does it make? Right now such changes are visible to the debugee in the locals frames if a user does the `exec` and calls `PyFrame_FastToLocals` right afterwards (even if they weren't initially there). So, it's the difference between being able to import a module and creating/manipulating new variables in an `exec` in any frame (as it works right now) or not being able to make it at all (if that feature is deprecated as is being implied in the PEP). -- ___ Python tracker <https://bugs.python.org/issue42197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42197] Disable automatic update of frame locals during tracing
Fabio Zadrozny added the comment: @ncoghlan I took a quick look at the PEP... I'm a bit worried about: > On optimised frames, the Python level f_locals API will become a direct > read/write proxy for the frame's local and closure variable storage, and > hence no longer support storing additional data that doesn't correspond to a > local or closure variable on the underyling frame object. In particular, it's common for a debugger to evaluate expressions in a context that would change the locals to add new variables. i.e.: stopping at a breakpoint and doing 2 `exec` calls with frame.f_locals with: import some_module v = some_module.compute(xxx) So, it's expected that `some_module` and `v` would be in the locals at this point. Right now after each line of the evaluation, a `PyFrame_FastToLocals` must be called so things work as they should, but given that the PEP explicitly says that it should be deprecated, and this being a common feature for a debugger, what'd be the proper way to support that? p.s.: should I ask such questions regarding the PEP somewhere else instead of this issue or is this an appropriate place? -- ___ Python tracker <https://bugs.python.org/issue42197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42044] Running Python in unbuffered mode may not write all contents to the console
Fabio Zadrozny added the comment: Seems fair. I just did a pull request to remove those limits. Please let me know if you think something else is needed there. -- ___ Python tracker <https://bugs.python.org/issue42044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42044] Running Python in unbuffered mode may not write all contents to the console
Change by Fabio Zadrozny : -- keywords: +patch pull_requests: +25264 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26678 ___ Python tracker <https://bugs.python.org/issue42044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42197] Disable automatic update of frame locals during tracing
Fabio Zadrozny added the comment: I agree that it can be made better, but I think most of the issues right now comes from CPython trying to automatically do something that's not bound to work (calling PyFrame_FastToLocals/PyFrame_LocalsToFast under the hood during the tracing call). https://bugs.python.org/issue30744 is a great example of why that can never work properly (debuggers need to manage that much more carefully, just doing it on all calls is really bound to not work). So, the current implementation besides being broken also makes things pretty slow. I agree that PEP 558 may fix things here (but it's much more work). As a disclaimer, pydevd actually uses a different tracer which doesn't do those calls and when possible uses the frame eval to modify the bytecode directly to minimize the overhead, so, in practice the current support given by CPython for debugger is pretty reasonable for doing a fast debugger (but there are a few caveats that it must work around -- such as the auto PyFrame_FastToLocals/PyFrame_LocalsToFast calls). -- ___ Python tracker <https://bugs.python.org/issue42197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42197] Disable automatic update of frame locals during tracing
New submission from Fabio Zadrozny :
Right now, when a debugger is active, the number of local variables can affect
the tracing speed quite a lot.
For instance, having tracing setup in a program such as the one below takes
4.64 seconds to run, yet, changing all the variables to have the same name --
i.e.: change all assignments to `a = 1` (such that there's only a single
variable in the namespace), it takes 1.47 seconds (in my machine)... the higher
the number of variables, the slower the tracing becomes.
```
import time
t = time.time()
def call():
a = 1
b = 1
c = 1
d = 1
e = 1
f = 1
def noop(frame, event, arg):
return noop
import sys
sys.settrace(noop)
for i in range(1_000_000):
call()
print('%.2fs' % (time.time() - t,))
```
This happens because `PyFrame_FastToLocalsWithError` and `PyFrame_LocalsToFast`
are called inside the `call_trampoline`
(https://github.com/python/cpython/blob/master/Python/sysmodule.c#L946).
So, I'd like to simply remove those calls.
Debuggers can call `PyFrame_LocalsToFast` when needed -- otherwise mutating
non-current frames doesn't work anyways. As a note, pydevd already has such a
call:
https://github.com/fabioz/PyDev.Debugger/blob/0d4d210f01a1c0a8647178b2e665b53ab113509d/_pydevd_bundle/pydevd_save_locals.py#L57
and PyPy also has a counterpart.
As for `PyFrame_FastToLocalsWithError`, I don't really see any reason to call
it at all.
i.e.: something as the code below prints the `a` variable from the `main()`
frame regardless of that and I checked all pydevd tests and nothing seems to be
affected (it seems that accessing f_locals already does this:
https://github.com/python/cpython/blob/cb9879b948a19c9434316f8ab6aba9c4601a8173/Objects/frameobject.c#L35,
so, I don't see much reason to call it at all).
```
def call():
import sys
frame = sys._getframe()
print(frame.f_back.f_locals)
def main():
a = 1
call()
if __name__ == '__main__':
main()
```
So, the idea is removing those lines (I expect that I'll be able to provide a
pull request for this).
--
components: Interpreter Core
messages: 379874
nosy: fabioz
priority: normal
severity: normal
status: open
title: Disable automatic update of frame locals during tracing
type: performance
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue42197>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42044] Running Python in unbuffered mode may not write all contents to the console
New submission from Fabio Zadrozny :
When running Python in unbuffered mode it may fail to write all the contents to
the actual console (on Windows).
The code below can reproduce the issue:
```
import sys
s = ''
for i in range(1,301):
s += f"{str(i*100).zfill(10)}{'x' * 89}\n"
sys.stdout.write(s)
```
When calling it with `python -u code.py` it'll write only up to line 15000 and
when calling it with `python code.py` it'll write up to line 3.
This fails because in `_textiowrapper_writeflush` it doesn't verify if all the
contents have been indeed written and thus fails in a partial write. In
buffered mode it works because `_io_BufferedWriter_write_impl` does the job
properly.
I'm a bit uncertain on why doesn't `_io__WindowsConsoleIO_write_impl` itself do
the loop to write everything instead of leaving it up to callers to do that
work (apparently due to issue11395 it says that it only writes partially, but
maybe the fix could've been to loop inside of
`_io__WindowsConsoleIO_write_impl` to write everything instead of expecting
callers to handle partial writes...
--
components: IO
messages: 378684
nosy: fabioz
priority: normal
severity: normal
status: open
title: Running Python in unbuffered mode may not write all contents to the
console
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue42044>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Add _PyEval_SetTrace(tstate, func, arg) function
Fabio Zadrozny added the comment: >> I.e.: something as adding a thread_id to sys.settrace -- >> sys.settrace(trace_func, thread_id=None). > What is the use case for this feature? The use case is having the user attach the debugger (either programmatically or by doing an attach to process) and be able to debug all threads, not just the current thread. > It seems quite complicated to implement the thread_id for > sys.settrace(trace_func, thread_id=None). Humm, isn't it just a matter of passing the proper tstate to _PyEval_SetTrace? It seems reasonably simple to do at C (i.e.: iterate the existing thread states to get the thread id and then pass the proper tsate to _PyEval_SetTrace -- which is roughly what is done in the debugger, although it's a bit more complicated because it supports Python 2.7 up to Python 3.8...). > At the C level, Python doesn't maintain a list of thread. There is only > threading.enumerate() which is implemented in Python. The tstate does contain the thread id, so, iterating the available tstates should be enough for that. > PyDev.Debugger seems to use the C API. Can it continue to use the C API? It can for CPython, but it can't for other Python implementations (and ideally I'd like to rely less on the CPython C-API -- because there's too much implementation details on it, things seem to break at each new version). > Note: There is threading.setprofile() and threading.settrace() which set a > profile/trace function when *new* threads are spawned Yes, I know about those, but it's not enough if the user attaches the debugger after the process is already running. -- ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Add _PyEval_SetTrace(tstate, func, arg) function
Fabio Zadrozny added the comment: >> As a note, the original request was for a Python-level tracing function (so >> that in the future other Python implementations also provide that function) >> -- does this need a PEP? > What do you mean by a Python-level tracing function? I mean that it's a function to be called from Python (not only from C) -- which hopefully could be adopted by other Python implementations in the long run. I.e.: something as adding a thread_id to sys.settrace -- sys.settrace(trace_func, thread_id=None). -- ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Add _PyEval_SetTrace(tstate, func, arg) function
Fabio Zadrozny added the comment: Holding the GIL is a reasonable constraint. As a note, the original request was for a Python-level tracing function (so that in the future other Python implementations also provide that function) -- does this need a PEP? -- ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Add _PyEval_SetTrace(tstate, func, arg) function
Fabio Zadrozny added the comment: I'm iterating on all threads and getting its thread id to find out the thread state (in my use case) and then doing what you just did there... So, while this solution does work for me, if the idea is making tstate opaque, then having (an optional) thread id in settrace (which iterates to find the proper thread if given) could solve it without having to rely on any CPython internals on my side (although it should probably return a bool to say if it did work then). -- ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Provide API to set the tracing function to be used for running threads.
Fabio Zadrozny added the comment: Maybe better would be the thread id so that the tstate structure is not needed there. -- ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Provide API to set the tracing function to be used for running threads.
Fabio Zadrozny added the comment: >> Note: currently there is a way to achieve that by pausing all the threads >> then selectively switching to a thread to make it current and setting the >> tracing function using the C-API (see: >> https://github.com/fabioz/PyDev.Debugger/blob/master/pydevd_attach_to_process/dll/attach.cpp#L1224), >> but I believe this is very hacky and not portable to other Python >> implementations. > I'm not sure that I understand your need. Do you need a variant of > PyEval_SetTrace() which accepts a tstate argument? Yes -- ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Provide API to set the tracing function to be used for running threads.
Fabio Zadrozny added the comment: I'd like to, but it only sets the tracing to the currently running thread (the request is for setting the tracing for other threads). Just for info, the problem I'm solving is that the debugger is multi-threaded, but the user can start the code without any tracing in place, and then, when it gets to an attach to process or a programmatic attach to the debugger, the debugger needs to set the tracing to threads that are already running (and any new thread created afterward) and Python doesn't really have any structure for that in place (so, I'm using the C-API as a workaround to do what PyEval_SetTrace does but targeting any thread). -- ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Provide API to set the tracing function to be used for running threads.
Fabio Zadrozny added the comment: As a note, the workaround is now in https://github.com/fabioz/PyDev.Debugger/blob/pydev_debugger_1_9_0/pydevd_attach_to_process/common/py_settrace_37.hpp#L150 -- ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39947] Make the PyThreadState structure opaque (move it to the internal C API)
Fabio Zadrozny added the comment: As a note, externally I have to use it in pydevd to set the tracing for different threads -- i.e.: https://bugs.python.org/issue35370 Will that still be possible? -- nosy: +fabioz ___ Python tracker <https://bugs.python.org/issue39947> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals
Fabio Zadrozny added the comment: @Mark First you have to explain to me how you envision changing the method code reliably in the debugger... Import hooks don't work (they'd break with something as simple as the code below) def method(): a = 10 mod = reload(old_mod) old_mod.method.__code__ = mod.method.__code__ using the tracing also doesn't work (it's too late to change the code) Note: consider the reload just an example, not the only use case (say, the user could pickle code objects to remote execution and the debugger should still work). Also, consider you have to change the bytecode of methods which are only internal to a function (and thus can't be accessed from the outside). Then, if you have a reliable way to do it, how do you keep track of those code objects to reapply the patching when breakpoints change? What if it adds a breakpoint to a new method, how do you locate it? Creating strong references to methods isn't an option because it would prevent things from being garbage collected (and you'd have to track all objects containing code objects for it to be reliable). As a note, pydevd does have some support for hot-reloading, but there are too many corner-cases and it doesn't work 100% for live coding (it's an unsolved problem is Python) -- and I can't really envision it working for regular breakpoints as there are too many corner cases to handle. -- ___ Python tracker <https://bugs.python.org/issue38500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals
Fabio Zadrozny added the comment: @Bret I don't really see a problem in breaking the API in major releases (so, having access for it in the internal API but without a backwards-compatibility guarantee seems like a good fit for me). -- ___ Python tracker <https://bugs.python.org/issue38500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals
Fabio Zadrozny added the comment: @Mark @Brett Well, PEP 523 still works (it's just more inconvenient to use now). Still, if PEP 523 will still be supported I think that having the setter/getter makes sense. If it is to be deprecated as @Mark is suggesting it doesn't really make sense to add it (but then, it should really be deprecated and ideally there'd be some replacement for the current debugger use... not sure about other use cases such as a jit, which was the initial target of PEP 523 -- @Mark, do you want to go that route/create a PEP to deprecate it so that this discussion takes place in a proper place?). p.s.: as a note, bytecode modification on the actual object is not a usable approach for the debugger because users could break that in real-world use cases (i.e.: what happens if the user creates a **new** code and sets it to the code which had the breakpoint? What about breakpoint changes? Right now the debugger evaluates all assumptions just before the frame is executed, so, it's easier to get things right -- the case you posted currently does what's expected on pydevd). Still, a callback before the execution so that it could change the frame code before it's executed without the remainder of PEP 523 would be enough (and maybe it could be adopted in other Python implementations too) -- actually, for the debugger it'd be awesome if the frame code could be changed from inside a trace call and then that stack would restart execution (close to what happens with setting the frame line to be executed), but I guess this would be a completely different request ;) p.s.: please don't reply to my previous p.s. here (let's move the discussion to another place -- either by @Mark creating a PEP for discussion or acknowledging the issue is ok given the current status quo). -- ___ Python tracker <https://bugs.python.org/issue38500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals
Fabio Zadrozny added the comment: @Mark I can think of many use-cases which may break if the function code is changed (users can change the code in real-use cases and when they do that they'd loose debugging). So, as long as the function code is part of the public API of Python, the debugger can't really change it for breakpoints (which is a bit different from the frame code, which the user can't really swap and it's not so common to change). -- ___ Python tracker <https://bugs.python.org/issue38500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals
Fabio Zadrozny added the comment: @Mark I don't want to change the original function code, I just want to change the code to be executed in the frame (i.e.: as breakpoints change things may be different). Changing the actual function code is a no-go since changing the real function code can break valid user code. -- ___ Python tracker <https://bugs.python.org/issue38500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals
Fabio Zadrozny added the comment: @Mark Shannon what I do is change the code object of the frame about to be evaluated to add a programmatic breakpoint, to avoid the need to have the trace function set at contexts that would need to be traced (after changing the frame.f_code it goes on to call the regular _PyEval_EvalFrameDefault), so, the user-code runs at full speed on all contexts (there's still added overhead on a function call to decide if the code object needs to be changed, but that'd happen on the regular tracing code too). Note that this does not change the semantics of anything as it calls the regular _PyEval_EvalFrameDefault, so, the worries you're listing shouldn't be a concern in this particular use-case. Also note that until Python 3.7 this was easy to change, and that's still possible in Python 3.8 (the only thing is that now it's less straightforward). Note that my use is much simpler that the original intent of the frame evaluator -- my use case could be solved by having a callback to change the code object before the frame execution -- but as far as I know, right now, the way to do that is through the frame evaluation API. -- ___ Python tracker <https://bugs.python.org/issue38500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38508] Tracing events anomaly when creating a multi-line list
Fabio Zadrozny added the comment: If it's a feature and not a bug, seems ok to me (I reported mainly because I thought the behavior was odd, but I guess it makes sense). -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38508] Tracing events anomaly when creating a multi-line list
New submission from Fabio Zadrozny : When creating a multi-line list it seems that there's an additional line event that goes back to the start of the list. i.e.: considering the code as: [ 1, 2 ] when stepping through the list, a debugger would get a line event at the `1` then at `2` and then at `['. I'm attaching a sample code which prints the traced lines, where it's possible to see that there's a line event that goes backward to the list creation there (note that on Python 3.7 there's no line event for the list creation). -- components: Interpreter Core files: snippet33.py messages: 354845 nosy: fabioz priority: normal severity: normal status: open title: Tracing events anomaly when creating a multi-line list type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file48665/snippet33.py ___ Python tracker <https://bugs.python.org/issue38508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals
New submission from Fabio Zadrozny : In CPython 3.7 it was possible to do: #include "pystate.h" ... PyThreadState *ts = PyThreadState_Get(); PyInterpreterState *interp = ts->interp; interp->eval_frame = my_frame_eval_func; This is no longer possible because in 3.8 the PyInterpreterState is opaque, so, Py_BUILD_CORE_MODULE needs to be defined defined and "internal/pycore_pystate.h" must be included to set PyInterpreterState.eval_frame. This works but isn't ideal -- maybe there could be a function to set PyInterpreterState.eval_frame? -- components: Interpreter Core messages: 354803 nosy: fabioz, vstinner priority: normal severity: normal status: open title: Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37416] If threading is not imported from the main thread it sees the wrong thread as the main thread.
New submission from Fabio Zadrozny : I'm attaching a snippet which shows the issue (i.e.: threading.main_thread() and threading.current_thread() should be the same and they aren't). What I'd see as a possible solution is that the initial thread ident would be stored when the interpreter is initialized and then when threading is imported the first time it would get that indent to initialize the main thread instead of calling `threading._MainThread._set_ident` in the wrong thread. I'm not sure if this is possible if CPython is embedded in some other C++ program, but it seems to be the correct approach when Python is called from the command line. As a note, I found this when doing an attach to pid for the `pydevd` debugger where a thread is created to initialize the debugger (the issue on the debugger is reported at: https://github.com/microsoft/ptvsd/issues/1542). -- components: Interpreter Core files: snippet.py messages: 346653 nosy: fabioz priority: normal severity: normal status: open title: If threading is not imported from the main thread it sees the wrong thread as the main thread. type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48438/snippet.py ___ Python tracker <https://bugs.python.org/issue37416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Provide API to set the tracing function to be used for running threads.
New submission from Fabio Zadrozny : Right now it's hard for debuggers to set the tracing function to be used for running threads. This would be really handy for debuggers when attaching to a running program to debug all threads. -- Note: currently there is a way to achieve that by pausing all the threads then selectively switching to a thread to make it current and setting the tracing function using the C-API (see: https://github.com/fabioz/PyDev.Debugger/blob/master/pydevd_attach_to_process/dll/attach.cpp#L1224), but I believe this is very hacky and not portable to other Python implementations. -- components: Interpreter Core messages: 330849 nosy: fabioz priority: normal severity: normal status: open title: Provide API to set the tracing function to be used for running threads. versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35370] Provide API to set the tracing function to be used for running threads.
Change by Fabio Zadrozny : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue35370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34799] When function in tracing returns None, tracing continues.
New submission from Fabio Zadrozny : https://docs.python.org/3/library/sys.html#sys.settrace explicitly states: The local trace function should return a reference to itself (or to another function for further tracing in that scope), or None to turn off tracing in that scope. Yet, it seems this happens only on the return of a 'call'. If None is returned in a 'line' event, apparently the previous tracing function is reused (but if a new function is returned, the new function is used properly). I'm attaching a test case which shows the issue. I've tested on 2.7, 3.6 and 3.7 and this issue is present on all. If I set frame.f_trace = None before returning it seems to work though (so, I think that either this behavior should be fixed or the docs should be updated to reflect that). -- files: issue_in_tracing_func.py messages: 326360 nosy: fabioz priority: normal severity: normal status: open title: When function in tracing returns None, tracing continues. type: behavior versions: Python 2.7, Python 3.6, Python 3.7 Added file: https://bugs.python.org/file47822/issue_in_tracing_func.py ___ Python tracker <https://bugs.python.org/issue34799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34099] Provide debuggers with a way to know that a function is exiting with an unhandled exception.
New submission from Fabio Zadrozny : Right now, debuggers can deal with handled exceptions by detecting the 'exception' event, but it's hard to know if the exception is handled or unhandled at that point (so, debuggers end up checking if it happens in a top-level function, but this isn't good if the user started the code and did a remote attach later on, where the top-level code is still user code). My suggestion would be creating another event type (such as 'exception_return') which would be issued after the 'return' event with the same information passed on the 'exception' info so that debuggers can detect that some exception is unhandled (the 'return' would still be issued as usual to minimize breakage to existing debuggers). Another option could be adding that information to the frame itself during a 'return' event (and then removing right after calling the debugger to avoid any cycles) -- although I think the other option is better to avoid making the frame bigger. -- components: Interpreter Core messages: 321492 nosy: fabioz priority: normal severity: normal status: open title: Provide debuggers with a way to know that a function is exiting with an unhandled exception. type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33621] repr(threading._DummyThread) always fails.
Fabio Zadrozny <fab...@users.sourceforge.net> added the comment: Actually, I tried on a more recent version of Python 3.6 (3.6.5) and it doesn't happen there (so, just happens in 3.6.0 -- i.e.: in the old conda env I had around). Sorry for the noise. Closing issue as it's already fixed. -- stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33621] repr(threading._DummyThread) always fails.
Fabio Zadrozny <fab...@users.sourceforge.net> added the comment: Python 3.6.0 |Continuum Analytics, Inc.| (default, Dec 23 2016, 11:57:41) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import threading >>> repr(threading._DummyThread()) Traceback (most recent call last): File "", line 1, in File "C:\tools\Miniconda\envs\pyqt5\lib\threading.py", line 819, in __repr__ self.is_alive() # easy way to get ._is_stopped set when appropriate File "C:\tools\Miniconda\envs\pyqt5\lib\threading.py", line 1115, in is_alive self._wait_for_tstate_lock(False) File "C:\tools\Miniconda\envs\pyqt5\lib\threading.py", line 1071, in _wait_for_tstate_lock assert self._is_stopped AssertionError -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33621] repr(threading._DummyThread) always fails.
New submission from Fabio Zadrozny <fab...@users.sourceforge.net>: Doing the following throws an exception: import threading repr(threading._DummyThread()) Or, in a more contrived example (I actually had this in a QThread, so, reproducing using getting the current_thread using a thread created with the _thread module): import threading import traceback finished = threading.Event() worked = [] def method(): try: repr(threading.current_thread()) worked.append(True) except: traceback.print_exc() worked.append(False) finally: finished.set() import _thread _thread.start_new_thread(method, ()) finished.wait() assert worked[0] -- components: Library (Lib) messages: 317430 nosy: fabioz priority: normal severity: normal status: open title: repr(threading._DummyThread) always fails. type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28597] f-string behavior is conflicting with its documentation
New submission from Fabio Zadrozny:
The file:
/Doc/reference/lexical_analysis.rst says that things as:
f"abc {a[\"x\"]} def" # workaround: escape the inner quotes
f"newline: {ord('\\n')}" # workaround: double escaping
fr"newline: {ord('\n')}" # workaround: raw outer string
are accepted in f-strings, yet, all those examples raise a:
SyntaxError: f-string expression part cannot include a backslash
The current Python version where this was tested is: 3.6.0b4
So, either those cases should be supported or lexical_analysis.rst should be
updated to say that '\' is not valid in the expression part of f-strings.
--
components: Interpreter Core
messages: 279992
nosy: fabioz
priority: normal
severity: normal
status: open
title: f-string behavior is conflicting with its documentation
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28597>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10933] Tracing disabled when a recursion error is triggered (even if properly handled)
Fabio Zadrozny added the comment: Well, I'd say that if tracing is enabled and is disabled automatically by Python (thus breaking a working debugger which would usually be used to diagnose the error), I'd at least consider issuing some warning to stderr... (probably warnings.warn cannot be used directly as the stack is at its max depth, but a choice could be raising the max depth, using warnings.warn and then restoring the max depth value in a try..finally -- or at least printing something to stderr regardless of warnings.warn). I.e.: as this is a rare situation and should only happen when you're debugging, I think printing something to stderr regarding that is definitely worth it regardless of chained exceptions (on many cases I had to help users instrument a simple tracer just to detect where it was disabled -- yes, on some of those they were catching all exceptions on some block -- so, program which worked with the recursion stopped having a working debugger). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1654367] [PATCH] Debuggers need a way to change the locals of a frame
Fabio Zadrozny added the comment: Hi Armin, That does make sense to me, but maybe it could be nice providing a standard API across Python implementations to make that call (even if the CPython version uses ctypes underneath and the PyPy version uses RPython), but I'll leave that up to CPython and PyPy devs to discuss -- so, for me, if that call is in the __pypy__ namespace, I'll do the proper check and use it in the PyDev debugger :) p.s.: no problem on putting my name on the test case (and distributing in whatever license PyPy or CPython is under). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1654367 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1654367] [PATCH] Debuggers need a way to change the locals of a frame
Fabio Zadrozny added the comment: Sure, no problems on my side :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1654367 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1654367] [PATCH] Debuggers need a way to change the locals of a frame
Fabio Zadrozny added the comment: Just a note for anyone interested: ctypes can be used to access that function: http://pydev.blogspot.com.br/2014/02/changing-locals-of-frame-frameflocals.html So, I think that the changes I proposed shouldn't be applied (it'd only be worth if someone provided an implementation that did frame.f_locals writable...). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1654367 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1654367] [PATCH] Debuggers need a way to change the locals of a frame
Fabio Zadrozny added the comment: Hi Armin, Sure, just attached the test case with tests failing (on the top, comment the save_locals(frame) which has a 'pass' to see it working). Mostly, it happens when editing something not in the top-frame (but sometimes I think it could fail there too, depending whether it's a cellvar or freevar). -- Added file: http://bugs.python.org/file33917/test_save_locals.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1654367 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11798] Test cases not garbage collected after run
Fabio Zadrozny fab...@users.sourceforge.net added the comment: Sure, will try to get a patch for next week... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11798] Test cases not garbage collected after run
Fabio Zadrozny fab...@users.sourceforge.net added the comment: So Michal, it seems no objections were raised? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11798] Test cases not garbage collected after run
New submission from Fabio Zadrozny fab...@users.sourceforge.net: Right now, when doing a test case, one must clear all the variables created in the test class, and I believe this shouldn't be needed... E.g.: class Test(TestCase): def setUp(self): self.obj1 = MyObject() ... def tearDown(self): del self.obj1 Ideally (in my view), right after running the test, it should be garbage-collected and the explicit tearDown wouldn't be needed (as the test would garbage-collected, that reference would automatically die), because this is currently very error prone... (and probably a source of leaks for any sufficiently big test suite). If that's accepted, I can provide a patch. -- components: Library (Lib) messages: 133225 nosy: fabioz priority: normal severity: normal status: open title: Test cases not garbage collected after run type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11798] Test cases not garbage collected after run
Fabio Zadrozny fab...@users.sourceforge.net added the comment: I do get the idea of the backward incompatibility, although I think it's really minor in this case. Just for some data, the pydev test runner has had a fix to clear those test cases for quite a while already and no one has complained about it (it actually makes each of the tests None after run, so, if someone tries to access it after that, it would be pretty clear that it's not there anymore). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11798] Test cases not garbage collected after run
Fabio Zadrozny fab...@users.sourceforge.net added the comment: The current code I use in PyDev is below -- another option could be not adding the None to the list of tests, but removing it, but I find that a bit worse because in the current way if someone tries to access it after it's ran, it'll become clear it was removed. def run(self, result): for index, test in enumerate(self._tests): if result.shouldStop: break test(result) # Let the memory be released! self._tests[index] = None return result I think the issue with the test result storing the test is much more difficult to deal with (because currently most unit test frameworks probably rely on having it there), so, that's probably not something I'd try to fix as it'd probably break many clients... in which case it should be expected that the test is kept alive if it fails -- but as the idea is that all has to turn green anyways, I don't see this as a big issue :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10933] Tracing disabled when a recursion error is triggered (even if properly handled)
New submission from Fabio Zadrozny fab...@users.sourceforge.net: It seems that tracing in the interpreter is lost after some recursion error is triggered (even if it's properly handled). This breaks any debugger working after any recursion error is triggered (which suppose shouldn't happen). The attached test case shows the problem in action. Tested the problem with Python 2.6.5 and 3.1.3 -- components: Interpreter Core files: recursion_error_disables_tracing.py messages: 126460 nosy: fabioz priority: normal severity: normal status: open title: Tracing disabled when a recursion error is triggered (even if properly handled) type: behavior versions: Python 2.6, Python 3.1 Added file: http://bugs.python.org/file20436/recursion_error_disables_tracing.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10933 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1654367] [PATCH] Debuggers need a way to change the locals of a frame
Fabio Zadrozny fab...@users.sourceforge.net added the comment: I agree that it'd be cleaner making the frame locals a dict-like object with write access, but I wouldn't be able to do that because of time constraints (and I'd have to research more how to do it and it'd be much more intrusive I guess). So, if it's guaranteed that it'll be accepted I can provide a patch (changing the clear to 1) of the savelocals() version. I guess I don't agree this falls in the language moratorium, but if that's the case I can wait 1 or 2 more years before submitting the patch :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1654367 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8943] Bug in InteractiveConsole
New submission from Fabio Zadrozny fab...@users.sourceforge.net: Unable to pickle classes used in the InteractiveConsole. The code attached works in python 2.5 and fails on python 3.1.2. -- components: Library (Lib) files: fast_test.py messages: 107328 nosy: fabioz priority: normal severity: normal status: open title: Bug in InteractiveConsole type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file17589/fast_test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5924] When setting complete PYTHONPATH on Python 3.x, paths in the PYTHONPATH are ignored
New submission from Fabio Zadrozny fab...@users.sourceforge.net: Setting the complete PYTHONPATH in Python 3.x does not work (reported initially for Pydev: https://sourceforge.net/tracker/index.php?func=detailaid=2767830group_id=85796atid=577329 ). Checked on 3.0.1 and 3.1a2. I'm not sure if the paths must be the same, but when I did change the path of the project, the bug was not always reproduced. I've reproduced it on Windows XP SP3. To reproduce, extract the ProjectStructure so that you have a path as c:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py Then considering your python install is at d:\bin\Python301, set the pythonpath as: [C:\temp]set pythonpath=C:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src;C:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_a\src;D:\bin\Python301;D:\bin\Python301\DLLs;D:\bin\Python301\lib;D:\bin\Python301\lib\plat-win;D:\bin\Python301\lib\site-packages And run the command below: [C:\temp]d:\bin\Python301\python.exe c:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py Running code is 'c:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py' The contents of 'sys.path' is: c:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src C:\WINDOWS\system32\python30.zip D:\bin\Python301\DLLs D:\bin\Python301\lib D:\bin\Python301\lib\plat-win D:\bin\Python301 D:\bin\Python301\lib\site-packages Traceback (most recent call last): File c:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py, line 11, in module from testmod_a import testfunc ImportError: No module named testmod_a Note how the module was not properly imported... Now, if the PYTHONPATH is set without the system folders: [C:\temp]set pythonpath=C:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src;C:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_a\src Running the command line: [C:\temp]d:\bin\Python301\python.exe c:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py Running code is 'c:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src\testcaller_a.py' The contents of 'sys.path' is: c:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src C:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_b\src C:\Documents and Settings\Fabio\Desktop\temp_pydev\ProjectStructure\proj_a\src C:\WINDOWS\system32\python30.zip D:\bin\Python301\DLLs D:\bin\Python301\lib D:\bin\Python301\lib\plat-win D:\bin\Python301 D:\bin\Python301\lib\site-packages 'test_print()' in testmod_a.testfunc is called. Properly works. Note that on Python 2.x this works. -- components: Interpreter Core, Windows files: ProjectStructure.zip messages: 87151 nosy: fabioz severity: normal status: open title: When setting complete PYTHONPATH on Python 3.x, paths in the PYTHONPATH are ignored type: behavior versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file13874/ProjectStructure.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5924 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5460] Python 3.0 grammar is ambiguous with the addition of star_expr
New submission from Fabio Zadrozny fab...@users.sourceforge.net:
Note: A discussion related to this bug was raised on:
http://mail.python.org/pipermail/python-dev/2009-March/086939.html
The following constructs are ambiguous in the Python 3.0 grammar:
arglist: (argument ',')*
(argument [',']
|'*' test (',' argument)* [',' '**' test]
|'**' test
)
argument: test [comp_for]
test: or_test
or_test: and_test
and_test: not_test
not_test: 'not' not_test | comparison
comparison: star_expr
star_expr: ['*'] expr
So, with that construct, having call(arglist) in a format:
call(*test), the grammar would find it to be consumed in the argument
construction (because of the star_expr) and not in the arglist in the
'*' test.
Python seems to be lucky in this because it seems to be getting in the
correct choice, when that's not really possible from the grammar --
maybe it tries the 2nd construct before the 1st and succeeds because of
that? It seems to me that this could actually be a bug in the Python
grammar generator.
It doesn't seem possible to disambiguate that without semantic actions
later on, but the grammar could be changed to disambiguate that.
I've used the constructs below in a JavaCC grammar successfully (and I
think Python could use the same constructs):
expr_stmt: testlist_star_expr (augassign (yield_expr|testlist) |
('=' (yield_expr|testlist_star_expr))*)
testlist_star_expr: (test|star_expr) (',' test|star_expr)* [',']
star_expr: '*' expr
--
components: Interpreter Core
message_count: 1.0
messages: 83395
nosy: fabioz
nosy_count: 1.0
severity: normal
status: open
title: Python 3.0 grammar is ambiguous with the addition of star_expr
type: feature request
versions: Python 3.0, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5460
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4716] Python 3.0 halts on shutdown when settrace is set
New submission from Fabio Zadrozny fab...@users.sourceforge.net:
In Python 3.0, the interpreter will not shutdown properly after setting
a tracing function and something goes into stdout.
The code attached shows the problem in action: just execute it and
notice how the interpreter will be kept running after the code has been
executed.
There are some more things that need to be considered:
- If the print('here') is not called, it will shutdown
- If BOTH the print('here') and the sys.settrace(None) is not called, it
will NOT shutdown
Note: I've marked the bug as crash because it's halting, but maybe there
could be a better alternative for it...
--
components: Interpreter Core
files: tracing_test.py
messages: 78169
nosy: fabioz
severity: normal
status: open
title: Python 3.0 halts on shutdown when settrace is set
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12422/tracing_test.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4716
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4717] execfile conversion is not correct
New submission from Fabio Zadrozny fab...@users.sourceforge.net: In 2to3, execfile(file, globals, locals) is translated to exec(open(file).read(), globals, locals) But that's not correct, as the actual file from the executed code gets wrong with that. The correct thing would be: exec(compile(open(file).read(), file, 'exec'), globals, locals) So that the name of the file remains correct in the module that's being run. -- components: 2to3 (2.x to 3.0 conversion tool) messages: 78170 nosy: fabioz severity: normal status: open title: execfile conversion is not correct versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
New submission from Fabio Zadrozny fab...@users.sourceforge.net: sys.exc_clear() does not seem to exist in Python 3.0 anymore, so, a way to deal with it should be provided (maybe put a #TODO comment and point to somewhere explaining what happened?). -- components: 2to3 (2.x to 3.0 conversion tool) messages: 78173 nosy: fabioz severity: normal status: open title: sys.exc_clear() not flagged in any way versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Fabio Zadrozny fab...@users.sourceforge.net added the comment: When created it was already marked as a 2to3 issue (in the components), so, for clarity, yes: it's a 2to3 issue (what should the user do with that when porting... I think that the 2to3 should do something regarding that... maybe just changing it for a 'pass'?). Also, the docs say it was removed, but they don't leave clear that it's not needed because no info is stored anymore (because that was needed just to clear the frame that was kept alive when an exception was raised -- so, note that I'm assuming that issue was fixed and it's not needed anymore, but the docs don't make that clear) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Fabio Zadrozny fab...@users.sourceforge.net added the comment: 2to3 doesn't deal with anything else that has been removed. That seems a bit odd for me... isn't it the perfect place for that? (it doesn't even need to change the code for a pass, but it could give the user some warning about it at that specific line -- maybe with a pointer to a place explaining why it was removed). I think that if 2to3 flags it, it can make the porting cycle faster than having to run the code (and expecting a huge code-coverage) to get those -- especially as sys.exc_clear is mostly used in cases where you are expecting some exception... and I believe not everyone gives as much emphasis for exception cases as they'd for the cases in the 'regular flow' ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4705] python3.0 -u: unbuffered stdout
Fabio Zadrozny fab...@users.sourceforge.net added the comment: Just as a note, Pydev needs the unbuffered output (or it cannot get it). This has been brought up in the python-dev list: http://mail.python.org/pipermail/python-dev/2008-December/084436.html As a workaround for now I'm using: sys.stdout._line_buffering = True, but that doesn't seem right as it's accessing an internal attribute. -- nosy: +fabioz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4289] Python 2.6 installer crashes when selecting 'advanced' and cancelling it
New submission from Fabio Zadrozny [EMAIL PROTECTED]: When installing python-2.6.msi it crashes when doing the following steps on a windows XP (32 bit). I'm not sure if all those steps are needed, but that's how it crashed here: - start python-2.6.msi - check 'install just for me' - change the destination directory (d:\bin\Python26) - click on 'advanced' - click on cancel - confirm cancel At this point windows presents a message: to help protect your computer, Windows has closed this program. -- components: Installation messages: 75653 nosy: fabioz severity: normal status: open title: Python 2.6 installer crashes when selecting 'advanced' and cancelling it type: crash versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4289 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3494] [Errno 11] Resource temporarily unavailable while using tracing facility/threads (in linux listdir with unicode path)
Fabio Zadrozny [EMAIL PROTECTED] added the comment: I've pasted the output below... also, the trace function is called for each function call after the settrace (not only in interpreter shutdown) -- and the error happens in the listdir -- which is in the main thread, so, it must happen before the interpreter shutdown. Also, one thing: it works if you read an empty folder... And putting: print frame.f_code.co_filename, frame.f_lineno in the 'func', it'll go on and print /usr/lib/python2.4/encodings/utf_8.py 15 /usr/lib/python2.4/encodings/utf_8.py 16 /usr/lib/python2.4/encodings/utf_8.py 16 For each file/dir available (so, it seems it's actually able to go on and get all the contents, but before returning, that exception is thrown) Output from running it: - /usr/bin/python Traceback (most recent call last): File /home/fabioz/test workspace with spaces/test project/src/mod1/mod2/listdir_problem.py, line 23, in ? print listdir(dir) OSError: [Errno 11] Resource temporarily unavailable: '/home/fabioz/jython' ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3494] [Errno 11] Resource temporarily unavailable while using tracing facility/threads (in linux listdir with unicode path)
Fabio Zadrozny [EMAIL PROTECTED] added the comment:
Thanks for looking into this...
Unfortunately, I'm not sure I can use the workaround of the int('0'), as
this could fix the debugger, but if the code that's being debugged
spawned other threads (which is pretty common), it would be pointless,
but at least clients that really want this can get that fix and apply it
to their python versions...
And I think that setting the errno to 0 in the debugger every time would
make other things misbehave, as in each python call it'd clear it (or
not? I'm not really aware of the implications of doing so -- but if no
one used it, it wouldn't be there, right?)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3494
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3494] [Errno 11] Resource temporarily unavailable while using tracing facility/threads (in linux listdir with unicode path)
New submission from Fabio Zadrozny [EMAIL PROTECTED]: A bug has been reported against pydev complaining about os.listdir() failing while debugging (with a unicode path). The link for that is: http://sourceforge.net/tracker/index.php?func=detailaid=2012138group_id=85796atid=577329 After trying to find its cause, it appears that pydev is exercising a python bug (which is reproduced in the file attached). I have no idea why that's happening. I've reproduced it in python 2.4 and python 2.5 under ubuntu 6.10, but I believe it happens on other versions too -- the original bug was reported in Ubuntu 8.04 AMD64 Hardy Heron) -- components: Interpreter Core, Library (Lib) files: listdir_problem.py messages: 70638 nosy: fabioz severity: normal status: open title: [Errno 11] Resource temporarily unavailable while using tracing facility/threads (in linux listdir with unicode path) type: crash versions: Python 2.4, Python 2.5 Added file: http://bugs.python.org/file11039/listdir_problem.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
