Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74033 > unrolled thread

How do you use `help` when write your code

Back to article view | Back to comp.lang.python

Contents

  How do you use `help` when write your code Shiyao Ma <i@introo.me> - 2014-07-07 00:36 +0800
    Re: How do you use `help` when write your code Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-06 17:52 +0000
      Re: How do you use `help` when write your code Tim Chase <python.list@tim.thechases.com> - 2014-07-06 13:22 -0500
      Re: How do you use `help` when write your code Roy Smith <roy@panix.com> - 2014-07-06 14:48 -0400
    Re: How do you use `help` when write your code Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-06 11:48 -0700
      Re: How do you use `help` when write your code Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-06 19:58 +0100
        Re: How do you use `help` when write your code Roy Smith <roy@panix.com> - 2014-07-06 15:15 -0400
          Re: How do you use `help` when write your code Chris Angelico <rosuav@gmail.com> - 2014-07-07 08:54 +1000
            Re: How do you use `help` when write your code Roy Smith <roy@panix.com> - 2014-07-06 20:52 -0400
              Re: How do you use `help` when write your code Chris Angelico <rosuav@gmail.com> - 2014-07-07 13:06 +1000
                Re: How do you use `help` when write your code Roy Smith <roy@panix.com> - 2014-07-07 07:22 -0400
                  Re: How do you use `help` when write your code Chris Angelico <rosuav@gmail.com> - 2014-07-07 21:36 +1000
          Re: How do you use `help` when write your code Cameron Simpson <cs@zip.com.au> - 2014-07-07 11:51 +1000

#74033 — How do you use `help` when write your code

Hi Pythonistas

I often heard people mention use help(ob) as a way of documentation
look up. Personally I seldom/never do that. My normal workflow is use
ipython, obj? or obj?? for quick look up or use docs.python.org for a
detailed read.


Do you use `help`? How does it integrate into your workflow?

Or instead, what similar tools do you use?


Regards.

shiyao

-- 

吾輩は猫である。ホームーページはhttp://introo.me。

[toc] | [next] | [standalone]

#74037

On Mon, 07 Jul 2014 00:36:23 +0800, Shiyao Ma wrote:

> Hi Pythonistas
> 
> I often heard people mention use help(ob) as a way of documentation look
> up. Personally I seldom/never do that. My normal workflow is use
> ipython, obj? or obj?? for quick look up or use docs.python.org for a
> detailed read.
> 
> Do you use `help`? How does it integrate into your workflow?


I frequently use the help() function. 

(By the way, a little trivia for you: although the help function is in 
the built-in namespace, it is not actually a built-in! When you start 
Python interactively, the site.py script runs automatically, creates the 
help() function, and monkey-patches it into the builtins namespace.)

I rarely use ipython, I use the regular Python interactive interpreter, 
so obj? and obj?? aren't an option.

My usual workflow is to have at least one Python interpreter open at all 
times. If I don't remember the parameters for a method or function, I'll 
call help(class.method) or help(function). If I'm not sure what the 
method is called, I'll usually call help(class) or help(module). If there 
are too many things in the class or module, I'll use dir() to inspect it 
first. I have a monkey-patched version of dir() which takes a second 
argument, a glob, to filter the list of names returned:

py> len(dir(os))  # Too much!
312
py> dir(os, 'env')
['_putenv', '_unsetenv', 'environ', 'environb', 'getenv', 'getenvb', 
'putenv', 'supports_bytes_environ', 'unsetenv']
py> dir(os, 'env*')
['environ', 'environb']



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#74040

On 2014-07-06 17:52, Steven D'Aprano wrote:
> I have a monkey-patched version of dir() which takes a second
> argument, a glob, to filter the list of names returned:
> 
> py> len(dir(os))  # Too much!
> 312
> py> dir(os, 'env')
> ['_putenv', '_unsetenv', 'environ', 'environb', 'getenv',
> 'getenvb', 'putenv', 'supports_bytes_environ', 'unsetenv']
> py> dir(os, 'env*')
> ['environ', 'environb']

And for those of us that don't have Steven's monkey-patched dir()
call, I tend to do it with a list comprehension:

 >>> [s for s in dir(obj) if 'env' in s]
 {output here}

This works nicely for even more complex tests:

 >>> [s for s in dir(obj) if not s.startswith('_')]
 {list of public properties/methods}
 >>> [s for s in dir(obj) if callable(getattr(obj, s))]
 {list of callable attributes}
 >>> [s for s in dir(obj) if isinstance(getattr(obj, s), basestring)]
 {list of string attributes}

-tkc

[toc] | [prev] | [next] | [standalone]

