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

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

annoying doctest problem

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

Contents

  annoying doctest problem gordianknot1981@gmail.com - 2015-01-11 20:20 -0800
    Re: annoying doctest problem gordianknot1981@gmail.com - 2015-01-11 20:30 -0800
    Re: annoying doctest problem Steven D'Aprano <steve@pearwood.info> - 2015-01-12 05:24 +0000
      Re: annoying doctest problem Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-12 06:15 -0600
        Re: annoying doctest problem Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-13 00:00 +1100
          Re: annoying doctest problem Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-12 14:59 +0000
            Re: annoying doctest problem Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-13 02:58 +1100
              Re: annoying doctest problem Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-12 16:46 +0000
          Re: annoying doctest problem Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-12 12:15 -0600
      Re: annoying doctest problem Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-12 06:32 -0600
    Re: annoying doctest problem Ned Batchelder <ned@nedbatchelder.com> - 2015-01-12 10:47 -0500
      Re: annoying doctest problem gordianknot1981@gmail.com - 2015-01-12 10:34 -0800

#83590 — annoying doctest problem

#!/usr/bin/python
# -*- coding: utf-8 -*-

import re
kivy_class_ptn      = re.compile(r"<\b[\w_.\@\+]+>:?")


def test_kivy_class(s):
    """
    >>> s = "<MYBT@ToggleButton+Button>:"
    >>> test_kivy_class(s)
    "<MYBT@ToggleButton+Button>:"
    >>> s = "<MYBT>"
    >>> test_kivy_class(s)
    "<MYBT>"
    """
    ret =  re.search(kivy_class_ptn, s)
    if ret: return ret.group()
    else:   return ''




if __name__ == "__main__":

    import doctest
    doctest.testmod()



output:

**********************************************************************
File "F:/MyDocument/[Programing]/Python/PhotoshopAsGui/python3_branch/regexSnippet.py", line 19, in __main__.test_kivy_class
Failed example:
    test_kivy_class(s)
Expected:
    "<MYBT@ToggleButton+Button>:"
Got:
    '<MYBT@ToggleButton+Button>:'
**********************************************************************
File "F:/MyDocument/[Programing]/Python/PhotoshopAsGui/python3_branch/regexSnippet.py", line 22, in __main__.test_kivy_class
Failed example:
    test_kivy_class(s)
Expected:
    "<MYBT>"
Got:
    '<MYBT>'
**********************************************************************
1 items had failures:
   2 of   8 in __main__.test_kivy_class
***Test Failed*** 2 failures.




It failed with an unknown reason that evaluate two expected equal value but got an unexpected result! I'm struggling with this problem for a long time. Did I did something wrong? And how do I to fix it?

any help is appreciated. :)

[toc] | [next] | [standalone]

#83591

gordian...@gmail.com於 2015年1月12日星期一 UTC+8下午12時20分46秒寫道：
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
> 
> import re
> kivy_class_ptn      = re.compile(r"<\b[\w_.\@\+]+>:?")
> 
> 
> def test_kivy_class(s):
>     """
>     >>> s = "<MYBT@ToggleButton+Button>:"
>     >>> test_kivy_class(s)
>     "<MYBT@ToggleButton+Button>:"
>     >>> s = "<MYBT>"
>     >>> test_kivy_class(s)
>     "<MYBT>"
>     """
>     ret =  re.search(kivy_class_ptn, s)
>     if ret: return ret.group()
>     else:   return ''
> 
> 
> 
> 
> if __name__ == "__main__":
> 
>     import doctest
>     doctest.testmod()
> 
> 
> 
> output:
> 
> **********************************************************************
> File "F:/MyDocument/[Programing]/Python/PhotoshopAsGui/python3_branch/regexSnippet.py", line 19, in __main__.test_kivy_class
> Failed example:
>     test_kivy_class(s)
> Expected:
>     "<MYBT@ToggleButton+Button>:"
> Got:
>     '<MYBT@ToggleButton+Button>:'
> **********************************************************************
> File "F:/MyDocument/[Programing]/Python/PhotoshopAsGui/python3_branch/regexSnippet.py", line 22, in __main__.test_kivy_class
> Failed example:
>     test_kivy_class(s)
> Expected:
>     "<MYBT>"
> Got:
>     '<MYBT>'
> **********************************************************************
> 1 items had failures:
>    2 of   8 in __main__.test_kivy_class
> ***Test Failed*** 2 failures.
> 
> 
> 
> 
> It failed with an unknown reason that evaluate two expected equal value but got an unexpected result! I'm struggling with this problem for a long time. Did I did something wrong? And how do I to fix it?
> 
> any help is appreciated. :)


Sorry for asking a dummy problem. I just solve it by changing the string quote from double to single. The problem is that doctest treat double quote string and single quote string as different value!


    >>> s = "<MYBT@ToggleButton+Button>:"
    >>> test_kivy_class(s)
    '<MYBT@ToggleButton+Button>:'   < change from double quote to single
    >>> s = "<MYBT>"             
    >>> test_kivy_class(s)
    '<MYBT>'                        < change from double quote to single

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

#83593

On Sun, 11 Jan 2015 20:20:35 -0800, gordianknot1981 wrote:
[...]
> Expected:
>     "<MYBT@ToggleButton+Button>:"
> Got:
>     '<MYBT@ToggleButton+Button>:'

doctest is *very* fussy about the strings matching exactly. You have to 
use single quotes.

I've been burned by this once or twice...


-- 
Steve

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

#83604

[Multipart message — attachments visible in raw view] — view raw

ISTR that when Tim Peters first implemented first, the typical way you were
expected to get tests into a doc string was to copy from an interactive
session, which would not have this problem.

