On Wed, Jul 31, 2013 at 12:17 PM, Somchai Smythe
<[email protected]> wrote:
> I can see this has become some kind of holy war, and I'm not going to
> play that game.
Really? I must have missed that part.
>
> This is the last relpy to this thread I'm going to make. I've already
> decided I'm going to force my students to man up and learn the
> built-in python debugger to avoid dealing with logic like this:
>
Did I offend you or something? I'm sorry if I did. I'm just trying to
express my opinion as I always do, in a civil way. I'm not dead set on
it. I'm willing to be convinced otherwise. In reality, I'm not yet
even convinced yet that any of the alternatives is the *right* way.
That's why we need to discuss it to figure it out.
But whatever. You're free to participate in the discussion or not. I'd
appreciate if you did if you have a strong opinion, so that we can see
your side of things, but no one is forcing you.
> "Sure you fixed it, but you didn't fix it in a good way"
> "Ok, show me how to fix it in a good way"
> "Well, uh, I don't have a better fix, but your fix is still not good enough"
> "So we revert a working fix because maybe someday somebody else will
> write a better fix?"
> "Yeah"
> "What do we do in the meantime?"
> "Crash and take it like a man!"
> "Aha! pass me the special kool-aid please...."
>
> Now for the serious part of the answer:
>
> #1 - if you install for python2 and 3, you must manually rename one of
> them. I chose to rename the python3 version to pudb3 for this
> example. I'm using stock
> pudb3-2013.1 version except for renaming the python3 file.
>
> Then debug a python2 program that uses print statement. Be wild, set
> a breakpoint on that print statement. Now use pudb3 version to debug
> something. Watch the crash. Remove by hand all config files. Repeat
> this every time you change from python2 to pyhthon3 debugging. Have
> 100 students ask you about it every time they crash, and have them ask
> questions like "If even the debugger crashes, why do we waste time on
> python?" and try to lamely convince them the developers really care
> about the user experience. So I sent a patch that fixes these
> problems. Clearly you all don't switch between python version2 to 3
> with the same user, or you'd hit this kind of thing often.
So do you see any issues with using pudb3 if it's there otherwise using pudb?
I may have overreacted on this whole thing, and it's possible the
current way of doing it is right. I was just a little shocked when I
started pudb in Python 3 and everything was in blue.
My point though is that I'm starting to see Python 3 less and less as
a different language from Python 2 and more as just a different
version of the same language, no different from Python 2.6 vs. 2.7 or
3.2 vs. 3.3 (each of which also have syntactically incompatible
changes by the way). Should we have pudb2.6 and pudb2.7 to distinguish
from the two? It's a problem that I think Python in general doesn't
solve very well, so we are left to stumble around our own hacky
solutions.
Aaron Meurer
>
> pudb3 hi3.py
> Traceback (most recent call last):
> File "/usr/bin/pudb3", line 9, in <module>
> load_entry_point('pudb==2013.1', 'console_scripts', 'pudb')()
> File "/usr/lib/python3.3/site-packages/pudb/run.py", line 30, in main
> steal_output=options.steal_output)
> File "/usr/lib/python3.3/site-packages/pudb/__init__.py", line 24,
> in runscript
> dbg = _get_debugger(steal_output=steal_output)
> File "/usr/lib/python3.3/site-packages/pudb/__init__.py", line 12,
> in _get_debugger
> dbg = Debugger(**kwargs)
> File "/usr/lib/python3.3/site-packages/pudb/debugger.py", line 151,
> in __init__
> for bpoint_descr in load_breakpoints():
> File "/usr/lib/python3.3/site-packages/pudb/settings.py", line 402,
> in load_breakpoints
> return parse_breakpoints(lines)
> File "/usr/lib/python3.3/site-packages/pudb/settings.py", line 368,
> in parse_breakpoints
> if get_breakpoint_invalid_reason(filename, lineno) is None:
> File "/usr/lib/python3.3/site-packages/pudb/lowlevel.py", line 48,
> in get_breakpoint_invalid_reason
> if lineno not in get_executable_lines_for_file(filename):
> File "/usr/lib/python3.3/site-packages/pudb/lowlevel.py", line 23,
> in get_executable_lines_for_file
> codes = [compile("".join(getlines(filename)), filename, "exec")]
> File "/home/bozo/hi.py", line 3
> print "hello, world!"
> ^
> SyntaxError: invalid syntax
>
>
> On 7/31/13, Andreas Kloeckner <[email protected]> wrote:
>> Somchai Smythe <[email protected]> writes:
>>> I will concede without a fight. I look forward to using that changes
>>> from Aaron's patch in the next release that permit python2 and python3
>>> to both work with different configurations using the same
>>> configuration file. I know you wouldn't email me suggesting a revert
>>> unless he had already submitted a better solution, and that means
>>> everybody wins and no fighting is required. I just want a solution
>>> that works, and I don't care who wrote it. :-D
>>
>> Just to be clear--there isn't a patch yet (other than "git revert
>> <somchai's changes>"). I'd like to hear your (Somchai's) reasoning for
>> wanting this in the first place. I can see where Aaron is coming from,
>> so I'm leaning towards reverting the change outright.
>>
>> Andreas
>>
_______________________________________________
Pudb mailing list
[email protected]
http://lists.tiker.net/listinfo/pudb
