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

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

Set a flag on the function or a global?

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

Contents

  Set a flag on the function or a global? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-15 23:57 +0000
    Re: Set a flag on the function or a global? Chris Angelico <rosuav@gmail.com> - 2015-06-16 10:07 +1000
    Re: Set a flag on the function or a global? Ethan Furman <ethan@stoneleaf.us> - 2015-06-15 17:19 -0700
    Re: Set a flag on the function or a global? Ben Finney <ben+python@benfinney.id.au> - 2015-06-16 10:20 +1000
      Re: Set a flag on the function or a global? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-16 19:07 +1000
    Re: Set a flag on the function or a global? Ethan Furman <ethan@stoneleaf.us> - 2015-06-15 17:21 -0700
    Re: Set a flag on the function or a global? sohcahtoa82@gmail.com - 2015-06-15 17:24 -0700
      Re: Set a flag on the function or a global? MRAB <python@mrabarnett.plus.com> - 2015-06-16 01:35 +0100
        Re: Set a flag on the function or a global? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-16 18:18 +1000
          Re: Set a flag on the function or a global? Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-06-16 13:45 +0100
            Re: Set a flag on the function or a global? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-16 22:46 +0000
          Re: Set a flag on the function or a global? Cameron Simpson <cs@zip.com.au> - 2015-06-17 09:51 +1000
            Re: Set a flag on the function or a global? Steven D'Aprano <steve@pearwood.info> - 2015-06-18 00:59 +1000
              Re: Set a flag on the function or a global? Laura Creighton <lac@openend.se> - 2015-06-17 17:06 +0200
                Re: Set a flag on the function or a global? Steven D'Aprano <steve@pearwood.info> - 2015-06-18 01:55 +1000
                  Documenting a function signature (was: Set a flag on the function or a global?) Ben Finney <ben+python@benfinney.id.au> - 2015-06-18 10:04 +1000
                  Re: Documenting a function signature (was: Set a flag on the function or a global?) Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-17 18:10 -0600
                  Re: Documenting a function signature (was: Set a flag on the function or a global?) Chris Angelico <rosuav@gmail.com> - 2015-06-18 10:14 +1000
                  Re: Documenting a function signature (was: Set a flag on the function or a global?) random832@fastmail.us - 2015-06-18 08:37 -0400
                  Re: Documenting a function signature (was: Set a flag on the function or a global?) Laura Creighton <lac@openend.se> - 2015-06-18 23:38 +0200
                  Re: Documenting a function signature Ben Finney <ben+python@benfinney.id.au> - 2015-06-19 10:41 +1000
    Re: Set a flag on the function or a global? Ron Adam <ron3200@gmail.com> - 2015-06-15 20:24 -0400
      Re: Set a flag on the function or a global? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-16 19:15 +1000
        Re: Set a flag on the function or a global? Ron Adam <ron3200@gmail.com> - 2015-06-16 07:02 -0400
    Re: Set a flag on the function or a global? Chris Angelico <rosuav@gmail.com> - 2015-06-16 10:32 +1000
    Re: Set a flag on the function or a global? Paul Rubin <no.email@nospam.invalid> - 2015-06-15 17:37 -0700
      Re: Set a flag on the function or a global? Ethan Furman <ethan@stoneleaf.us> - 2015-06-15 17:53 -0700
        Re: Set a flag on the function or a global? Paul Rubin <no.email@nospam.invalid> - 2015-06-15 19:04 -0700
      Re: Set a flag on the function or a global? MRAB <python@mrabarnett.plus.com> - 2015-06-16 02:15 +0100
      Re: Set a flag on the function or a global? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-16 18:30 +1000
    Re: Set a flag on the function or a global? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-16 07:06 +0100
      Re: Set a flag on the function or a global? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-16 19:28 +1000
    Re: Set a flag on the function or a global? Jonas Wielicki <jonas@wielicki.name> - 2015-06-16 12:00 +0200
    Re: Set a flag on the function or a global? Michael Torrie <torriem@gmail.com> - 2015-06-16 07:44 -0600
    Re: Set a flag on the function or a global? Michael Torrie <torriem@gmail.com> - 2015-06-16 07:56 -0600
    Re: Set a flag on the function or a global? Peter Otten <__peter__@web.de> - 2015-06-16 15:59 +0200
    Re: Set a flag on the function or a global? Ethan Furman <ethan@stoneleaf.us> - 2015-06-16 07:57 -0700

Page 2 of 2 — ← Prev page 1 [2]

#92862 — Re: Documenting a function signature

Laura Creighton <lac@openend.se> writes:

> In a message of Thu, 18 Jun 2015 10:04:46 +1000, Ben Finney writes:
> >Since the introduction of keyword-only arguments in Python functions,
> >the question arises of how to communicate this in documentation.
>
> I suppose it is way too late to scream "I hate keyword-only
> arguments"!