Also, to Steven's comment about fussiness, it isn't so much that it's
fussy. It's more that it's dumb. I just does a simple string comparison of
the expected and actual outputs. It would be impossible for doctest to know
whether the expected output was something like repr or str output, and thus
safe to exchange single for double (don't forget to escape other embedded
quotes!), or was some sort of user-generated string, perhaps intended to be
text in  another programming language which has different quoting rules
than Python. Therefore, fussy (or dumb) is exactly what you want.

I-said-what-I-meant-ly y'rs,

Skip

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

#83607

Skip Montanaro wrote:

> ISTR that when Tim Peters first implemented first, the typical way you
> were expected to get tests into a doc string was to copy from an
> interactive session, which would not have this problem.

I believe that is still documented as the way to generate doctests.
 
> Also, to Steven's comment about fussiness, it isn't so much that it's
> fussy. It's more that it's dumb. I just does a simple string comparison of
> the expected and actual outputs. It would be impossible for doctest to
> know whether the expected output was something like repr or str output,
> and thus safe to exchange single for double (don't forget to escape other
> embedded quotes!), or was some sort of user-generated string, perhaps
> intended to be
> text in  another programming language which has different quoting rules
> than Python. Therefore, fussy (or dumb) is exactly what you want.

I didn't mean to give the impression that doctest was wrong to be fussy, or
dumb if you prefer. I think it's exactly the right behaviour.



-- 
Steven

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

#83611

On 12/01/2015 13:00, Steven D'Aprano wrote:
> Skip Montanaro wrote:
>
>> ISTR that when Tim Peters first implemented first, the typical way you
>> were expected to get tests into a doc string was to copy from an
>> interactive session, which would not have this problem.
>
> I believe that is still documented as the way to generate doctests.
>
>> Also, to Steven's comment about fussiness, it isn't so much that it's
>> fussy. It's more that it's dumb. I just does a simple string comparison of
>> the expected and actual outputs. It would be impossible for doctest to
>> know whether the expected output was something like repr or str output,
>> and thus safe to exchange single for double (don't forget to escape other
>> embedded quotes!), or was some sort of user-generated string, perhaps
>> intended to be
>> text in  another programming language which has different quoting rules
>> than Python. Therefore, fussy (or dumb) is exactly what you want.
>
> I didn't mean to give the impression that doctest was wrong to be fussy, or
> dumb if you prefer. I think it's exactly the right behaviour.
>

If doctest is dumb then that's clearly down to the author.  Perhaps we 
should refer him or her to the Zen of Python so they don't repeat the 
mistake with future design decisions?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#83614

Mark Lawrence wrote:

> If doctest is dumb then that's clearly down to the author.  Perhaps we
> should refer him or her to the Zen of Python so they don't repeat the
> mistake with future design decisions?

o_O


I don't even ... 

wait ... 

[starts typing]

[stops typing]

... okay.

-- 
Steven

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

#83615

On 12/01/2015 15:58, Steven D'Aprano wrote:
> Mark Lawrence wrote:
>
>> If doctest is dumb then that's clearly down to the author.  Perhaps we
>> should refer him or her to the Zen of Python so they don't repeat the
>> mistake with future design decisions?
>
> o_O
>
>
> I don't even ...
>
> wait ...
>
> [starts typing]
>
> [stops typing]
>
> ... okay.
>

Drat, drat and double drat, for just one minute I thought I'd hooked a 
large, highly respected Antipodean :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#83617

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 12, 2015 at 7:00 AM, Steven D'Aprano <
steve+comp.lang.python@pearwood.info> wrote:

> I didn't mean to give the impression that doctest was wrong to be fussy, or
> dumb if you prefer. I think it's exactly the right behaviour.
>

I wasn't actually concerned that Steven might have misunderstood how
doctest works, just that other less experienced programmers might interpret
his statement as suggesting that doctest's comparisons were somehow wrong
or might be made less "fussy". That word suggests to me that there is some
sort of critical evaluation by the fussy party going on (doctest, in this
case), when there is none. Which is why I chose the word "dumb."

Skip

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

#83606

On Mon, Jan 12, 2015 at 6:15 AM, Skip Montanaro
<skip.montanaro@gmail.com> wrote:
> ... first implemented first ...

s/first/doctest/

Darn auto-correct...

Skip

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

#83613

On 1/11/15 11:20 PM, gordianknot1981@gmail.com wrote:
>
> It failed with an unknown reason that evaluate two expected equal value but got an unexpected result! I'm struggling with this problem for a long time. Did I did something wrong? And how do I to fix it?
>
> any help is appreciated. :)
>

My recommendation is to use doctest to test the code samples that 
naturally occur in your docstrings, but not to use it as a 
general-purpose testing tool.  It has too many limitations and quirks, 
and if you're going to write separate test methods anyway, why not just 
write actual code?

More detail here: 
http://nedbatchelder.com/blog/200811/things_i_dont_like_about_doctest.html


-- 
Ned Batchelder, http://nedbatchelder.com

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

#83618

----------------------------------------------------------
> My recommendation is to use doctest to test the code samples that 
> naturally occur in your docstrings, but not to use it as a 
> general-purpose testing tool.  It has too many limitations and quirks, 
> and if you're going to write separate test methods anyway, why not just 
> write actual code?
> 
> More detail here: 
> http://nedbatchelder.com/blog/200811/things_i_dont_like_about_doctest.html
------------------------------------------------------------
"Docstrings may be good ways to explain what code does, but explaining and testing are two different tasks"......That's really to the point, and make sense. anyway, thanks for your article I benefit a lot from it.

[toc] | [prev] | [standalone]

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

csiph-web