Testing for presence of arguments

[Madhusudan Singh]

Hi

I know how to set optional arguments in the function definition. Is there an
intrinsic function that determines if a certain argument was actually
passed ? Like the fortran 95 present() logical intrinsic ?

My required functionality depends on whether a certain argument is specified
at all. (Setting default values is *not* good enough.).

Thanks.

 

[Peter Decker]

I know how to set optional arguments in the function definition. Is there an
intrinsic function that determines if a certain argument was actually
passed ? Like the fortran 95 present() logical intrinsic ?

My required functionality depends on whether a certain argument is specified
at all. (Setting default values is *not* good enough.).

Could you just write the function as:

myFunc(*args, **kwargs):

....and then figure out what was passed?

 

[Dan Sommers]

I know how to set optional arguments in the function definition. Is
there an intrinsic function that determines if a certain argument was
actually passed ? Like the fortran 95 present() logical intrinsic ?

def f(**kw):
if kw.has_key('required_argument'):
print "require_argument was present"
else:
print "require_argument was not present"

My required functionality depends on whether a certain argument is
specified at all. (Setting default values is *not* good enough.).

You can very nearly achieve this with carefully planned default
arguments. Put this into a module:

class _SemiPrivateClass:
pass

def f(required_argument=_SemiPrivateClass):
if required_argument == _SemiPrivateClass:
print "required_argument was probably not present"
else:
print "required_argument was present"

It's not impossible fool f, but an external module has to try very hard
to do so.

(All code untested.)

Regards,
Dan

 

[Diez B. Roggisch]

I don't have the details ready - but in the ASPN cookbook are recipes
to e.g. figure insied a function f out how many results the caller of f
expects - and act accordingly. This boils down to inspect the
call-stack. So it ceratinly is possible.

However, I'd say it is almost 100% a design flaw. Or can you give us a
compelling reason why you need this behaviour?

Diez

 

[Benji York]

I know how to set optional arguments in the function definition. Is there an
intrinsic function that determines if a certain argument was actually
passed ? Like the fortran 95 present() logical intrinsic ?

People generally use a value that isn't a valid option, often None.

def my_func(a, b, c=None):
if c is None:
do something

If None is a valid value, make one that isn't:

unspecified = object()

def my_func(a, b, c=unspecified):
if c is unspecified:
do something

 

[Madhusudan Singh]

I don't have the details ready - but in the ASPN cookbook are recipes
to e.g. figure insied a function f out how many results the caller of f
expects - and act accordingly. This boils down to inspect the
call-stack. So it ceratinly is possible.

However, I'd say it is almost 100% a design flaw. Or can you give us a
compelling reason why you need this behaviour?

Diez

I am writing some code for a measurement application (would have used
fortran 95 if a library had been available for linux-gpib, but python is a
lot friendlier than C without the irritating and utterly pointless braces)
where one of the input parameters for the GPIB command is optional, and
depending on whether it is specified at all, an entire sequence of commands
has to be sent to the GPIB bus plus some input parameters recalculated.
Further, the sequence of commands depends on the range of values of the
optional parameter. And some of these commands in turn have similar
optional arguments.

All in all, the above would have been a bunch of simple one-liners with a
simple if block if python had something like the fortran 95 present()
intrinsic, but I could not find it. Hence my query. Just because there is
no simple and direct way of doing something in a language does not mean
that the application that requires it has a design flaw.

Unrelated question, how does one call a fortran 95 subroutine from python ?
I need really high speed of execution for that call (needed for each
measurement point, and is used to calculate some parameters for the
excitation for the next measurement point) and a scripting language would
not cut it.

 

[Madhusudan Singh]

People generally use a value that isn't a valid option, often None.

def my_func(a, b, c=None):
if c is None:
do something

If None is a valid value, make one that isn't:

unspecified = object()

def my_func(a, b, c=unspecified):
if c is unspecified:
do something

Now, that was a very good suggestion. Thanks.

 

[Madhusudan Singh]

def f(**kw):
if kw.has_key('required_argument'):
print "require_argument was present"
else:
print "require_argument was not present"


You can very nearly achieve this with carefully planned default
arguments. Put this into a module:

class _SemiPrivateClass:
pass

def f(required_argument=_SemiPrivateClass):
if required_argument == _SemiPrivateClass:
print "required_argument was probably not present"
else:
print "required_argument was present"

It's not impossible fool f, but an external module has to try very hard
to do so.

(All code untested.)

Regards,
Dan