#74044

In article <53b98cf2$0$29985$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> I have a monkey-patched version of dir() which takes a second 
> argument, a glob, to filter the list of names returned:

Neat idea, but globs are for wimps.  All the cool kids are using 
regexes.  See that other thread over there ==>

[toc] | [prev] | [next] | [standalone]

#74043

On Sunday, July 6, 2014 11:36:23 AM UTC-5, Shiyao Ma wrote:
> I often heard people mention use help(ob) as a way of
> documentation look up. Personally I seldom/never do that.
> My normal workflow is use ipython, obj? or obj?? for quick
> look up or use docs.python.org for a detailed read. Do you
> use `help`? How does it integrate into your workflow? Or
> instead, what similar tools do you use?

For me i use a very simple graphical IDE for writing code,
and i have a Python interactive console for testing snippets
here or there when needed.

I just abhor bloatware like Eclise! I also have no use for
debuggers or line breaks or any of that childish nonsense.
*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".

Besides, writing rock solid interfaces is prerequisite for
programmer happiness. That means type checking inputs to
function and classes so you don't propagate errors ten miles
from the source of the problem before they get raised by
Python (Tkinter i'm looking at angrily you now!), then you
spend two day analyzing miles of implicit trace-back messages
only to find out a parameter was illegal and could have been
caught at input!

    ARE YOU KIDDING ME!

And, as Mr.D'Aprano has stated, many of the built-in
functions like "dir" are in need of refining. But i go a
step further than mere monkey patching, and have decided long
ago that too much of the introspection of Python is broken
in ways that can only be repaired via an "introspection
mini-language", which i have incorporated directly into my
custom shell. Besides, who really enjoys typing 

    help(obj)
    
or 

    dir(obj)
   
Both of those function require more effort to type than the
information for which they provide, much of which is too
verbose anyhow. I mean really, what is GvR's excuse for not
adding some filtering to "dir"? He could do it in a
backwards compatible manner, but no, he refuses, and instead,
decides to fracture a community over a print function!

    BUT I DIGRESS!

And i've never used ipyhon, but if that question mark does
what i think it does then i'm yet again reminded that "great
minds do, in fact, think alike"!

What i'm saying is that the built-in functions of "help",
"dir", "type", "id", "repr", "str", etc... are "enough" for
the neophyte however they are woefully inadequate for a
pythonista like myself.

In fact, the more i use this language the more i realize how
much i need to change to make it useful for me, which
reminds me that i need to get cracking on that fork again.
Although i don't know why i bother to mention that fork
anyway since it will most likely be my little private toy
anyway. I have yet to be convinced that this community
deserves any of my contributions, and instead, they will
suffer my grievances.

[toc] | [prev] | [next] | [standalone]

#74046

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.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#74049

In article <mailman.11552.1404673207.18130.python-list@python.org>,
 Mark Lawrence <breamoreboy@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.

[toc] | [prev] | [next] | [standalone]

#74062

On Mon, Jul 7, 2014 at 5:15 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.11552.1404673207.18130.python-list@python.org>,
>  Mark Lawrence <breamoreboy@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

[toc] | [prev] | [next] | [standalone]

#74064

In article <mailman.11564.1404687291.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> But the important thing is that you log.

I 'spose.  Let's see.  Yesterday we generated 133 GB of log files.  And 
Sunday is a slow day :-)

> Have you ever had a bug where someone else finds it and then doesn't 
> give you full repro steps?

Are there people like that where you are?  Weird.

> 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.

Yup; strace and tcpdump are two of my best friends.  The source code 
only tells you what the program is *supposed* to do.  Strace tells you 
what it did.  And tcpdump tells you what it said.

[toc] | [prev] | [next] | [standalone]

#74071

On Mon, Jul 7, 2014 at 10:52 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.11564.1404687291.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>
>> But the important thing is that you log.
>
> I 'spose.  Let's see.  Yesterday we generated 133 GB of log files.  And
> Sunday is a slow day :-)

Heh, that's a bit bigger in scale than most of what I work with... but
yes. I have a log file of the from and to addresses of every email
that goes through my spam filter, and whether it was marked spam or
ham; the expectation is that any mail that doesn't bounce (the server
will reject prior to this log based on certain rules) will be in the
log, so if anyone asks about something, I can grep the log for an
address. It's a fairly compact log, and this is a fairly small site,
so the growth is a lot slower than 133GB/day! But the principle's the
same: log today so you can find a problem tomorrow.

>> Have you ever had a bug where someone else finds it and then doesn't
>> give you full repro steps?
>
> Are there people like that where you are?  Weird.

