[HN Gopher] The features of Python's help() function
       ___________________________________________________________________
        
       The features of Python's help() function
        
       Author : danso
       Score  : 52 points
       Date   : 2025-03-05 14:07 UTC (2 days ago)
        
 (HTM) web link (www.pythonmorsels.com)
 (TXT) w3m dump (www.pythonmorsels.com)
        
       | ape4 wrote:
       | Cool idea. Do any other languages have this?
        
         | jhbadger wrote:
         | R has probably the best help feature for any language -- not
         | only can you ask it about help on individual functions with
         | "?", the tradition (and this continues with most add in
         | packages as well as builtins) is not only does it give you info
         | on the function, it gives you example code using it so you can
         | understand what it does in practice.
        
         | emmelaich wrote:
         | utop for ocaml is cool, gives type signatures for functions. no
         | explicit help, but does offer completions with tab.
         | 
         | Similarly, rtop for reason.
         | 
         | https://opam.ocaml.org/blog/about-utop/ and
         | https://opam.ocaml.org/packages/rtop/
        
         | stevekemp wrote:
         | Like many others here I once wrote a toy lisp in golang, and I
         | added a help function. It would give usage-information for all
         | the built-in functions.                     > (help +)
         | Arguments N arg1..argN           Adds all arguments present to
         | the first number.                > (help map)
         | Arguments lst:list fun:function           Return a list with
         | the contents of evaluating the given function on every item of
         | the supplied list.           See-also: map-pairs
        
         | freedomben wrote:
         | Ruby has a similar help() function you can invoke from the REPL
         | (irb), or from the CLI with the standalone tool `ri`[1]. Pretty
         | nifty feature!
         | 
         | [1]: https://stackoverflow.com/a/25671404
        
       | viccis wrote:
       | help() is great, but my favorite tool for getting quick info
       | about an object from the Python REPL is still wat.
       | 
       | Just `pip install wat` and then if you need info about some
       | object o, do `wat / o`. If you want full docstrings, do `wat.long
       | / o`
       | 
       | It's a lifesaver when you're using a poorly documented package.
        
         | kstrauser wrote:
         | Dear god: https://github.com/igrek51/wat?tab=readme-ov-
         | file#load-from-...
        
       | ks2048 wrote:
       | Some room for improvement on getting help for symbols:
       | 
       | help("**") explains the power operator, but could also mention
       | dict unpacking.
       | 
       | help("<<") doesn't mention bit shifting (shows a page for
       | "operator precedence").
       | 
       | I was going to say languages should emphasize help for symbols
       | because they're hard to Google for - but I guess in the LLM age,
       | that's no longer true.
        
         | emmelaich wrote:
         | Also uses / in the method signatures with no indication of what
         | it means.
         | 
         | This article doesn't either.
         | 
         | Apparently "It signifies the end of the positional only
         | parameters, parameters you cannot use as keyword parameters."
         | 
         | Which is redundant for most functions as they only have
         | positional parameters.
        
           | hermitdev wrote:
           | > Which is redundant for most functions as they only have
           | positional parameters.
           | 
           | Huh? This is not true.                   def foo(a, b, c):
           | ...
           | 
           | This can be invoked as either `foo(1, 2, 3)` or `foo(c=3,
           | b=2, a=1)`:                   >>> def foo(a, b, c):
           | ...     print(f"{a=}")         ...     print(f"{b=}")
           | ...     print(f"{c=}")         ...         >>> foo(1, 2, 3)
           | a=1         b=2         c=3         >>> foo(c=3, b=2, a=1)
           | a=1         b=2         c=3         >>>
        
           | aftbit wrote:
           | Ooh that feature was new to me. See PEP 570[1] for more
           | details. My personal opinion is that this is not something
           | that any code should do... but I'm not the BDFL!
           | 
           | 1: https://peps.python.org/pep-0570/
        
           | masklinn wrote:
           | > Which is redundant for most functions as they only have
           | positional parameters.
           | 
           | It would not need to exist if that were the case.
           | 
           | The "default" in Python is that a parameter can be passed
           | both positionally and by keyword. Until Python 3.8, the only
           | way to have positional only parameters in pure Python was to
           | use *args and unpack them yourself.
        
           | rat87 wrote:
           | It's not redundant because regular python parameters without
           | a / in the list can be called by name even if they don't have
           | default values. The author may intend them to be positional
           | only but some callers might call them by name and you might
           | break them when you refactor the parameter names, positional
           | only avoids that. Some people dislike positional only
           | parameters but they're already used in a number of stdlib
           | functions written in c so it makes sense to be able to write
           | replacement with the same semantics in pure python as well as
           | being able to express signatures for the c function
        
       | tclancy wrote:
       | Nice. I usually fall back to dir() as my first inspection tool at
       | the command line.
        
         | mdaniel wrote:
         | or its awesome two friends: locals() and globals() to see their
         | names and values simultaneously; I've gotten a lot of mileage
         | out of that as a pseudo-debugger when the only insight you have
         | is a logger in production
        
           | kstrauser wrote:
           | Don't forget `vars()`.
        
         | analog31 wrote:
         | I bounce back and forth. First dir() then help()...
        
         | bayesianbot wrote:
         | I used to, but wat offers a better printout of the methods:
         | https://github.com/igrek51/wat
        
       | shawnz wrote:
       | > There are other ways to use the help function, but before we
       | dive into those I'd like to address the *, and / symbols shown in
       | the output above.
       | 
       | Where is this addressed? Is there a section missing here?
        
         | mdaniel wrote:
         | I am posting this because I always forget which one it is and
         | searching for it is damn near impossible
         | 
         | https://peps.python.org/pep-0457/#syntax-and-semantics
         | 
         | "/" marks the boundary between "positional only" and "mixed"
         | and then "*" does the same for "mixed" and "kwargs only"
        
       | nayuki wrote:
       | The web page's stylesheet is broken (returns HTTP 404) but the
       | text is still quite readable. Good job!
        
       | btdmaster wrote:
       | An interesting side effect is that it runs the code inside the
       | module you import, so that code can act based on whether it gets
       | imported by help or not:
       | 
       | https://tio.run/##VY6/DoIwEMb3PsUXl6ODLK7ETVcfwBhylBqIpW1KB3...
        
       | rzzzt wrote:
       | Before 3.13: https://thejenkinscomic.net/?id=52
        
       ___________________________________________________________________
       (page generated 2025-03-07 23:00 UTC)