Thanks for the suggestion, but seems needlessly complicated for something
very simple.

 

[Madhusudan Singh]

Could you just write the function as:

myFunc(*args, **kwargs):

...and then figure out what was passed?

Seems a lot simpler than the other module suggestion, but another person has
posted a suggestion that is a lot more quick and elegant. Thanks anyways. I
might find this useful in some as yet unknown context.

 

[Diez B. Roggisch]

I am writing some code for a measurement application (would have used

fortran 95 if a library had been available for linux-gpib, but python is a
lot friendlier than C without the irritating and utterly pointless braces)
where one of the input parameters for the GPIB command is optional, and
depending on whether it is specified at all, an entire sequence of commands
has to be sent to the GPIB bus plus some input parameters recalculated.
Further, the sequence of commands depends on the range of values of the
optional parameter. And some of these commands in turn have similar
optional arguments.

I still don't see why default arguments like None won't do the trick.
If The argument _can_
be some value (let's say an int) or None, you still could go for a
default value like () or any other value
from a different domain.

All in all, the above would have been a bunch of simple one-liners with a
simple if block if python had something like the fortran 95 present()
intrinsic, but I could not find it. Hence my query. Just because there is
no simple and direct way of doing something in a language does not mean
that the application that requires it has a design flaw.

Certainly, but as certainly thinking in terms of one language while
using another is prone to
creating design flaws.

So far you still haven't convinced me that default arguments don't work
for you. To me it seems that
your idiom of present() is modeld by python's

if arg is None:
whatever

pretty mich. It might help if you show'd us what your code would like
_if_ python
had present() available. Then we can see what alternatives there are.

Unrelated question, how does one call a fortran 95 subroutine from python ?
I need really high speed of execution for that call (needed for each
measurement point, and is used to calculate some parameters for the
excitation for the next measurement point) and a scripting language would
not cut it.

Didn't ever try that, but either do it in C, or if fortran code can be
exposed as C lib, use that (ctypes is your friend). I'm not aware of a
fortran binding - but I never tried to find one. Basically Python can
interface with everything that can behave like C - which is the least
common denominator I think, so there should be some way.

Regards,

Diez

 

[Madhusudan Singh]

I still don't see why default arguments like None won't do the trick.
If The argument _can_
be some value (let's say an int) or None, you still could go for a
default value like () or any other value
from a different domain.

"None" works perfectly. Someone else on the thread suggested it. I did not
know about the special intrinsic.

Didn't ever try that, but either do it in C, or if fortran code can be
exposed as C lib, use that (ctypes is your friend). I'm not aware of a
fortran binding - but I never tried to find one. Basically Python can
interface with everything that can behave like C - which is the least
common denominator I think, so there should be some way.

Hmm. Thanks for the pointers here.

 

[Robert Kern]

Unrelated question, how does one call a fortran 95 subroutine from python ?
I need really high speed of execution for that call (needed for each
measurement point, and is used to calculate some parameters for the
excitation for the next measurement point) and a scripting language would
not cut it.

http://cens.ioc.ee/projects/f2py2e/

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Peter Maas]

Dan Sommers wrote: [...]

class _SemiPrivateClass:
pass

def f(required_argument=_SemiPrivateClass):
if required_argument == _SemiPrivateClass:
print "required_argument was probably not present"
else:
print "required_argument was present"

[...]
Thanks for the suggestion, but seems needlessly complicated for
> something very simple.

What is "very simple"? The problem or the solution? If you examine
this suggestion more closely you will note that it is more or less
the same as Benji York's one except Benji used a built-in class.

If you are interested in getting help on usenet you should abstain
from devaluating efforts to give you a useful reply. "Thanks for
the suggestion" or even no answer would have been sufficient.

 

[Madhusudan Singh]

What is "very simple"? The problem or the solution? If you examine

The form of the solution.

this suggestion more closely you will note that it is more or less
the same as Benji York's one except Benji used a built-in class.

Many good solutions have some similarity. From the point of view of a user
trying to include some simple functionality in a already complicated
application, Benji's answer was most definitely more useful.

If you are interested in getting help on usenet you should abstain
from devaluating efforts to give you a useful reply. "Thanks for
the suggestion" or even no answer would have been sufficient.

One might have thought that a truthful assessment would have been
appreciated at the other end. I myself help people on the Usenet on some
other newsgroups, and am usually welcoming of responses that offer a
relevant criticism. The exchange improves me as much as it improves them.

Thanks for the suggestion, anyways