On Mon, Jul 7, 2014 at 5:15 AM, Roy Smith <r...@panix.com> wrote:
> In article <mailman.11552.1404673207.18130.python-l...@python.org>,
> Mark Lawrence <breamore...@yahoo.co.uk> wrote:
>
>> On 06/07/2014 19:48, Rick Johnson wrote:
>> >
>> > *Real* programmers possess keen detective that can root out
>> > bugs with nothing more than a few well placed print
>> > statements and some good old fashioned "eyeball analysis".
>> >
>>
>> In the 21st century real programmers are using the logging module so
>> they don't have to mess around.
>
> The problem with the logging module is you can configure it to do pretty
> much anything, which is another way of saying if it's not configured
> right (perhaps because you're running your application in an environment
> it wasn't designed for), your output disappears into the ether.
>
> I can't tell you how many times I've given up fighting with logging and
> just done "open("/tmp/x").write("my debugging message\n") when all else
> failed.
But the important thing is that you log. There's a VAST difference
between logging and interactive debugging: logging can debug something
that happened once and didn't recur, interactive debugging requires
that you create the problem on command. Have you ever had a bug where
someone else finds it and then doesn't give you full repro steps? Or
where you find it yourself and declare it intermittent? Proper logging
(and hey, Python's pretty helpful with exceptions) can mean that you
find that just by browsing backward.
There are times when you have to go for the "Real Programmer"
debugging style. Pretend the program is a black box, no source code
available, nothing. (Maybe that's because it really is like that, or
maybe it's just easier to strace a process and watch for the failures
than it is to hunt down the source code for the exact version you're
running.) Or pretend the code has no direct correlation to what
happens, owing to an interpreter bug. (Again, it really can be;
imagine a refcount bug in a Python C API function.) Debugging those
problems gives you an appreciation for the ease of "double-click the
line in the traceback, or hit F4, and go straight to the cause of the
error". Python gives us an insane amount of help (I say "insane"
because sometimes there have been performance questions surrounding
tracebacks), although at the end of the day, debugging is something
people. not tools, do. No matter how good Python's traceback handling
is, it becomes useless if you wrap everything in "try: ... except:
print('Something went wrong')". As Alice's father told her, a tool's
"intended function is almost beside the point. Ultimately it's only as
good as the person who wields it".
http://alice.wikia.com/wiki/Memory
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
