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

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

Function Defaults - avoiding unneccerary combinations of arguments at input

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

Contents

  Function Defaults - avoiding unneccerary combinations of arguments at input "Ivan Evstegneev" <webmailgroups@gmail.com> - 2015-03-25 19:43 +0200
    Re: Function Defaults - avoiding unneccerary combinations of arguments at input Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-26 10:48 +1100
      RE: Function Defaults - avoiding unneccerary combinations of arguments at input "Ivan Evstegneev" <webmailgroups@gmail.com> - 2015-03-26 11:47 +0200
        RE: Function Defaults - avoiding unneccerary combinations of arguments at input Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-26 21:51 +1100

#87955 — Function Defaults - avoiding unneccerary combinations of arguments at input

Hello all , 


Just a little question about function's default arguments.

Let's say I have this function:

def  my_fun(history=False, built=False, current=False, topo=None,
full=False, file=None):
	if currnet and full:
		do something_1
	elif current and file:
		do something_2
	elif history and full and file:
		do something_3
	

	...... some code here..............

and so on... 

I won't cover all the possibilities here (actually I don't use all of them
^_^).

The question is about avoiding the response for unnecessary combinations? 

For instance, if user will call function this way: 


>>>my_fun(current=True, full=True, topo='some str', file="some_file")

That will lead to function's misbehavior. As a particular case it will
choose "current and full" condition. 


What is the common accepted way to deal with such unwanted situations? 


Thanks a lot in advance,

Ivan.


 

[toc] | [next] | [standalone]

#87998

On Thu, 26 Mar 2015 04:43 am, Ivan Evstegneev wrote:

> Hello all ,
> 
> 
> Just a little question about function's default arguments.
> 
> Let's say I have this function:
> 
> def  my_fun(history=False, built=False, current=False, topo=None,
> full=False, file=None):
> if currnet and full:
> do something_1
> elif current and file:
> do something_2
> elif history and full and file:
> do something_3


This is an extreme example that shows why Guido's Law "No constant
arguments" is a good design principle. (Well, it's not really so much a law
as a guideline.)

If you have a function that looks like this:

def spam(arg, flag=True):
    if flag:
        return do_this(arg)
    else:
        return do_that(arg)


then you should just use do_this and do_that directly and get rid of spam.

In your case, its hard to say *exactly* what you should do, since you are
only showing a small sketch of "my_fun", but it looks to me that it tries
to do too much. You can probably split it into two or four smaller
functions, and avoid needing so many (or any!) flags.

That will avoid (or at least reduce) the need to check for mutually
incompatible sets of arguments.

Another useful design principle: if dealing with the combinations of
arguments is too hard, that's a sign that you have too many combinations of
arguments.

If there are combinations which are impossible, there are three basic ways
to deal with that. In order from best to worst:


(1) Don't let those combinations occur at all. Redesign your function, or
split it into multiple functions, so the impossible combinations no longer
exist.

(2) Raise an error when an impossible combination occurs.

(3) Just ignore one or more argument so that what was impossible is now
possible.




-- 
Steven

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

#88036

> -----Original Message-----
> From: Python-list [mailto:python-list-
> bounces+webmailgroups=gmail.com@python.org] On Behalf Of Steven
> D'Aprano
> Sent: Thursday, March 26, 2015 01:49
> To: python-list@python.org
> Subject: Re: Function Defaults - avoiding unneccerary combinations of
> arguments at input
> 
> On Thu, 26 Mar 2015 04:43 am, Ivan Evstegneev wrote:
> 
> > Hello all ,
> >
> >
> > Just a little question about function's default arguments.
> >
> > Let's say I have this function:
> >
> > def  my_fun(history=False, built=False, current=False, topo=None,
> > full=False, file=None):
> > if currnet and full:
> > do something_1
> > elif current and file:
> > do something_2
> > elif history and full and file:
> > do something_3
> 
> 
> This is an extreme example that shows why Guido's Law "No constant
> arguments" is a good design principle. (Well, it's not really so much a
law as a
> guideline.)
> 
> If you have a function that looks like this:
> 
> def spam(arg, flag=True):
>     if flag:
>         return do_this(arg)
>     else:
>         return do_that(arg)
> 
> 
> then you should just use do_this and do_that directly and get rid of spam.
> 
> In your case, its hard to say *exactly* what you should do, since you are
only
> showing a small sketch of "my_fun", but it looks to me that it tries to do
too
> much. You can probably split it into two or four smaller functions, and
avoid
> needing so many (or any!) flags.
> 
> That will avoid (or at least reduce) the need to check for mutually
> incompatible sets of arguments.
> 
> Another useful design principle: if dealing with the combinations of
> arguments is too hard, that's a sign that you have too many combinations
of
> arguments.
> 
> If there are combinations which are impossible, there are three basic ways
to
> deal with that. In order from best to worst:
> 
> 
> (1) Don't let those combinations occur at all. Redesign your function, or
split
> it into multiple functions, so the impossible combinations no longer
exist.
> 
> (2) Raise an error when an impossible combination occurs.
> 
> (3) Just ignore one or more argument so that what was impossible is now
> possible.
> 
> 
> 
> 
> --
> Steven
> 
> --
> https://mail.python.org/mailman/listinfo/python-list



Hello Steven,

As I said in a previous mail, main purpose of this arguments is to define
what path should be chose. It is actually one xls file that could be placed
into various placed within my folder tree. 

For instance, I have following folder tree:

data_lib/
	current/
	history/
	built/

Say  I have "test.xls" that could be in one of those three folders. 
I wrote a function that reads it out, and its input arguments just define
where it should be read. So  all those "ifs" related to path definition.



Still now I'm thinking to really split it out...  I'll have a separate
function for path definition and then it will call a common reader_fun() in
order to read this file.


Sincerely,

Ivan

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

#88042

On Thu, 26 Mar 2015 08:47 pm, Ivan Evstegneev wrote:

> 
> 
>> -----Original Message-----
>> From: Python-list [mailto:python-list-
>> bounces+webmailgroups=gmail.com@python.org] On Behalf Of Steven
>> D'Aprano
>> Sent: Thursday, March 26, 2015 01:49
>> To: python-list@python.org
>> Subject: Re: Function Defaults - avoiding unneccerary combinations of
>> arguments at input
>> 
>> On Thu, 26 Mar 2015 04:43 am, Ivan Evstegneev wrote:
>> 
>> > Hello all ,
>> >
>> >
>> > Just a little question about function's default arguments.
>> >
>> > Let's say I have this function:
>> >
>> > def  my_fun(history=False, built=False, current=False, topo=None,
>> > full=False, file=None):
>> > if currnet and full:
>> > do something_1
>> > elif current and file:
>> > do something_2
>> > elif history and full and file:
>> > do something_3

[...]

> As I said in a previous mail, main purpose of this arguments is to define
> what path should be chose. It is actually one xls file that could be
> placed into various placed within my folder tree.
> 
> For instance, I have following folder tree:
> 
> data_lib/
>     current/
>     history/
>     built/
> 
> Say  I have "test.xls" that could be in one of those three folders.
> I wrote a function that reads it out, and its input arguments just define
> where it should be read. So  all those "ifs" related to path definition.

Perhaps something like this?

def my_func(subdir):
    if subdir not in ("current", "history", "built"):
        raise ValueError("invalid sub-directory")
    # Better to use os.path.join, but I'm feeling lazy.
    path = "path/to/data_lib/" + subdir + "/test.xls"
    process(path)




-- 
Steven

[toc] | [prev] | [standalone]

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

csiph-web