On 16Jun2015 18:18, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>
wrote:
On Tuesday 16 June 2015 10:35, MRAB wrote:
On 2015-06-16 01:24, sohcahto...@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 <c...@zip.com.au>
All who love Liberty are enemies of the State. - Karl Hess
--
https://mail.python.org/mailman/listinfo/python-list