It's never too late for screams, go right ahead.

If you're hoping those screams will result in the keyword-arguments not
being part of Python now and in the future; yes, I think it's too late
for that :-)

-- 
 \      “If sharing a thing in no way diminishes it, it is not rightly |
  `\      owned if it is not shared.” —Augustine of Hippo (354–430 CE) |
_o__)                                                                  |
Ben Finney

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

#92650

On 06/15/2015 08:07 PM, Chris Angelico wrote:
> On Tue, Jun 16, 2015 at 9:57 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info>  wrote:
>> >I have two ideas for this, a module-level global, or a flag set on the
>> >function object itself. Remember that the usual way of using this will be
>> >"from module import edir", there are two obvious ways to set the global:
>> >
>> >import module
>> >module.dunders = False
>> >
>> ># -or-
>> >
>> >edir.__globals__['dunders'] = False
>> >
>> >
>> >Alternatively, I can use a flag set on the function object itself:
>> >
>> >edir.dunders = False
>> >
> For most situations, the last one is extremely surprising - attributes
> on functions aren't normally meant to be changed by outside callers,

Or inside callers either.  You can't be sure of the name and there is no self.


> it always feels wrong (they belong to the function itself). But since
> this is interactive, I'd advise going for the absolute simplest, which
> this would be. Go for the function attribute IMO.


Another way is to make it an object with a __call__ method.

The the attribute can be accessed from both outside and inside dependably.

Cheers,
    Ron

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

#92666

On Tuesday 16 June 2015 10:24, Ron Adam wrote:

> Another way is to make it an object with a __call__ method.
> 
> The the attribute can be accessed from both outside and inside dependably.

That's what functions are, objects with a __call__ method:


py> (lambda: None).__call__
<method-wrapper '__call__' of function object at 0xb7301a04>


One slight disadvantage is that functions don't take a "self" parameter by 
default, which means they have to refer to themselves by name:

def spam():
    print spam.attr


Here's a fun hack:

py> from types import MethodType
py> def physician(func):
...     # As in, "Physician, Know Thyself" :-)
...     return MethodType(func, func)
... 
py> @physician
... def spam(this, n):
...     return this.food * n
... 
py> spam.__func__.food = "spam-and-eggs "
py> spam(3)
'spam-and-eggs spam-and-eggs spam-and-eggs '


Alas, you cannot write directly to the method object itself :-(



-- 
Steve

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

#92673

On 06/16/2015 05:15 AM, Steven D'Aprano wrote:
> On Tuesday 16 June 2015 10:24, Ron Adam wrote:
>
>> >Another way is to make it an object with a __call__ method.
>> >
>> >The the attribute can be accessed from both outside and inside dependably.
> That's what functions are, objects with a __call__ method:
>
>
> py> (lambda: None).__call__
> <method-wrapper '__call__' of function object at 0xb7301a04>

Yes ;-)


> One slight disadvantage is that functions don't take a "self" parameter by
> default, which means they have to refer to themselves by name:
>
> def spam():
>      print spam.attr
>
>
> Here's a fun hack:
>
> py> from types import MethodType
> py> def physician(func):
> ...     # As in, "Physician, Know Thyself":-)
> ...     return MethodType(func, func)
> ...
> py> @physician
> ... def spam(this, n):
> ...     return this.food * n
> ...
> py> spam.__func__.food = "spam-and-eggs "
> py> spam(3)
> 'spam-and-eggs spam-and-eggs spam-and-eggs'


How about this?:  (paste it into your console)

#---------------------
import sys
class EDir:
     long = False
     def __call__(self, obj=None):
         if obj == None:
             d = sys._getframe(1).f_locals
         else:
             d = dir(obj)
         return [x for x in d if self.long or not x.startswith("_")]


edir = EDir()

edir()

edir(edir)

edir.long = True
edir(edir)

edir.long = False
edir(edir)
#----------------------


I didn't test how that works from other modules or in nested scopes.  Also 
replacing None with a unique sentinel object may be better so dir(None) 
will work.

Cheers,
    Ron

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

#92651

On Tue, Jun 16, 2015 at 10:20 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Tue, Jun 16, 2015 at 9:57 AM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>> > I can use a flag set on the function object itself:
>> >
>> > edir.dunders = False
>>
>> For most situations, the last one is extremely surprising - attributes
>> on functions aren't normally meant to be changed by outside callers,
>> it always feels wrong (they belong to the function itself).
>
> I'm surprised by your assertion. To my mind, outside callers get simple
> and direct access to the attribute, whereas the code of the function
> itself does not have such easy access; unlike ‘self’ for the current
> instance of a class, there's no obvious name to use for referring to the
> function object within the function object's own code.
>
> In what sense do they “belong to” the function itself *more than* to
> outside callers?

Custom function attributes (as in, those not set by the interpreter
itself) are pretty rare, but I've usually seen them only being defined
by the module that created them. Setting that kind of attribute
externally, from a different module, seems odd - and undiscoverable.
But for interactive work, that should be fine.

ChrisA

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

#92653

Steven D'Aprano <steve+comp.lang.python@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.  

If you also support the keyword arg, then you could have

  edir_(obj)=functools.partial(edir,dunders=True).

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

#92654

On 06/15/2015 05:37 PM, Paul Rubin wrote:
> Steven D'Aprano <steve+comp.lang.python@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.

`edir_` ?  What a horrible name.  I hate trailing underscores.  Too easy to miss.

--
~Ethan~

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

#92657

Ethan Furman <ethan@stoneleaf.us> writes:
>>    edir_(obj) = dunders.
> `edir_` ?  What a horrible name.  I hate trailing underscores.  Too easy to miss.

They've worked ok for me at various times.  edir_u (for unfiltered) is
another idea.

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

#92655

On 2015-06-16 01:53, Ethan Furman wrote:
> On 06/15/2015 05:37 PM, Paul Rubin wrote:
>> Steven D'Aprano <steve+comp.lang.python@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.
>
> `edir_` ?  What a horrible name.  I hate trailing underscores.  Too easy to miss.
>
Especially when there's also `edir`! :-)

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

#92664

On Tuesday 16 June 2015 10:37, Paul Rubin wrote:

> Steven D'Aprano <steve+comp.lang.python@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

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

#92661

On 16/06/2015 00:57, Steven D'Aprano wrote:
> I have a function in a module which is intended to be used by importing
> that name alone, then used interactively:
>
>      from module import edir
>      edir(args)
>
>
> edir is an enhanced version of dir, and one of the enhancements is that
> you can filter out dunder methods. I have reason to believe that people
> are split on their opinion on whether dunder methods should be shown by
> default or not: some people want to see them, others do not. Since edir
> is meant to be used interactively, I want to give people a setting to
> control whether they get dunders by default or not.
>
> I have two ideas for this, a module-level global, or a flag set on the
> function object itself. Remember that the usual way of using this will be
> "from module import edir", there are two obvious ways to set the global:
>
> import module
> module.dunders = False
>
> # -or-
>
> edir.__globals__['dunders'] = False
>
>
> Alternatively, I can use a flag set on the function object itself:
>
> edir.dunders = False
>
>
> Naturally you can always override the default by explicitly specifying a
> keyword argument edir(obj, dunders=flag).
>
> 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.
>
>

For interactive use I'd be perfectly happy with just the keyword 
argument.  Why bother toggling something when I can explicitly set it in 
the call each and every time?  If I have to choose it's a flag on the 
object, just no competition.

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

Mark Lawrence

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

#92668

On Tuesday 16 June 2015 16:06, Mark Lawrence wrote:

> On 16/06/2015 00:57, Steven D'Aprano wrote:
[...]
>> Naturally you can always override the default by explicitly specifying a
>> keyword argument edir(obj, dunders=flag).
>>
>> 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.
>>
>>
> 
> For interactive use I'd be perfectly happy with just the keyword
> argument.  Why bother toggling something when I can explicitly set it in
> the call each and every time?  If I have to choose it's a flag on the
> object, just no competition.

The idea is to set the default behaviour: does edir(obj) display dunder 
methods by default or not? I've found that many people don't want to see the 
dunder methods, and find dir() less pleasant or useful because it shows 
them. Others disagree and want to see them. So you can set the default 
behaviour you want, and then only worry about giving an explicit argument 
when you want the opposite.

There is no intention for people to toggle the flag between calls!

# don't do this!
edir.dunders = True
edir(x)
edir.dunders = False
edir(y)


# do this instead
edir.dunders = True  # if that is your preferred setting
edir(x)
edir(y, dunders=False)




-- 
Steve

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

#92669

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 16.06.2015 01:57, Steven D'Aprano wrote:
> Alternatively, I can use a flag set on the function object itself:
> 
> edir.dunders = False
> 
> 
> Naturally you can always override the default by explicitly
> specifying a keyword argument edir(obj, dunders=flag).
> 
> 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.

I like a flag on the object, and this would be my implementation:

```
def edir_impl():
    # implementation of edir
    pass

