On Tuesday 16 June 2015 10:37, Paul Rubin wrote:
> Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> writes:
>> Thoughts and feedback? Please vote: a module global, or a flag on the
>> object? Please give reasons, and remember that the function is intended
>> for interactive use.
>
> Both are bad. More state to remember, ugh. Instead have separate entry
> points for filtering or not filtering the dunders. Something like:
>
> edir(obj) = no dunders
> edir_(obj) = dunders.
I certainly wouldn't call it edir_ but I'd maybe call it edir2 or ddir
("Dunderless DIR") or just_like_builtin_dir_only_better. <wink>
Normally I would agree with you, as a matter of principle, functions which
differ only by an argument called as a constant, particular when that
argument is a flag, should be split into multiple functions.
That is, instead of foo(x, flag=True) and foo(x, flag=False), have foo(x)
and foo2(x).
One disadvantage of this, though, is that it may not be self-evident which
function does what. Who remembers the difference between all the os.exec*
functions? Speaking of which:
py> dir(os, 'exec*')
['execl', 'execle', 'execlp', 'execlpe', 'execv', 'execve', 'execvp',
'execvpe']
But in this case, because [e]dir is intended to be run interactively, I
think that the convenience of a single function is more important. Most
people will set the default setting to whatever they prefer and then 95% of
the time just use it as given, only occasionally giving the dunders keyword
argument when they need the opposite setting.
Or at least, that's how *I* use it.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
