Re: verify the return value of a function

2012-01-20 Thread Jean-Michel Pichavant

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
--
http://mail.python.org/mailman/listinfo/python-list


Re: verify the return value of a function

2012-01-20 Thread Ulrich Eckhardt

Am 19.01.2012 21:45, schrieb Jabba Laci:

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
istype 'instance'


I'm not sure where the problem here is and where exactly you are seeing 
this. This might even indicate a problem with how the returned type is 
constructed.


Anyhow:

 x = 1
 type(x)
type 'int'
 type(x) is int
True

So checking for an exact type should work using type().



2) return_value.__class__ .__name__ gives 'LWPCookieJar', which is bettter


It doesn't cover namespaces though. Also, you should compare that to 
cookielib.LWPCookieJar.__name__, not 'LWPCookieJar'. What is the LWP, btw?




3) isinstance(return_value, cookielib.LWPCookieJar) seems to be the
best way, however somewhere I read that using isinstance is
discouraged.


Never trust any such claim that doesn't give a justification. In your 
case, that would be the right thing to do, IMHO. Promising to return an 
LWPCookieJar is fulfilled when the returnvalue is of that type or a 
class derived from that, which variant 1 doesn't cover.


Uli
--
http://mail.python.org/mailman/listinfo/python-list


Re: verify the return value of a function

2012-01-20 Thread Mel Wilson
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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: verify the return value of a function

2012-01-20 Thread Roy Smith
In article mailman.4872.1327005963.27778.python-l...@python.org,
 Jabba Laci jabba.l...@gmail.com 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?

jar = my_function_being_tested()
self.assertIsInstance(jar, cookielib.LWPCookieJar)

That works in 2.7.  If you're using something older than 2.7, you'll 
need to do:

self.assertTrue(isinstance(jar, cookielib.LWPCookieJar)

Alternatively, just download the 2.7 version of unittest and use that 
(it works fine with 2.6, not sure about earlier than that).
 
 3) isinstance(return_value, cookielib.LWPCookieJar) seems to be the
 best way, however somewhere I read that using isinstance is
 discouraged

Where did you read that, and in what context?

Compared to type(), isinstance() is an improvement because it correctly 
handles subclasses.  If you want a LWPCookieJar, you should be happy to 
have somebody give you a subclass of LWPCookieJar (assuming they 
correctly implemented the interface).  Thus says the Church of Most 
Corpulent Staticness and Type Bondage.

On the other hand, there are some (adherents of the Most Holy and 
Loquacious Church of Duck Typing) who would say that testing for class 
at all is a sin, and what you want to do is test that the object being 
tested has the methods and attributes you expect.

Me, I'm somewhere in between.  I believe that pinching it and seeing 
what the quack sounds like is usually the right thing to do.  On the 
other hand, if you want to demand to see its Certificate of Duckiness, 
you have a right to do that too.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: verify the return value of a function

2012-01-20 Thread Steven D'Aprano
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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: verify the return value of a function

2012-01-20 Thread Ian Kelly
On Fri, Jan 20, 2012 at 2:15 AM, Ulrich Eckhardt 
ulrich.eckha...@dominolaser.com wrote:

 Am 19.01.2012 21:45, schrieb Jabba Laci:

  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
 istype 'instance'


 I'm not sure where the problem here is and where exactly you are seeing
 this. This might even indicate a problem with how the returned type is
 constructed.


This just means that LWPCookieJar is an old-style class:

 class Foo: pass
...
 type(Foo())
type 'instance'
 Foo().__class__
class __main__.Foo at 0x01DC4CE0

So for type checks here the __class__ attribute should be used, not the
type function.  isinstance is better for instance checks though in either
case.

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: verify the return value of a function

2012-01-20 Thread Terry Reedy

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

--
http://mail.python.org/mailman/listinfo/python-list


verify the return value of a function

2012-01-19 Thread Jabba Laci
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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: verify the return value of a function

2012-01-19 Thread Chris Rebert
On Thu, Jan 19, 2012 at 12:45 PM, Jabba Laci jabba.l...@gmail.com 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?
snip
 3) isinstance(return_value, cookielib.LWPCookieJar) seems to be the
 best way, however somewhere I read that using isinstance is
 discouraged

Explicit typechecking is often discouraged in favor of duck typing.
However, if you want to do explicit typechecking (as one might in unit
tests), then isinstance() is absolutely the technique to use.
The alternative would be to check for the specific attributes of
LWPCookieJar that you're relying upon (using hasattr() or similar),
but that's probably overkill here.

Cheers,
Chris
--
http://rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list