Re: verify the return value of a function

Discussion in 'Python' started by Jean-Michel Pichavant, Jan 20, 2012.

  1. 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
     
    Jean-Michel Pichavant, Jan 20, 2012
    #1
    1. Advertising

  2. Jean-Michel Pichavant

    Mel Wilson Guest

    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.
     
    Mel Wilson, Jan 20, 2012
    #2
    1. Advertising

  3. 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
     
    Steven D'Aprano, Jan 20, 2012
    #3
  4. Jean-Michel Pichavant

    Terry Reedy Guest

    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
     
    Terry Reedy, Jan 20, 2012
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Seong-Kook Shin
    Replies:
    1
    Views:
    498
    Richard Bos
    Jun 18, 2004
  2. Greenhorn
    Replies:
    15
    Views:
    840
    Keith Thompson
    Mar 6, 2005
  3. roberta

    Verify a collection value

    roberta, May 8, 2010, in forum: ASP .Net
    Replies:
    4
    Views:
    287
    Mr. Arnold
    May 9, 2010
  4. Jabba Laci

    verify the return value of a function

    Jabba Laci, Jan 19, 2012, in forum: Python
    Replies:
    2
    Views:
    192
    Roy Smith
    Jan 20, 2012
  5. jdog

    Verify current interval value?

    jdog, Oct 5, 2004, in forum: Javascript
    Replies:
    1
    Views:
    72
    Michael Winter
    Oct 7, 2004
Loading...

Share This Page