class Edir(object):
    def __init__(self):
        self.kwargs = {}

    def __getattr__(self, name):
        return self.kwargs[name]

    def __setattr__(self, name, value):
        self.kwargs[name] = value

    def __delattr__(self, name):
        del self.kwargs[name]

    def __call__(self, *args, **kwargs):
        kwargs_to_use = self.kwargs.copy()
        kwargs_to_use.update(kwargs)
        edir_impl(*args, **kwargs_to_use)

edir = Edir()
```
(untested, but you get the idea, hopefully)

This also allows to have several versions of edir around in a shell
with different default settings.

regards,
jwi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVf/PLAAoJEMBiAyWXYliKFM4P/jf/ZDZFacrRuk29tNzNFjA2
6UT4GURF6UX+C129gGgaqxpDY9oD9herfUpqbFxfNWq4Rye9MX+xkv3uQUsP5BXE
G7VjrSC0qd1GmdwFxdIQEb1fa6LgMmOnnYe/sIw5XWF2Rtbkqlisw7ZO3YDsWT9d
cadoEh0ShFbM6z4MUDEd8tu6RQ/j61v906TwsVgY+4uI8WWOzqHumM7pkWHxP2ns
3b/2ijQJNNLwH3UfbPBo3YhJWt0c+ACzuxr5MamVHUJBZpNatcszti3mkn2CtDCb
m5Kc0gO0RxHVaHV4RWrjYlcllhysQ/zeAuOz1PHEqevlitj8z1cBy3p4sfz8GOZe
XAKChaZHVAq7eTGzgtLksBQ0dujLxy9zLWiHfeLfMnTyZoYFKVCM2rlSYutnkI0f
7VdaaKStVpqkXeJHX1n1LvHBOroQCFtUFn2F0FylpR/nBA7ar9epZYiCWbrb21xO
DYs8T7dC7DI1waLeXJ2JbXiXqh6cQ9Fy86fm+VE1lmkJ6LvboRCN9eWMQ1o1+RtM
Dla6CvH2zxgW2u3HZCIoU9TusYaNLR9kSxqCMc2yLuMiUQpj0HfjZCR+ZP2/9phS
wx+qZx+5X25ybXlCZRtlvzb409BclOJ7JOynboX4MU4M9sSCPJhb5/ZcM79r7nJa
o0y06nE5eReu71TMwmDW
=r9uV
-----END PGP SIGNATURE-----

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

#92676

On 06/15/2015 06:20 PM, Ben Finney wrote:
> I'm surprised by your assertion. To my mind, outside callers get simple
> and direct access to the attribute, whereas the code of the function
> itself does not have such easy access; unlike ‘self’ for the current
> instance of a class, there's no obvious name to use for referring to the
> function object within the function object's own code.

Of course it has access, and it's obvious and easy as well:

def foo():
    foo.flag = True

The only thing I'm not sure of is a clean way to test for the
attribute's existence.  The __init__.py of a package, or the
initialization code of the module could preset the attribute, though.

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

#92678

On 06/15/2015 06:19 PM, Ethan Furman wrote:
> Setting a global on the module (which I may not have, and probably
> didn't, import) for only one function is overkill.

What do you mean?  Even if you pull in just one function from the
module on an import, the module's initialization code still runs.

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

#92679

Steven D'Aprano wrote:

> I have a function in a module which is intended to be used by importing
> that name alone, then used interactively:
> 
>     from module import edir
>     edir(args)
> 
> 
> edir is an enhanced version of dir, and one of the enhancements is that
> you can filter out dunder methods. I have reason to believe that people
> are split on their opinion on whether dunder methods should be shown by
> default or not: some people want to see them, others do not. Since edir
> is meant to be used interactively, I want to give people a setting to
> control whether they get dunders by default or not.
> 
> I have two ideas for this, a module-level global, or a flag set on the
> function object itself. Remember that the usual way of using this will be
> "from module import edir", there are two obvious ways to set the global:
> 
> import module
> module.dunders = False
> 
> # -or-
> 
> edir.__globals__['dunders'] = False
> 
> 
> Alternatively, I can use a flag set on the function object itself:
> 
> edir.dunders = False
> 
> 
> Naturally you can always override the default by explicitly specifying a
> keyword argument edir(obj, dunders=flag).
> 
> 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.

"""
In general I'm wary of routines that take flags (such as 'swapped')
that really mean "use a different version of the function" -- these
flags are almost always passed from constants and so it would be more
efficient to have a second name for the variant function.
"""
http://legacy.python.org/search/hypermail/python-1994q2/0852.html

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

#92680

On 06/16/2015 06:56 AM, Michael Torrie wrote:
> On 06/15/2015 06:19 PM, Ethan Furman wrote:
>>
>> Setting a global on the module (which I may not have, and probably
>> didn't, import) for only one function is overkill.
>
> What do you mean?  Even if you pull in just one function from the
> module on an import, the module's initialization code still runs.

For me, an appropriate use of globals requires that it will be used by many other pieces of code in that module.  If only one piece of code is using it, it's not really global.

--
~Ethan~

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web