[issue17971] Weird interaction between Komodo Python debugger C module Python 3
Eric Promislow added the comment:
I found a workaround in our debugger code, so you can lower the priority on
this, or even mark it Wontfix, although I still
think the frame stack is getting messed up.
One thing about our debugger, it essentially runs all the Python code in a big
exec statement, and this particular code contains its own exec stmt. The stack
looks wrong after we finish the inner exec statement.
So if you're looking for a repro, that might be the way to go. However
I can break at line 10 in the following code with no problem using pdb (Py 3):
1 #!/usr/bin/env python3
2
3 def inner_f(a, b):
4 ns2 = {c: 7, a:a, b:b, tot:None }
5 exec(tot = a + b + 1 + 100 * c, ns2)
6 return ns2['tot']
7
8 ns1 = {c: 5, inner_f: inner_f, res:None }
9 exec(res = inner_f(3, 4) + 10 * c, ns1)
10 print(After all that, res: %d % (ns1['res'],))
11 print(Stop here)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17971
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17971] Weird interaction between Komodo Python debugger C module Python 3
New submission from Eric Promislow:
While much of Komodo's source code has been released under MIT/GPL/LGPL, the
Python debugger hasn't, so I can't post it here. We can work out an
arrangement later, although it might not be necessary once I describe
the problem:
Komodo's Python debugger was a pure-Python debugger, based on pdb. To make it
possible to debug the Chandler app, one of the components was written in C
against the CPython API, for performance, and all was good.
With Python 3, breakpoints no longer work after an exec with an explicit
globals arg, where globals is a user-supplied dict, not globals() or
locals(). For example, in this code:
print(I'm line 1)
namespace = {}
exec(a = 42, namespace)
print(I'm line 4)
print(Done)
Set breakpoints at lines 1 and 4. Start the debugger in
Run mode (stops at first breakpoint). The debugger
stops at line 1. Press continue. The debugger runs to
end, without stopping.
If the namespace arg to exec is deleted, or replaced with
globals() or locals(), (quotes are typographic, not literal),
the breakpoint at line 4 is honored. It only fails when globals
is set to a new dict.
Additionally, if the namespace is defined like so:
namespace = {DBGPHide: 1}, the breakpoint is honored.
The debugger marks its internal frames with directives like
DBGPHide to avoid stepping into them. Yes, it's a hack.
Adding more diagnostics to the C file shows that the first
time the debugger finds a frame with a global named DBGPHide,
__name__ is dbgp.common. This makes sense, because that
module sets DBGPHide to 1, but after every other time, __name__ is __main__ ,
and DBGPHide isn't set on it.
I had a look at the implementation of exec in Python 3.3 in
bltinmodule.c and ceval.c, but don't see anything obvious.
Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=98951
--
components: Interpreter Core
messages: 189183
nosy: ericp
priority: normal
severity: normal
status: open
title: Weird interaction between Komodo Python debugger C module Python 3
type: behavior
versions: Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17971
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17971] Weird interaction between Komodo Python debugger C module Python 3
Eric Promislow added the comment: I'm running it inside gdb to see if I can figure it out. I don't see a way of isolating this from the whole product. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17971 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17568] re: Infinite loop with repeated empty alternative
New submission from Eric Promislow:
import re
p = re.compile(r'^(?:\\|.|)*?', re.S|re.M)
s = 'sub foo {\n\tprint \n\t\tbar\n\t\t;\n}\n'
m = p.findall(s)
Python doesn't return.
Dropping the last | in the pattern fixes this.
Regex engines in Perl, PHP, JS, and Ruby all handle
this regex. Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=98268
--
messages: 185474
nosy: ericp
priority: normal
severity: normal
status: open
title: re: Infinite loop with repeated empty alternative
type: enhancement
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17568
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13723] Regular expressions: (?:X|\s+)*$ takes a long time
New submission from Eric Promislow er...@activestate.com: This regular expression takes a few seconds to be evaluated against any text: (.*?)((?:X|\s+)*)$ This reg ex is much faster: (.*?)((?:X|\s)*)$ To be fair, Ruby's performance with the first regex is the same as Python's. PHP and JavaScript both fail to match the first regex at all. Only Perl evaluates both regexes nearly instantly. -- messages: 150770 nosy: ericp priority: normal severity: normal status: open title: Regular expressions: (?:X|\s+)*$ takes a long time type: performance versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12878] io.StringIO doesn't provide a __dict__ field
New submission from Eric Promislow er...@activestate.com: I see that going from Python 3.1.1 to 3.1.2 instances of io.StringIO no longer have a __dict__ field. Why? Is this to make them unpicklable? -- components: IO messages: 143344 nosy: ericp priority: normal severity: normal status: open title: io.StringIO doesn't provide a __dict__ field type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12878 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10204] exec string fails with trailing whitespace
New submission from Eric Promislow er...@activestate.com:
The following code throws an exception in Python 3.1 (and 3.2 alpha),
but runs with 2.x:
exec('if True:\nprint(Hello)\n\n')
Traceback (most recent call last):
File stdin, line 1, in module
File string, line 4
SyntaxError: invalid syntax
This is with Python 3.1.1.2, but I can repro it with a 3.2 alpha
as well.
Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=88566
--
components: Interpreter Core
messages: 119640
nosy: ericp
priority: normal
severity: normal
status: open
title: exec string fails with trailing whitespace
versions: Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10204
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9274] code.InteractiveInterpreter fails to change locals when invoked in a function
New submission from Eric Promislow er...@activestate.com: Similar to bug http://bugs.python.org/issue5215 which found a workaround in pdb. Here I want to use code.InteractiveInterpreter to modify code interactively (see Komodo bug http://bugs.activestate.com/show_bug.cgi?id=87405 ) I can do this at the top-level, but not inside a function. The attached file shows the problem: -- components: Interpreter Core files: bug87405a.py messages: 110464 nosy: ericp priority: normal severity: normal status: open title: code.InteractiveInterpreter fails to change locals when invoked in a function type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file18029/bug87405a.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9274 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9274] code.InteractiveInterpreter fails to change locals when invoked in a function
Eric Promislow er...@activestate.com added the comment: I've modified the bug status so anyone can read it. You don't need an account to read ActiveState bugs, only to add or comment on one. Please note that I closed bug http://bugs.activestate.com/show_bug.cgi?id=87405, as we're now writing to frame-f_localsplus[] to make sure changes to locals stick. I logged a different bug on Komodo's dependence on this bug at http://bugs.activestate.com/show_bug.cgi?id=87417 - Here's how we run into this bug: In Komodo, while you're debugging, you can push an interactive shell, that uses the current state of the program. We build each block of code the user types in a variable called source, and try executing it like so: code.InteractiveInterpreter(locals()).runsource(source, console) In other words, we're letting the Python core do all the heavy lifting identifying multi-line stmts, indented blocks, etc. We've had problems with modifying local variables in the Python debugger for years (almost a decade now). I got a C extension working using frame-f_localsplus to make sure modifications are persisted, but noticed that changes in the interactive shell weren't being persisted. I distilled the code we use into the attached file, which shows that changes aren't being persisted here. I'm not an expert on core internals, but I suspect that python code locals() maps to C code frame-f_locals, and we still have the problem that inside functions, frame-f_locals is a temporary object that is rebuilt on each access. From what I've observed, frame-f_localsplus points to the actual items, and these are the pointers that need to be changed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9274 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9274] code.InteractiveInterpreter fails to change locals when invoked in a function
Eric Promislow er...@activestate.com added the comment: Thanks for the response. Note that our use case *is* to implement Python-console functionality, but sometimes we do this in the context of a currently running Python program, inside a function. That's why I wrote the repro that way. Using code.InteractiveInterpreter(locals()).runsource(...) in a function corresponds to interacting with the debugger in a function, while the second call to runsource() corresponds to interacting with the program when it's stepping through top-level code. Keep in mind that all of this takes place while control flow of the main program is stuck in the debugger's read-eval-print loop. It would be useful if there was a way of accessing the localsplus container in Python code -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9274 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9274] code.InteractiveInterpreter fails to change locals when invoked in a function
Eric Promislow er...@activestate.com added the comment: David, that won't work for a reason I'll get into in a bit. I would drop the priority of this ... Komodo has a had a Python debugger since late 2000, we only fixed updating variables while debugging (using the variable viewer) yesterday, and received fewer than 10 complaints about that over the years. While looking at the code, something seemed wrong with our handling of the variables in the interactive shell. I tested it, and it failed, and then wrote the standalone Python code to isolate the problem. Your solution will work sometimes, but not completely. When you're in interactive mode while debugging, you can type arbitrary Python code, but can also use the variable viewer in the UI to change variables. These two functions are handled by different code paths. My recommendation is to resolve this as a limitation, and document the module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9274 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8206] 2to3 doesn't convert 'types.InstanceType' to 'object'
New submission from Eric Promislow er...@activestate.com: Title should be self-explanatory. -- components: 2to3 (2.x to 3.0 conversion tool) messages: 101543 nosy: ericp severity: normal status: open title: 2to3 doesn't convert 'types.InstanceType' to 'object' versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8206] 2to3 doesn't convert 'types.InstanceType' to 'object'
Eric Promislow er...@activestate.com added the comment: I'm working on a debugger, trying to identify instances of old-style classes in Python 2, and any class in Python 3. The getattr formulation will work, but because I already need to maintain an is_v3 flag, I might as well use it here. As a side note, how are instances of new-style classes in v2 categorized? This v2 code prints 'None': import types def get_type_name(target_type): for t in dir(types): if target_type == getattr(types, t): return t class C(object): pass c = C() print get_type_name(type(c)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6537] string.split shouldn't split on non-breaking spaces
Eric Promislow er...@activestate.com added the comment: Thanks. For the record, I want textwrap.TextWrapper(..., break_long_words=False) or it will break after a non-breaking space if that gives an optimum length. -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6496] 2to3 generates from urllib.parse import pathname2url
Eric Promislow er...@activestate.com added the comment: Not in Sridar's patch, but 'pathname2url' is also misspelled as 'pahtname2url' in the MAPPING struct. -- nosy: +ericp ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6506] lib2to3 fails to convert 'thread' when not followed by a period
New submission from Eric Promislow er...@activestate.com:
Given this code:
import thread
print thread
$ python
ActivePython 2.6.1.1 (ActiveState Software Inc.) based on
Python 2.6.1 (r261:67515, Dec 5 2008, 13:58:38) [MSC v.1500 32 bit
(Intel)] on
win32
from lib2to3.main import main
print open(flip2.py).read()
import thread
print thread
main('lib2to3.fixes', ['flip2.py'])
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- flip2.py (original)
+++ flip2.py (refactored)
@@ -1,2 +1,2 @@
-import thread
-print thread
+import _thread
+print(thread)
RefactoringTool: Files that need to be modified:
RefactoringTool: flip2.py
0
Note how thread in the print statement is not converted.
--
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90635
nosy: ericp
severity: normal
status: open
title: lib2to3 fails to convert 'thread' when not followed by a period
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6506
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6506] lib2to3 fails to convert 'thread' when not followed by a period
Eric Promislow er...@activestate.com added the comment: Understood. Could the tool emit a warning when it encounters something like this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6506 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6126] Python 3 pdb: shows internal code, breakpoints don't work
Eric Promislow er...@activestate.com added the comment: Similar problem with 3.1rc1: C:\...c:\Python31rc1\python.exe -m pdb hello01.py --Return-- c:\python31rc1\lib\encodings\cp437.py(19)encode()-b'Hello' - return codecs.charmap_encode(input,self.errors,encoding_map)[0] (Pdb) b 2 *** Blank or comment (Pdb) b hello01.py:2 Breakpoint 1 at c:\...\hello01.py:2 (Pdb) b Num Type Disp Enb Where 1 breakpoint keep yes at c:\...\hello01.py:2 (Pdb) c Hello here bye The program finished and will be restarted --Return-- c:\python31rc1\lib\encodings\cp437.py(19)encode()-b'Hello' - return codecs.charmap_encode(input,self.errors,encoding_map)[0] (Pdb) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6126] Python 3 pdb: shows internal code, breakpoints don't work
New submission from Eric Promislow er...@activestate.com: I have a simple test file, test01.py, with this output: $ cat test01.py #!/usr/bin/env python print(Line 1) print(Line 2) print(Line 3) $ $ # Now try debugging it. $ python3.0 -mpdb test01.py --Return-- /home/ericp/opt/Python-3.0.1/lib/python3.0/io.py(762)closed()-False - return self.raw.closed (Pdb) b test01.py:4 Breakpoint 1 at /home/ericp/lab/Python-3.0.1/test01.py:5 (Pdb) r --Return-- /home/ericp/opt/Python-3.0.1/lib/python3.0/io.py(1471)closed()-False - return self.buffer.closed (Pdb) c line 1 line 2 line 3 The program finished and will be restarted Two main problems: 1. I shouldn't see the code for io.py 2. The program doesn't stop at the breakpoint, because that stack frame is exposed to bdb as (file:string, line:4), not (file:/home/.../test01.py, line:4). -- components: Interpreter Core messages: 88431 nosy: ericp severity: normal status: open title: Python 3 pdb: shows internal code, breakpoints don't work type: behavior versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