Yes, sadly, there are people just about everywhere.

(Despite my post being in response to one of yours, Roy, I still
partly felt that I was addressing Rick. Hence the slightly odd wording
of something that, for most of us, is a "duh" matter.)

>> 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.
>
> Yup; strace and tcpdump are two of my best friends.  The source code
> only tells you what the program is *supposed* to do.  Strace tells you
> what it did.  And tcpdump tells you what it said.

That's about it, yeah. I tend to find both strace and tcpdump rather
too spammy for most usage, so any time I reach for those tools, it's
usually with some tight filtering - and even that's not always
helpful. The last thing I straced was a (closed-source) game that was
having some problems (cross-platform, I'm one of a very small number
of Linux testers), and it was running at well over 100 FPS... and each
frame involved quite a few system calls. Yeah, that was spammy.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74094

In article <mailman.11570.1404702375.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:
 
> That's about it, yeah. I tend to find both strace and tcpdump rather
> too spammy for most usage, so any time I reach for those tools, it's
> usually with some tight filtering - and even that's not always
> helpful.

Usually, when I fire up strace, it's because I'm looking for something 
specific.  A common use case is, "I just edited this config file, but it 
doesn't seem to be having any effect".  I'll do something like "strace 
-e file" and grep out all the open() calls.  From there, it's trivial to 
verify that it is indeed reading my config file (or not).  Or that 
there's other config files (/usr/share/whatever) that it's reading that 
I didn't even know existed, which might be overriding my own.  Likewise 
for which libraries it's linking against, which executables it's 
running, etc.

[toc] | [prev] | [next] | [standalone]

#74095

On Mon, Jul 7, 2014 at 9:22 PM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.11570.1404702375.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>
>> That's about it, yeah. I tend to find both strace and tcpdump rather
>> too spammy for most usage, so any time I reach for those tools, it's
>> usually with some tight filtering - and even that's not always
>> helpful.
>
> Usually, when I fire up strace, it's because I'm looking for something
> specific.  A common use case is, "I just edited this config file, but it
> doesn't seem to be having any effect".  I'll do something like "strace
> -e file" and grep out all the open() calls.  From there, it's trivial to
> verify that it is indeed reading my config file (or not).  Or that
> there's other config files (/usr/share/whatever) that it's reading that
> I didn't even know existed, which might be overriding my own.  Likewise
> for which libraries it's linking against, which executables it's
> running, etc.

Yep. Sometimes it's fairly easy. I was trying to figure out where
rdesktop was looking for its keymaps, and rather than hunt down the
source, I just straced it and watched for errors, and found that it
was looking for ~/.rdesktop/keymaps, so I made that as a symlink to
what I wanted. (I'm sure I could have found this somewhere in the
docs, but after a small amount of searching, I didn't have any
indication of where; and for this job, I needed it to be local, rather
than in a root-owned directory.) That one was pretty straight-forward.
The time I was trying to trace that game, though, I was trying to
figure out why it was unable to save screenshots; and since the most
likely cause was an incorrect path name, I couldn't search for the
path. Had to negate the search - run the trace, then filter out
everything that looks like the one most common line, rinse and repeat
until it's silent. Then hit the screenshot key. Whoops, filtered out
too much, didn't see a thing.... weaken the filters, start again.
Would have liked source code for THAT one! A simple line of "write my
parameters to stderr" would have done the job.

At the end of the day, it's just another tool in the box. You learn to
use it because there are times when it's the right one for the job.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74068

On 06Jul2014 15:15, Roy Smith <roy@panix.com> wrote:
>In article <mailman.11552.1404673207.18130.python-list@python.org>,
> Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> 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.

Indeed. I have a cs.logutils module, which is almost entirely support for the 
logging module (standard setups, funky use cases), but it also defines two 
functions, X and D, thus:

     def X(fmt, *args):
       msg = str(fmt)
       if args:
         msg = msg % args
       sys.stderr.write(msg)
       sys.stderr.write("\n")
       sys.stderr.flush()

     def D(fmt, *args):
       ''' Print formatted debug string straight to sys.stderr if D_mode is true,
           bypassing the logging modules entirely.
           A quick'n'dirty debug tool.
       '''
       global D_mode
       if D_mode:
         X(fmt, *args)

I use X() for ad hoc right now debugging and D() for turn on at need debugging.

Surprisingly handy. Many many of my modules have "from cs.logutils import X, D" 
at the top.

Cheers,
Cameron Simpson <cs@zip.com.au>

"How do you know I'm Mad?" asked Alice.
"You must be," said the Cat, "or you wouldn't have come here."

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web