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 do
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 suppor
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/issue42
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/issu
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
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
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' *
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 at
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 trac
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
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
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/issue35
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/Py
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
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.
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
<ht
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
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
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
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
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
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
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 -&g
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
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 Py
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
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
Change by Fabio Zadrozny :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue35370>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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
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
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 inform
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
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')}" # wo
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
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
Fabio Zadrozny added the comment:
Sure, no problems on my side :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1654367
___
___
Python-bugs
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
59 matches
Mail list logo
