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

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

Re: verify the return value of a function

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: verify the return value of a function Jean-Michel Pichavant <jeanmichel@sequans.com> - 2012-01-20 11:13 +0100
    Re: verify the return value of a function Mel Wilson <mwilson@the-wire.com> - 2012-01-20 08:53 -0500
      Re: verify the return value of a function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-20 15:07 +0000
        Re: verify the return value of a function Terry Reedy <tjreedy@udel.edu> - 2012-01-20 15:42 -0500

#19142 — Re: verify the return value of a function

Jabba Laci wrote:
> Hi,
>
> In a unit test, I want to verify that a function returns a
> cookielib.LWPCookieJar object. What is the correct way of doing that?
>
> 1) First I tried to figure out its type with type(return_value) but it
> is <type 'instance'>
>
> 2) return_value.__class__ .__name__ gives 'LWPCookieJar', which is bettter
>
> 3) isinstance(return_value, cookielib.LWPCookieJar) seems to be the
> best way, however somewhere I read that using isinstance is
> discouraged
>
> Thanks,
>
> Laszlo
>   
isinstance is fine, if you could find the source where it is 
discouraged... Could be a consequence of some specific context.
However, checking types in OOP is in general a failure. Unitary tests 
are possibly an exception.

JM

[toc] | [next] | [standalone]

#19145

Jean-Michel Pichavant wrote:

> isinstance is fine, if you could find the source where it is
> discouraged... Could be a consequence of some specific context.
> However, checking types in OOP is in general a failure. Unitary tests
> are possibly an exception.

I think it's discouraged when people try to write big overloaded functions 
that check the types of the arguments to decide what they should be doing.
In diagnostics and tests like the OP's there should be no problem.

	Mel.

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

#19147

On Fri, 20 Jan 2012 08:53:13 -0500, Mel Wilson wrote:

> Jean-Michel Pichavant wrote:
> 
>> isinstance is fine, if you could find the source where it is
>> discouraged... Could be a consequence of some specific context.
>> However, checking types in OOP is in general a failure. Unitary tests
>> are possibly an exception.
> 
> I think it's discouraged when people try to write big overloaded
> functions that check the types of the arguments to decide what they
> should be doing.

I don't agree with that. Writing polymorphic functions using isinstance 
is a perfectly reasonable thing to do. E.g. from the standard library's 
decimal module:

class Decimal(object):
    """Floating point class for decimal arithmetic."""
    # We're immutable, so use __new__ not __init__
    def __new__(cls, value="0", context=None):
        self = object.__new__(cls)
        # From a string
        # REs insist on real strings, so we can too.
        if isinstance(value, str):
            ...
        # From an integer
        if isinstance(value, int):
            ...
        # From another decimal
        if isinstance(value, Decimal):
            ...
        # From an internal working value
        if isinstance(value, _WorkRep):
            ...
        # tuple/list conversion (possibly from as_tuple())
        if isinstance(value, (list,tuple)):
            ...
        if isinstance(value, float):
            ...
        raise TypeError("Cannot convert %r to Decimal" % value)


What should be avoided, when possible, is over-reliance on isinstance 
checks instead of protocol or interface checks. For example, don't check 
for a list if your function doesn't *need* a list but would be happy with 
a tuple or some other sequence.

Worse than isinstance is testing for an exact type:

if type(x) is list  # worse than isinstance(x, list)

although of course, there are times where you need to break the rules.



> In diagnostics and tests like the OP's there should be
> no problem.

Agreed.



-- 
Steven

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

#19165

On 1/20/2012 10:07 AM, Steven D'Aprano wrote:

> What should be avoided, when possible, is over-reliance on isinstance
> checks instead of protocol or interface checks. For example, don't check
> for a list if your function doesn't *need* a list but would be happy with
> a tuple or some other sequence.

In other words, do not use isinstance to artificially limit the input 
domain of a function. The generic or polymorphic nature of (builtin) 
operators and functions is a major feature of Python.

On the other hand, the output range of a function is typically much more 
limited as to type. Complete testing requires testing the specified 
output type. For instance, sorted(iterable) is documented as producing a 
sorted list, so 'type(output) is list' is an appropriate test.

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

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

csiph-web