Set a flag on the function or a global?

[Cameron Simpson]

On 16Jun2015 18:18, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>On Tuesday 16 June 2015 10:35, MRAB wrote:
>> On 2015-06-16 01:24, sohcahtoa82 at gmail.com wrote:
>>> Using a keyword argument for the edir function is the most intuitive
>>> and easy to read, IMO.
>
>edir() has a keyword argument: edir(x, dunders=False) suppresses the return
>of dunder names. But since the primary purpose of [e]dir is, in my opinion,
>to be used interactively, needing to type an extra 15 characters to hide
>dunders is too inconvenient.

I'm just catching up here, but have now read the whole thread.

I am personally against a global (==> single variable affecting all callers) of 
any kind, be it a function attribute or whatever. Why? For that same reason 
that we discourage use of functions like os.chdir or os.umask except in rare 
circumstances: the single call inevitably affects the entire program behaviour.

Your intended use case may be interactive, where I agree the convenience looks 
nice. However, I think it inevitable that someone imports your edir function as 
an aid to writing friendly debugging messages is a larger program, and thus is 
escapes into noninteractive use. (As an example, I have a class named "O" which 
I use as a base class for many classes, especially in the debugging phase; its 
major semantic is friendlier __str__ and __repr__ for exactly the same reasons 
you wrote "edir", and with similar effect.)

On that basis (avoiding global state) my preference would be strongly to rely 
entirely on your keyword argument (dunder=False) and to offer two flavors, such 
as the "edir" and "edir_" suggested elsewhere. The user can always import 
"edir_ as edir_noisy" if they are of the mindset which dislikes single trailing 
underscores.

[...]
>> But it's meant to be used interactively. If they're using it in a
>> script, they'd most likely set the argument appropriately.
>
>Yes.

Ideally yes. "Most likely"? I have less confidence there.

>The primary use-case (at least *my* use-case, and hopefully others) is to
>have "from module import edir as dir" in their Python startup file. That
>means that when running interactively, they will get the enhanced version of
>dir, but when running a script or an application they'll just get the
>regular one.

This fits well with two functions, then they can import "edir" or "edir_" as 
dir as they see fit.

>Besides, apart from the inspect module, which probably shouldn't, who uses
>dir() programmatically?

Directly, perhaps rarely. But I use my O.__str__ method implicitly quite a lot, 
and it has a similar purpose to your edir. (It is not the same, so the parallel 
is not perfect.)

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

All who love Liberty are enemies of the State.  - Karl Hess