date:20130520

On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
 
 We should continue to encourage users to make thorough unit tests
 and to leave doctests for documentation.  That said, it should be
 recognized that some testing is better than no testing.  And doctests
 may be attractive in that regard because it is almost effortless to
 cut-and-paste a snippet from the interactive prompt.  That isn't a
 best practice, but it isn't a worst practice either.

There are other reasons to hate doctest, such as the obnoxious
error reporting.  Having to wade through ten pages of output to find
what went wrong is no fun.

Also the difficulty of editing them. For some reason, my editor doesn't
offer me facilities to edit interactive prompt session snippets.

All in all, I try hard to ignore any doctest present in the Python test
suite.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

2013-05-20 Thread Tres Seaver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/19/2013 07:22 PM, Mark Janssen wrote:
 On Sun, May 19, 2013 at 1:13 PM, Tres Seaver tsea...@palladion.com
 wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 05/19/2013 10:48 AM, Guido van Rossum wrote:
 Anyway, if you're doing arithmetic on enums you're doing it
 wrong.
 
 Hmm, bitwise operations, even?
 
 I think it's rather pointless to do bitwise operations on python 
 enums.  We're not that close to the machine.

What, nobody uses Python to do networking?  How abaout driving the GPIO
on a RaspberryPI?  Using the bitwise operators to compbine named flag
values seems like a pretty natural fit to me (if you don't care about the
specific values, you don't need IntEnum anyway).


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGaEDwACgkQ+gerLs4ltQ5eXACfTrmegJsYDvbuwrbr5zyjwWV+
jMUAoIHQBi/qkm+MClGeh/ZwWOUGCMFm
=4ey/
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Ordering keyword dicts

2013-05-20 Thread Armin Rigo

Hi all,

On Sun, May 19, 2013 at 4:59 PM, Maciej Fijalkowski fij...@gmail.com wrote:
 Note that raymonds proposal would make dicts and ordereddicts almost
 exactly the same speed.

Just checking: in view of Raymond's proposal, is there a good reason
against  having all dicts be systematically ordered?  It would
definitely improve the debugging experience, by making multiple runs
of the same program more like each other, instead of depending on the
random address-based ordering.  (Performance-wise, I guess it might be
a little bit slower or faster depending on cache issues and so on, but
the emphasis I'd put is on the little bit.)

I apologize if this was already shot down.


A bientôt,

Armin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is documentation not inline?

2013-05-20 Thread Serhiy Storchaka


20.05.13 01:33, Benjamin Peterson написав(ла):

2013/5/19 Demian Brecht demianbre...@gmail.com:

It seems like external docs is standard throughout the stdlib. Is
there an actual reason for this?

ernal
One is legacy. It certainly wasn't possible with the old LaTeX doc
system.


Do you know that TeX itself written using a literate programming. TeX 
binary and the TeXbook are compiled from the same source.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is documentation not inline?

2013-05-20 Thread Stefan Drees


On 20.05.13 14:37, Serhiy Storchaka wrote:

20.05.13 01:33, Benjamin Peterson написав(ла):

2013/5/19 Demian Brecht demianbre...@gmail.com:

It seems like external docs is standard throughout the stdlib. Is
there an actual reason for this?

ernal
One is legacy. It certainly wasn't possible with the old LaTeX doc
system.


Do you know that TeX itself written using a literate programming. TeX
binary and the TeXbook are compiled from the same source.


Separation of concerns and DRY - tension rising:

Who wants to tangle and weave? Anyone :-?)


All the best,
Stefan

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

2013-05-20 Thread Steven D'Aprano


On 20/05/13 20:45, Antoine Pitrou wrote:

On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:


We should continue to encourage users to make thorough unit tests
and to leave doctests for documentation.  That said, it should be
recognized that some testing is better than no testing.  And doctests
may be attractive in that regard because it is almost effortless to
cut-and-paste a snippet from the interactive prompt.  That isn't a
best practice, but it isn't a worst practice either.


There are other reasons to hate doctest, such as the obnoxious
error reporting.  Having to wade through ten pages of output to find
what went wrong is no fun.


Ten pages of broken unit tests are no picnic either.

If you have ten pages of failures, then it doesn't matter *what* testing 
framework you use, you're going to have a bad time. But personally, I find doc 
test error reports perfectly clear and readable, and not overly verbose.

File test.py, line 4, in __main__
Failed example:
len(abcd)
Expected:
24
Got:
4


That's even simpler than a traceback.



Also the difficulty of editing them. For some reason, my editor doesn't
offer me facilities to edit interactive prompt session snippets.


Your text editor doesn't allow you to edit text? Even Notepad allows that!

Seriously, what editor are you using that doesn't allow you to edit pasted 
snippets?




--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 409 and the stdlib


As a quick reminder, PEP 409 allows this:

try:
...
except AnError:
raise SomeOtherError from None

so that if the exception is not caught, we get the traditional single exception 
traceback, instead of the new:

During handling of the above exception, another exception occurred


My question:

How do we go about putting this in the stdlib?  Is this one of the occasions where we don't do it unless we're modifying 
a module already for some other reason?


For that matter, should we?

Pros:  Makes tracebacks much less confusing, especially coming from a library

Cons:  Could hide bugs unrelated to what is being caught and transformed

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On Mon, 20 May 2013 23:32:10 +1000
Steven D'Aprano st...@pearwood.info wrote:
 On 20/05/13 20:45, Antoine Pitrou wrote:
  On Sat, 18 May 2013 23:41:59 -0700
  Raymond Hettinger raymond.hettin...@gmail.com wrote:
 
  We should continue to encourage users to make thorough unit tests
  and to leave doctests for documentation.  That said, it should be
  recognized that some testing is better than no testing.  And doctests
  may be attractive in that regard because it is almost effortless to
  cut-and-paste a snippet from the interactive prompt.  That isn't a
  best practice, but it isn't a worst practice either.
 
  There are other reasons to hate doctest, such as the obnoxious
  error reporting.  Having to wade through ten pages of output to find
  what went wrong is no fun.
 
 Ten pages of broken unit tests are no picnic either.

You didn't understand the objection. I'm talking about *one* broken
doctest in a sea of non-broken ones. For some reason doctest (or its
unittest driver) insists on either displaying everything, or nothing.
It doesn't only print the errors and leave the rest silent.

  Also the difficulty of editing them. For some reason, my editor doesn't
  offer me facilities to edit interactive prompt session snippets.
 
 Your text editor doesn't allow you to edit text? Even Notepad allows that!
 
 Seriously, what editor are you using that doesn't allow you to edit pasted 
 snippets?

I don't know if you're intentionally being stupid. Of course I can edit
them *by hand*. But I'll have to re-create by hand the various
artifacts of an interpreter session, e.g. the prompts.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Ordering keyword dicts

On May 20, 2013, at 02:30 PM, Armin Rigo wrote:

Just checking: in view of Raymond's proposal, is there a good reason
against  having all dicts be systematically ordered?  It would
definitely improve the debugging experience, by making multiple runs
of the same program more like each other, instead of depending on the
random address-based ordering.  (Performance-wise, I guess it might be
a little bit slower or faster depending on cache issues and so on, but
the emphasis I'd put is on the little bit.)

I'm ambivalent on the proposal -- I could get behind it if it was demonstrably
*not* a performance hit (I'm already fighting enough Python is too slow
battles).

However, if such a change were made, I think it must be adopted as a change
to the language specification.  Meaning, if dicts (or even just keyword
arguments) are to be ordered, it can't be as a side-effect of the
implementation.  We've had a lot of churn getting code and tests to the point
where most libraries have adjusted to the undefined order of dictionary
iteration.  I don't want to go back to the situation where lots of implicit
ordering assumptions caused broken code when run in one implementation or
another.

Or in other words, if dicts are to be ordered, let's make it an explicit
language feature that we can measure compliance against.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On Mon, 20 May 2013 12:45:57 +0200, Antoine Pitrou solip...@pitrou.net wrote:
 On Sat, 18 May 2013 23:41:59 -0700
 Raymond Hettinger raymond.hettin...@gmail.com wrote:
  
  We should continue to encourage users to make thorough unit tests
  and to leave doctests for documentation.  That said, it should be
  recognized that some testing is better than no testing.  And doctests
  may be attractive in that regard because it is almost effortless to
  cut-and-paste a snippet from the interactive prompt.  That isn't a
  best practice, but it isn't a worst practice either.
 
 There are other reasons to hate doctest, such as the obnoxious
 error reporting.  Having to wade through ten pages of output to find
 what went wrong is no fun.

That's why I added the 'failfast' option to doctest.

 Also the difficulty of editing them. For some reason, my editor doesn't
 offer me facilities to edit interactive prompt session snippets.

I don't have much problem with lacking tailored facilities for this
in vim.  I suppose that is a matter of personal style.  I *would* like to
teach it the proper indentation, but I haven't been bothered enough yet
to do it.  (After all, weren't you the one who told me the lack of tab
key indentation at the interactive prompt after you enabled completion
by default wasn't an issue because one could just use space to indent? :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is documentation not inline?

On Mon, 20 May 2013 15:02:08 +0200, Stefan Drees ste...@drees.name wrote:
 On 20.05.13 14:37, Serhiy Storchaka wrote:
  20.05.13 01:33, Benjamin Peterson Ð½Ð°Ð¿Ð¸ÑÐ°Ð²(Ð»Ð°):
  2013/5/19 Demian Brecht demianbre...@gmail.com:
  It seems like external docs is standard throughout the stdlib. Is
  there an actual reason for this?
  ernal
  One is legacy. It certainly wasn't possible with the old LaTeX doc
  system.
 
  Do you know that TeX itself written using a literate programming. TeX
  binary and the TeXbook are compiled from the same source.
 
 Separation of concerns and DRY - tension rising:
 
 Who wants to tangle and weave? Anyone :-?)

I loved that concept so much when I first encountered it that I
subsequently wrote systems (in REXX :) for doing something similar on two
big projects I worked in my IBM mainframe days (one of them using SGML,
if anyone remembers when there were actual source-to-printed-document
systems for SGML).  I guess I pretty much forgot about it when I moved
to unix, but I suppose it is one of the reasons I do like doctest.

A quick google tells me there are some links I should check out :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

2013-05-20 Thread Nick Coghlan

On 20 May 2013 23:38, Ethan Furman et...@stoneleaf.us wrote:

 As a quick reminder, PEP 409 allows this:

 try:
 ...
 except AnError:
 raise SomeOtherError from None

 so that if the exception is not caught, we get the traditional single
exception traceback, instead of the new:

 During handling of the above exception, another exception occurred


 My question:

 How do we go about putting this in the stdlib?  Is this one of the
occasions where we don't do it unless we're modifying a module already for
some other reason?

 For that matter, should we?

 Pros:  Makes tracebacks much less confusing, especially coming from a
library

 Cons:  Could hide bugs unrelated to what is being caught and transformed

Be pretty conservative with this one - we should only use it when we're
confident we know the original exception is almost certain to be irrelevant
noise.

Ensuring the traceback module makes it easy to display both would also be a
good preliminary step.

Cheers,
Nick.


 --
 ~Ethan~
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

On Mon, 20 May 2013 06:12:41 -0700, Ethan Furman et...@stoneleaf.us wrote:
 As a quick reminder, PEP 409 allows this:
 
  try:
  ...
  except AnError:
  raise SomeOtherError from None
 
 so that if the exception is not caught, we get the traditional single 
 exception traceback, instead of the new:
 
  During handling of the above exception, another exception occurred
 
 
 My question:
 
 How do we go about putting this in the stdlib?  Is this one of the occasions 
 where we don't do it unless we're modifying 
 a module already for some other reason?
 
 For that matter, should we?
 
 Pros:  Makes tracebacks much less confusing, especially coming from a library
 
 Cons:  Could hide bugs unrelated to what is being caught and transformed

I'm pretty sure the answer is almost never.

I think a case needs to be made for any place that seems like it would
actually improve things, because usually I don't think it will, in the
stdlib.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On Mon, 20 May 2013 09:37:32 -0400
R. David Murray rdmur...@bitdance.com wrote:
 On Mon, 20 May 2013 12:45:57 +0200, Antoine Pitrou solip...@pitrou.net 
 wrote:
  On Sat, 18 May 2013 23:41:59 -0700
  Raymond Hettinger raymond.hettin...@gmail.com wrote:
   
   We should continue to encourage users to make thorough unit tests
   and to leave doctests for documentation.  That said, it should be
   recognized that some testing is better than no testing.  And doctests
   may be attractive in that regard because it is almost effortless to
   cut-and-paste a snippet from the interactive prompt.  That isn't a
   best practice, but it isn't a worst practice either.
  
  There are other reasons to hate doctest, such as the obnoxious
  error reporting.  Having to wade through ten pages of output to find
  what went wrong is no fun.
 
 That's why I added the 'failfast' option to doctest.

I didn't know that. Is it propagated by regrtest? I never use doctest
standalone.

  Also the difficulty of editing them. For some reason, my editor doesn't
  offer me facilities to edit interactive prompt session snippets.
 
 I don't have much problem with lacking tailored facilities for this
 in vim.  I suppose that is a matter of personal style.  I *would* like to
 teach it the proper indentation, but I haven't been bothered enough yet
 to do it.  (After all, weren't you the one who told me the lack of tab
 key indentation at the interactive prompt after you enabled completion
 by default wasn't an issue because one could just use space to indent? :)

An interpreter prompt session is throwaway, so you can pretty much
indent as you like (which may not be very pretty in a tests file).
Besides, I was thinking about the prompts (' ' and '... '), not the
indentation itself.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

On 05/20/2013 06:47 AM, Nick Coghlan wrote:

On 20 May 2013 23:38, Ethan Furman wrote:

As a quick reminder, PEP 409 allows this:

try:
...
except AnError:
raise SomeOtherError from None

so that if the exception is not caught, we get the traditional single exception
traceback, instead of the new:

During handling of the above exception, another exception occurred

My question:

How do we go about putting this in the stdlib? Is this one of the occasions
where we don't do it unless we're modifying a module already for some other
reason?

For that matter, should we?

Pros: Makes tracebacks much less confusing, especially coming from a library

Cons: Could hide bugs unrelated to what is being caught and transformed

Be pretty conservative with this one - we should only use it when we're
confident we know the original exception is
almost certain to be irrelevant noise.

Ensuring the traceback module makes it easy to display both would also be a
good preliminary step.

As a case in point, base64.py is currently getting a bug fix, and also contains
this code:

def b32decode(s, casefold=False, map01=None):
.
.
.
for i in range(0, len(s), 8):
quanta = s[i: i + 8]
acc = 0
try:
for c in quanta:
acc = (acc 5) + b32rev[c]
except KeyError:
raise binascii.Error('Non-base32 digit found')
.
.
.
else:
raise binascii.Error('Incorrect padding')

Does the KeyError qualify as irrelevant noise?

If we're not going to suppress the originating error I think we should at least change the double trace back message as
it implies two failures, instead of just one.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On Mon, 20 May 2013 15:57:35 +0200, Antoine Pitrou solip...@pitrou.net wrote:
 On Mon, 20 May 2013 09:37:32 -0400
 R. David Murray rdmur...@bitdance.com wrote:
  On Mon, 20 May 2013 12:45:57 +0200, Antoine Pitrou solip...@pitrou.net 
  wrote:
   On Sat, 18 May 2013 23:41:59 -0700
   Raymond Hettinger raymond.hettin...@gmail.com wrote:

We should continue to encourage users to make thorough unit tests
and to leave doctests for documentation.  That said, it should be
recognized that some testing is better than no testing.  And doctests
may be attractive in that regard because it is almost effortless to
cut-and-paste a snippet from the interactive prompt.  That isn't a
best practice, but it isn't a worst practice either.
   
   There are other reasons to hate doctest, such as the obnoxious
   error reporting.  Having to wade through ten pages of output to find
   what went wrong is no fun.
  
  That's why I added the 'failfast' option to doctest.
 
 I didn't know that. Is it propagated by regrtest? I never use doctest
 standalone.

I don't think so.  That's a good idea, though.

   Also the difficulty of editing them. For some reason, my editor doesn't
   offer me facilities to edit interactive prompt session snippets.
  
  I don't have much problem with lacking tailored facilities for this
  in vim.  I suppose that is a matter of personal style.  I *would* like to
  teach it the proper indentation, but I haven't been bothered enough yet
  to do it.  (After all, weren't you the one who told me the lack of tab
  key indentation at the interactive prompt after you enabled completion
  by default wasn't an issue because one could just use space to indent? :)
 
 An interpreter prompt session is throwaway, so you can pretty much
 indent as you like (which may not be very pretty in a tests file).
 Besides, I was thinking about the prompts (' ' and '... '), not the
 indentation itself.

True.  I don't find typing  or ... very burdensome, though.  Less
even than fixing the alignment after hitting tab :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

On Mon, 20 May 2013 07:12:07 -0700, Ethan Furman et...@stoneleaf.us wrote:
 As a case in point, base64.py is currently getting a bug fix, and also
 contains this code:
 
 def b32decode(s, casefold=False, map01=None):
  .
  .
  .
  for i in range(0, len(s), 8):
  quanta = s[i: i + 8]
  acc = 0
  try:
  for c in quanta:
  acc = (acc  5) + b32rev[c]
  except KeyError:
  raise binascii.Error('Non-base32 digit found')
  .
  .
  .
  else:
  raise binascii.Error('Incorrect padding')
 
 Does the KeyError qualify as irrelevant noise?

I don't see that it is of benefit to suppress it.

 If we're not going to suppress the originating error I think we should
 at least change the double trace back message as it implies two
 failures, instead of just one.

I don't understand what you want to do here.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On May 18, 2013, at 11:41 PM, Raymond Hettinger wrote:

I'm hoping that core developers don't get caught-up in the doctests are bad
meme.

Thanks for your message Raymond.  I know that doctests are controversial, but
I do firmly believe that when used correctly, they have value and should not
be broken without careful consideration.

You make excellent points about Python 3 adoption and the canary-like nature
of doctests.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Ordering keyword dicts

2013-05-20 Thread fwierzbi...@gmail.com

On Mon, May 20, 2013 at 6:39 AM, Barry Warsaw ba...@python.org wrote:
 Or in other words, if dicts are to be ordered, let's make it an explicit
 language feature that we can measure compliance against.
Guaranteeing a dict order would be tough on Jython - today it's nice
that we can just have a thin wrapper around ConcurrentHashMap. In a
world with hard ordering guarantees I think we'd need to write our own
from scratch.

-Frank
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On May 19, 2013, at 07:28 PM, Tim Peters wrote:

But more than just one ;-)  Another great use has nothing to do with
docstrings:  using an entire file as a doctest.   This encourages
writing lots of text explaining what you're doing,. with snippets of
code interspersed to illustrate that the code really does behave in
the ways you've claimed.

Agreed!  I love separate-file doctests, and the marriage of doctests and
reST/Sphinx is just fantastic.  It's a pleasure to write usage documentation
that contains code samples that are guaranteed to work, because they pass
their doctest.  (I personally don't like long-winded docstring doctests
because they are harder to edit and distract from the code, but YMMV.)

Several years ago, I spent some time experimenting with using doctest for
*everything*.  I deliberately wanted to go that extreme in order to better
explore where doctests are good and where they're not so good.  A general rule
of thumb I came up with is that reST-style doctests are great for explanations
involving mostly good-path usage of a library, or IOW this is how you're
supposed to use this API, and see it works!.

IME, doctests are not so good at testing all the failure modes, odd corner
cases, and the perhaps less-common good-path use cases.  Fortunately, we have
another useful tool for testing that stuff wink.

I'd rather encourage users to turn their brains on when writing
doctest files - and when writing unit tests.  I've lost count of how
many times I've seen a unit test fail, then stared helplessly at the
unit test code just trying to figure out what the author thought they
were doing.  A lot of comments in the test code could have helped
that, but - outside of doctest-based tests - there's typically very
little explanatory text in testing code.

+1

A rule-of-thumb I use is what I call the FORTH rule[1].  If you should be able
to understand what your own test is trying to accomplish a week later,
otherwise you're not writing very good tests. ;)

-Barry

[1] or PERL rule maybe, depending on the unit of time. :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On May 19, 2013, at 04:27 PM, Gregory P. Smith wrote:

Idea: I don't believe anybody has written a fixer for lib2to3 that applies
fixers to doctests.  That'd be an interesting project for someone.

I'm not sure that's true.  I don't use 2to3 anymore if I can help it, but I'm
pretty sure you can 2to3 your doctests too.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Ordering keyword dicts

2013-05-20 Thread Guido van Rossum

I think that kills the let's make all dicts ordered idea, even for
CPython. I wouldn't want people to start relying on this. The dict type
should be clearly recognizable as the hash table it is.

Making **kwds ordered is still open, but requires careful design and
implementation to avoid slowing down function calls that don't benefit.

--Guido van Rossum (sent from Android phone)
On May 20, 2013 8:25 AM, fwierzbi...@gmail.com fwierzbi...@gmail.com
wrote:

 On Mon, May 20, 2013 at 6:39 AM, Barry Warsaw ba...@python.org wrote:
  Or in other words, if dicts are to be ordered, let's make it an explicit
  language feature that we can measure compliance against.
 Guaranteeing a dict order would be tough on Jython - today it's nice
 that we can just have a thin wrapper around ConcurrentHashMap. In a
 world with hard ordering guarantees I think we'd need to write our own
 from scratch.

 -Frank
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/guido%40python.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib


On 05/20/2013 07:50 AM, R. David Murray wrote:

On Mon, 20 May 2013 07:12:07 -0700, Ethan Furman wrote:

As a case in point, base64.py is currently getting a bug fix, and also
contains this code:

def b32decode(s, casefold=False, map01=None):
  .
  .
  .
  for i in range(0, len(s), 8):
  quanta = s[i: i + 8]
  acc = 0
  try:
  for c in quanta:
  acc = (acc  5) + b32rev[c]
  except KeyError:
  raise binascii.Error('Non-base32 digit found')
  .
  .
  .
  else:
  raise binascii.Error('Incorrect padding')

Does the KeyError qualify as irrelevant noise?


I don't see that it is of benefit to suppress it.


If we're not going to suppress the originating error I think we should
at least change the double trace back message as it implies two
failures, instead of just one.


I don't understand what you want to do here.


As a user of the b32decode the KeyError is an implementation detail and noise in the traceback.  If I've got a 
non-base32 digit in my submitted string then the only exception I care about is the binascii.Error... but I'm going to 
see both, and the wording is such that it seems like I have two errors to deal with instead of just one.


So I guess I see three options here:

1)  Do nothing and be happy I use 'raise ... from None' in my own libraries

2)  Change the wording of 'During handling of the above exception, another exception occurred' (no ideas as to what at 
the moment)


3)  have the traceback module be configurable to show both exceptions even when 'raise ... from None' is used to help 
with debugging, then we can make the changes in stdlib confident that in our own testing of bugs we can see all 
available information.


I would prefer 3, but I can live with 1.  :)

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

2013-05-20 Thread Steven D'Aprano


On 21/05/13 00:12, Ethan Furman wrote:



As a case in point, base64.py is currently getting a bug fix, and also contains 
this code:

def b32decode(s, casefold=False, map01=None):
 .
 .
 .
 for i in range(0, len(s), 8):
 quanta = s[i: i + 8]
 acc = 0
 try:
 for c in quanta:
 acc = (acc  5) + b32rev[c]
 except KeyError:
 raise binascii.Error('Non-base32 digit found')
 .
 .
 .
 else:
 raise binascii.Error('Incorrect padding')

Does the KeyError qualify as irrelevant noise?



IMO, it is irrelevant noise, and obviously so. The binascii.Error raised is not a bug to 
be fixed, it is a deliberate exception and part of the API of the binascii module. That 
it occurs inside an except KeyError block is a mere implementation detail. It 
merely happens to be that digits are converted by looking up in a mapping, another 
implementation might use a completely different mechanism. In fact, the implementation in 
Python 3.3 *is* completely different, and there is no KeyError to suppress.

In another reply, R.David Murray answered:

I don't see that it is of benefit to suppress [the KeyError].

Can I suggest that it's obviously been a long, long time since you were a 
beginner to the language, and you've forgotten how intimidating error messages 
can be? Error messages should be *relevant*. Irrelevant details don't help, 
they hinder, and I suggest that the KeyError is irrelevant.




--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

On Mon, 20 May 2013 07:12:07 -0700
Ethan Furman et...@stoneleaf.us wrote:
 
 As a case in point, base64.py is currently getting a bug fix, and also 
 contains this code:
 
 def b32decode(s, casefold=False, map01=None):
  .
  .
  .
  for i in range(0, len(s), 8):
  quanta = s[i: i + 8]
  acc = 0
  try:
  for c in quanta:
  acc = (acc  5) + b32rev[c]
  except KeyError:
  raise binascii.Error('Non-base32 digit found')
  .
  .
  .
  else:
  raise binascii.Error('Incorrect padding')
 
 Does the KeyError qualify as irrelevant noise?

I think it is a legitimate case where to silence the original
exception. However, the binascii.Error would be more informative if it
said *which* non-base32 digit was encountered.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

2013-05-20 Thread Steven D'Aprano


On 20/05/13 23:38, Antoine Pitrou wrote:

On Mon, 20 May 2013 23:32:10 +1000
Steven D'Aprano st...@pearwood.info wrote:

On 20/05/13 20:45, Antoine Pitrou wrote:

On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:


We should continue to encourage users to make thorough unit tests
and to leave doctests for documentation.  That said, it should be
recognized that some testing is better than no testing.  And doctests
may be attractive in that regard because it is almost effortless to
cut-and-paste a snippet from the interactive prompt.  That isn't a
best practice, but it isn't a worst practice either.


There are other reasons to hate doctest, such as the obnoxious
error reporting.  Having to wade through ten pages of output to find
what went wrong is no fun.


Ten pages of broken unit tests are no picnic either.


You didn't understand the objection. I'm talking about *one* broken
doctest in a sea of non-broken ones. For some reason doctest (or its
unittest driver) insists on either displaying everything, or nothing.
It doesn't only print the errors and leave the rest silent.



It sounds like you are inadvertently calling doctest with the verbose option. It is not 
standard behaviour to display everything or nothing. Here is the output from 
1 failing test out of 112, with absolutely nothing edited.


[steve@ando ~]$ python test.py
**
File test.py, line 224, in __main__
Failed example:
len(abcd)
Expected:
24
Got:
4
**
1 items had failures:
   1 of 112 in __main__
***Test Failed*** 1 failures.


If I had any criticism of doctest, it would be that by default it prints 
nothing at all if all tests pass. I hate that, ever since I had a bunch of 
doctests that for about a week I thought were passing when in fact they weren't 
running at all. So now I always write something like this:


if __name__ == '__main__':
import doctest
failed, tried = doctest.testmod()
if failed == 0:
print(Successfully ran %d tests % tried)



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On Tue, 21 May 2013 02:00:32 +1000
Steven D'Aprano st...@pearwood.info wrote:

 On 20/05/13 23:38, Antoine Pitrou wrote:
  On Mon, 20 May 2013 23:32:10 +1000
  Steven D'Aprano st...@pearwood.info wrote:
  On 20/05/13 20:45, Antoine Pitrou wrote:
  On Sat, 18 May 2013 23:41:59 -0700
  Raymond Hettinger raymond.hettin...@gmail.com wrote:
 
  We should continue to encourage users to make thorough unit tests
  and to leave doctests for documentation.  That said, it should be
  recognized that some testing is better than no testing.  And doctests
  may be attractive in that regard because it is almost effortless to
  cut-and-paste a snippet from the interactive prompt.  That isn't a
  best practice, but it isn't a worst practice either.
 
  There are other reasons to hate doctest, such as the obnoxious
  error reporting.  Having to wade through ten pages of output to find
  what went wrong is no fun.
 
  Ten pages of broken unit tests are no picnic either.
 
  You didn't understand the objection. I'm talking about *one* broken
  doctest in a sea of non-broken ones. For some reason doctest (or its
  unittest driver) insists on either displaying everything, or nothing.
  It doesn't only print the errors and leave the rest silent.
 
 
 It sounds like you are inadvertently calling doctest with the verbose option. 
 It is not standard behaviour to display everything or nothing.

Well, I never run doctest directly, I use regrtest (there are some
doctests in the standard library). So perhaps the blame lies on
regrtest or on the unittest adapter, my bad.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

Hi !
:)

I'll be replying some individual messages in this thread in spite of
putting my replies in the right context . Sorry if I repeat something
, or this makes the thread hard to read . Indeed , IMHO this is a
subject suitable to discuss in TiP ML .

On 5/19/13, Gregory P. Smith g...@krypto.org wrote:
 On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger 
 raymond.hettin...@gmail.com wrote:


 On May 14, 2013, at 9:39 AM, Gregory P. Smith g...@krypto.org wrote:

 Bad: doctests.


 I'm hoping that core developers don't get caught-up in the doctests are
 bad meme.


 So long as doctests insist on comparing the repr of things being the number
 one practice that people use when writing them there is no other position I
 can hold on the matter.  reprs are not stable and never have been.
  ordering changes, hashes change, ids change, pointer values change,
 wording and presentation of things change.  none of those side effect
 behaviors were ever part of the public API to be depended on.


«Bad doctests» slogan is not positive because the subliminal message
for new users is «there's something wrong with that ... let's better
not use it» . IMHO that's not true ; doctest is an incredibly awesome
testing framework for delta assertions and there is nothing wrong with
the philosophy behind that module and its intent .

This surfaces an issue I've noticed years ago wrt doctest module (so,
yes , it's obvious there's an issue ;) . The way I see it this is more
about the fact that module frontend does not offer the means to
benefit from all the possibilities of doctest classes in the backend
(e.g. output checkers , doctest runners, ...)

 That one can write doctests that don't depend on such things as the repr
 doesn't ultimately matter because the easiest thing to do, as encouraged by
 examples that are pasted from an interactive interpreter session into docs,
 is to have the interactive interpreter show the repr and not add code to
 check things in a accurate-for-testing manner that would otherwise make the
 documentation harder for a human to read.


This is something that could be easily mitigated by a custom output
checker . In the end , in docs there is no difference between output
messages like 'Spam object at 0xb7cf5d70' or 'Spam object at
0x1' (i.e. some deterministic label like computed hex number or
anything else ...) . You might also avoid printing repr(s)

 Instead, we should be clear about their primary purpose which is to test
 the examples given in docstrings.   In many cases, there is a great deal
 of benefit to docstrings that have worked-out examples (see the
 docstrings
 in the decimal module for example).  In such cases it is also worthwhile
 to make sure those examples continue to match reality. Doctests are
 a vehicle for such assurance.  In other words, doctests have a perfectly
 legitimate use case.


 I really do applaud the goal of keeping examples in documentation up to
 date.  But doctest as it is today is the wrong approach to that. A repr
 mismatch does not mean the example is out of date.


... and I confess I never use doctest «as it is today» in stdlib . So
, you are right .

 We should continue to encourage users to make thorough unit tests
 and to leave doctests for documentation.  That said, it should be
 recognized that some testing is better than no testing.  And doctests
 may be attractive in that regard because it is almost effortless to
 cut-and-paste a snippet from the interactive prompt.  That isn't a
 best practice, but it isn't a worst practice either.


 Not quite, they at least tested something (yay!) but it is uncomfortably
 close to a worst practice.


I disagree . IMO what is a bad practice is to spread the rumor that
«doctests are evil» rather than saying «doctest module has
limitations»

 It means someone else needs to come understand the body of code containing
 this doctest when they make an unrelated change that triggered a behavior
 change as a side effect that the doctested code may or may not actually
 depend on but does not actually declare its intent one way or another for
 the purposes of being a readable example rather than accurate test.


I see no problem in keeping both these aspects .

 bikeshed colors: If doctest were never called a test but instead were
 called docchecker to not imply any testing aspect

No way ! ( IMHO )

I just wrote dutest [1]_ framework , built on top of doctest and
unittest , that does the following (among other things) :

  1. Implements unittest loaders for doctests
  2. Allows for customizing output checkers , doctest runners , ...
  anything you might find in the backend
 * For instance , replacing default test runner and output checkers
   might be useful to write delta assertions for command-line scripts
  3. Tightly integrated with unittest (e.g. custom TestSuite(s) ...)
  4. Access to unittest test case in special __tc__ variable , so all
  known assertion methods are handy ootb
  5. Encapsulate

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

-- Forwarded message --
From: Olemis Lang ole...@gmail.com
Date: Mon, 20 May 2013 11:33:42 -0500
Subject: Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
To: Antoine Pitrou solip...@pitrou.net

On 5/20/13, Antoine Pitrou solip...@pitrou.net wrote:
 On Sat, 18 May 2013 23:41:59 -0700
 Raymond Hettinger raymond.hettin...@gmail.com wrote:

 We should continue to encourage users to make thorough unit tests
 and to leave doctests for documentation.  That said, it should be
 recognized that some testing is better than no testing.  And doctests
 may be attractive in that regard because it is almost effortless to
 cut-and-paste a snippet from the interactive prompt.  That isn't a
 best practice, but it isn't a worst practice either.

 There are other reasons to hate doctest, such as the obnoxious
 error reporting.  Having to wade through ten pages of output to find
 what went wrong is no fun.

+1

FWIW , while using dutest [1]_ each interactive example will be a test
case and therefore the match for that particular assertion will be
reported using the usual unittest output format

.. [1] dutest
(https://pypi.python.org/pypi/dutest)

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

2013-05-20 Thread Mark Janssen

 I'm hoping that core developers don't get caught-up in the doctests are bad
 meme.

 Instead, we should be clear about their primary purpose which is to test
 the examples given in docstrings.
 In other words, doctests have a perfectly legitimate use case.

 But more than just one ;-)  Another great use has nothing to do with
 docstrings:  using an entire file as a doctest.   This encourages
 writing lots of text explaining what you're doing,. with snippets of
 code interspersed to illustrate that the code really does behave in
 the ways you've claimed.

+1, very true.  I think doctest excel in almost every way above
UnitTests.  I don't understand the popularity of  UnitTests, except
perhaps for GUI testing which doctest can't handle.  I think people
just aren't very *imaginative* about how to create good doctests that
are *also* good documentation.

That serves two very good purposes in one.  How can you beat that?
The issues of teardown and setup are fixable and even more beautifully
solved with doctests -- just use the lexical scoping of the program to
determine the execution environment for the doctests.

 picking-your-poison-ly y'rs  - tim

Cheers,

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

2013-05-20 Thread Georg Brandl

Am 20.05.2013 17:39, schrieb Steven D'Aprano:
 On 21/05/13 00:12, Ethan Furman wrote:
 
 
 As a case in point, base64.py is currently getting a bug fix, and also
 contains this code:
 
 def b32decode(s, casefold=False, map01=None): . . . for i in range(0,
 len(s), 8): quanta = s[i: i + 8] acc = 0 try: for c in quanta: acc = (acc
  5) + b32rev[c] except KeyError: raise binascii.Error('Non-base32 digit
 found') . . . else: raise binascii.Error('Incorrect padding')
 
 Does the KeyError qualify as irrelevant noise?
 
 
 IMO, it is irrelevant noise, and obviously so. The binascii.Error raised is
 not a bug to be fixed, it is a deliberate exception and part of the API of
 the binascii module. That it occurs inside an except KeyError block is a
 mere implementation detail. It merely happens to be that digits are converted
 by looking up in a mapping, another implementation might use a completely
 different mechanism. In fact, the implementation in Python 3.3 *is*
 completely different, and there is no KeyError to suppress.
 
 In another reply, R.David Murray answered:
 
 I don't see that it is of benefit to suppress [the KeyError].
 
 Can I suggest that it's obviously been a long, long time since you were a
 beginner to the language, and you've forgotten how intimidating error
 messages can be? Error messages should be *relevant*. Irrelevant details
 don't help, they hinder, and I suggest that the KeyError is irrelevant.

I agree. This is a case of a well isolated exception where there's no chance
of hiding a bug because the KeyError was exceptional (wink/).

The argument of not making it harder than necessary to beginners (or casual
users) seems valid to me, and since the code is being touched anyway, there
shouldn't be unnecessary code churn.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On 5/19/13, Steven D'Aprano st...@pearwood.info wrote:
 On 20/05/13 09:27, Gregory P. Smith wrote:
 On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger 
 raymond.hettin...@gmail.com wrote:


 On May 14, 2013, at 9:39 AM, Gregory P. Smith g...@krypto.org wrote:

 Bad: doctests.


 I'm hoping that core developers don't get caught-up in the doctests are
 bad meme.


 So long as doctests insist on comparing the repr of things being the
 number
 one practice that people use when writing them there is no other position
 I
 can hold on the matter.  reprs are not stable and never have been.

 I think this *massively* exaggerates the problem with doc tests.

I agree , and it is a negative influence for beginners .

 I make
 heavy use of them, and have no problem writing doc tests that work in code
 running over multiple versions, including from 2.4 through 3.3. Objects that
 I write myself, I control the repr and can make it as stable as I wish. Many
 built-in types also have stable reprs. The repr for small ints is not going
 to change, the repr for floats like 0.5, 0.25, 0.125 etc. are stable and
 predictable, lists and tuples and strings all have stable well-defined
 reprs. Dicts are a conspicuous counter-example, but there are trivial
 work-arounds.


+1

 Doc tests are not limited to a simple-minded compare the object's repr.

Yes

 You can write as much, or as little, scaffolding around the test as you
 need. If the scaffolding becomes too large, that's a sign that the test
 doesn't belong in documentation and should be moved out, perhaps into a unit
 test, or perhaps into a separate literate testing document that can be as
 big as necessary without overwhelming the doc string.


There is an alternate approach related to a feature of dutest [1]_ I
mentioned in a previous message (i.e. doctests setUp and tearDown
methods) . The main reason to desire to leave long doctests
scaffolding code out (e.g. loading a Trac environment, or setting up a
separate Python virtual environment , subversion repository , ... as
part of -unit, functional, ...- test setup ) is to focus on SUT / API
details , avoid repetition of some steps , and keep tests readable .
This code is moved to underlying unittest setUp method and it's still
possible to write readable doctests for the particular feature of the
SUT .

In general there's a need to find a balance to decide what should be
«hidden» in doctests fixture methods and what should be written in
doctests . Based on my experience there's no benefit in using unittest
over doctests

unittests :

  - are unreadable
  - require knowledge of XUnit , etc ...
  - Writing complex assertions might be hard and tedious

doctests:

  - are extremely readable
  - anybody familiar with the SUT could write tests
  - especially for modules that are meant to be used by persons
who are not (professional / skilled) software developers
encapsulating the use of a testing framework is a plus ;
your test suite is «talking in users language»
(/me not sure about stdlib ...)


   ordering changes, hashes change, ids change, pointer values change,
 wording and presentation of things change.  none of those side effect
 behaviors were ever part of the public API to be depended on.

 Then don't write doctests that depend on those things. It really is that
 simple. There's no rule that says doctests have to test the entire API.
 Doctests in docstrings are *documentation first*, so you write tests that
 make good documentation.


... but someone could do so , if it wasn't by the current limitations
of doctest frontend .
;)

 The fact that things that are not stable parts of the API can be tested is
 independent of the framework you use to do the testing. If I, as an ignorant
 and foolish developer, wrote a unit test like this:

 class MyDumbTest(unittest.TestCase):
  def testSpamRepr(self):
  x = Spam(arg)
  self.assertEquals(repr(x), Spam object at 0x123ab)


 we shouldn't conclude that unit tests are bad, but that MyDumbTest is bad
 and needs to be fixed.

+1

[...]
 And that's great, it really is, I'm not being sarcastic. But unit testing is
 not in competition to doc testing, they are complimentary, not alternatives.
 If you're not using both, then you're probably missing out on something.


+1

PS: ... and well , this would be my last message about dutest and how
it improves upon what's offered by doctest module ...

Summarizing : «Bad doctests» is not a cool statement

.. [1] dutest @ PyPI
(https://pypi.python.org/pypi/dutest)

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What if we didn't have repr?

2013-05-20 Thread Mark Janssen

 I have pondered it many times, although usually in the form Why do we
 need both str and repr?

Here's an idea:  considering python objects are stateful.   Make a
general, state-query operator: ?.  Then the distinction is clear.

 ?This is a string  #Returns the contents of the string
This is a string

Then repr() is clearly the object as it is -- unstripped; i.e., not
just it's state (or contents, or whatever).
-- 
MarkJ
Tacoma, Washington
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

2013-05-20 Thread Serhiy Storchaka


20.05.13 16:12, Ethan Furman написав(ла):

As a quick reminder, PEP 409 allows this:

 try:
 ...
 except AnError:
 raise SomeOtherError from None

so that if the exception is not caught, we get the traditional single
exception traceback, instead of the new:

 During handling of the above exception, another exception occurred


My question:

How do we go about putting this in the stdlib?  Is this one of the
occasions where we don't do it unless we're modifying a module already
for some other reason?


Usually I use from None in a new code when it hides irrelevant 
details. But in case of b32decode() (changeset 1b5ef05d6ced) I didn't do 
it. It's my fault, I'll fix it in next commit.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

2013-05-20 Thread Terry Jan Reedy


On 5/20/2013 11:39 AM, Steven D'Aprano wrote:

On 21/05/13 00:12, Ethan Furman wrote:



As a case in point, base64.py is currently getting a bug fix, and also
contains this code:

def b32decode(s, casefold=False, map01=None):
 .
 .
 .
 for i in range(0, len(s), 8):
 quanta = s[i: i + 8]
 acc = 0
 try:
 for c in quanta:
 acc = (acc  5) + b32rev[c]
 except KeyError:
 raise binascii.Error('Non-base32 digit found')
 .
 .
 .
 else:
 raise binascii.Error('Incorrect padding')

Does the KeyError qualify as irrelevant noise?



IMO, it is irrelevant noise, and obviously so. The binascii.Error raised
is not a bug to be fixed, it is a deliberate exception and part of the
API of the binascii module. That it occurs inside an except KeyError
block is a mere implementation detail.


Yes, the code could be revised to make a check on c before the indexing.
This would be redundant (and a slowdown) in that the check is already 
done by the indexing mechanism. The whole point of the above is to 
*replace* the default KeyError with a custom binascii.Error for 
too-large chars.


And I agree with Georg, please say which bad digit was found.

Terry






___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What if we didn't have repr?


On 05/20/2013 11:14 AM, Mark Janssen wrote:

I have pondered it many times, although usually in the form Why do we
need both str and repr?


Here's an idea:  considering python objects are stateful.   Make a
general, state-query operator: ?.  Then the distinction is clear.

-- ?This is a string  #Returns the contents of the string
This is a string

Then repr() is clearly the object as it is -- unstripped; i.e., not
just it's state (or contents, or whatever).


You can have that now, just make your __repr__ do what you want.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib


On 05/20/2013 11:32 AM, Terry Jan Reedy wrote:

On 5/20/2013 11:39 AM, Steven D'Aprano wrote:

On 21/05/13 00:12, Ethan Furman wrote:



As a case in point, base64.py is currently getting a bug fix, and also
contains this code:

def b32decode(s, casefold=False, map01=None):
 .
 .
 .
 for i in range(0, len(s), 8):
 quanta = s[i: i + 8]
 acc = 0
 try:
 for c in quanta:
 acc = (acc  5) + b32rev[c]
 except KeyError:
 raise binascii.Error('Non-base32 digit found')
 .
 .
 .
 else:
 raise binascii.Error('Incorrect padding')

Does the KeyError qualify as irrelevant noise?



IMO, it is irrelevant noise, and obviously so. The binascii.Error raised
is not a bug to be fixed, it is a deliberate exception and part of the
API of the binascii module. That it occurs inside an except KeyError
block is a mere implementation detail.


Yes, the code could be revised to make a check on c before the indexing.
This would be redundant (and a slowdown) in that the check is already done by 
the indexing mechanism. The whole point of
the above is to *replace* the default KeyError with a custom binascii.Error for 
too-large chars.

And I agree with Georg, please say which bad digit was found.


Actually, that was Antoine, but I'm sure Georg also agrees.  ;)

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

2013-05-20 Thread Eric V. Smith



On May 20, 2013, at 11:46 AM, Antoine Pitrou solip...@pitrou.net wrote:

 On Mon, 20 May 2013 07:12:07 -0700
 Ethan Furman et...@stoneleaf.us wrote:
 
 As a case in point, base64.py is currently getting a bug fix, and also 
 contains this code:
 
 def b32decode(s, casefold=False, map01=None):
 .
 .
 .
 for i in range(0, len(s), 8):
 quanta = s[i: i + 8]
 acc = 0
 try:
 for c in quanta:
 acc = (acc  5) + b32rev[c]
 except KeyError:
 raise binascii.Error('Non-base32 digit found')
 .
 .
 .
 else:
 raise binascii.Error('Incorrect padding')
 
 Does the KeyError qualify as irrelevant noise?
 
 I think it is a legitimate case where to silence the original
 exception. However, the binascii.Error would be more informative if it
 said *which* non-base32 digit was encountered.
 

And, if possible, the location (index) in the string. 

Eric. 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 409 and the stdlib

2013-05-20 Thread Nick Coghlan

On 21 May 2013 05:01, Ethan Furman et...@stoneleaf.us wrote:

 On 05/20/2013 11:32 AM, Terry Jan Reedy wrote:

 On 5/20/2013 11:39 AM, Steven D'Aprano wrote:

 On 21/05/13 00:12, Ethan Furman wrote:


 As a case in point, base64.py is currently getting a bug fix, and also
 contains this code:

 def b32decode(s, casefold=False, map01=None):
  .
  .
  .
  for i in range(0, len(s), 8):
  quanta = s[i: i + 8]
  acc = 0
  try:
  for c in quanta:
  acc = (acc  5) + b32rev[c]
  except KeyError:
  raise binascii.Error('Non-base32 digit found')
  .
  .
  .
  else:
  raise binascii.Error('Incorrect padding')

 Does the KeyError qualify as irrelevant noise?



 IMO, it is irrelevant noise, and obviously so. The binascii.Error raised
 is not a bug to be fixed, it is a deliberate exception and part of the
 API of the binascii module. That it occurs inside an except KeyError
 block is a mere implementation detail.


 Yes, the code could be revised to make a check on c before the indexing.
 This would be redundant (and a slowdown) in that the check is already
done by the indexing mechanism. The whole point of
 the above is to *replace* the default KeyError with a custom
binascii.Error for too-large chars.

 And I agree with Georg, please say which bad digit was found.


 Actually, that was Antoine, but I'm sure Georg also agrees.  ;)

Indeed, a good question to ask when making use of PEP 409 is what debugging
info is being lost by suppressing the original exception, and then making
sure that info is captured and reported by the outer exception.

There's probably a new PEP 8 guideline in this thread - perhaps something
based on the above paragraph.

Cheers,
Nick.


 --
 ~Ethan~

 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

2013-05-20 Thread Michael Foord


On 20 May 2013, at 18:26, Mark Janssen dreamingforw...@gmail.com wrote:

 I'm hoping that core developers don't get caught-up in the doctests are bad
 meme.
 
 Instead, we should be clear about their primary purpose which is to test
 the examples given in docstrings.
 In other words, doctests have a perfectly legitimate use case.
 
 But more than just one ;-)  Another great use has nothing to do with
 docstrings:  using an entire file as a doctest.   This encourages
 writing lots of text explaining what you're doing,. with snippets of
 code interspersed to illustrate that the code really does behave in
 the ways you've claimed.
 
 +1, very true.  I think doctest excel in almost every way above
 UnitTests.  I don't understand the popularity of  UnitTests, except
 perhaps for GUI testing which doctest can't handle.  I think people
 just aren't very *imaginative* about how to create good doctests that
 are *also* good documentation.
 

Doc tests have lots of problems for unit testing.

* Every line is a test with *all* output part of the test - in unit tests you 
only assert the specific details you're interested in
* Unordered types are a pain with doctest unless you jump through hoops
* Tool support for editing within doctests is *generally* worse
* A failure on one line doesn't halt execution, so you can get many many 
reported errors from a single failure
* Try adding diagnostic prints and then running your doctests!
* Tools support in terms of test discovery and running individual tests is not 
as smooth
* Typing  and ... all the time is really annoying
* Doctests practically beg you to write your code first and then copy and paste 
terminal sessions - they're the enemy of TDD
* Failure messages are not over helpful and you lose the benefit of some of the 
new asserts (and their diagnostic output) in unittest
* Tests with non-linear code paths (branches) are more painful to express in 
doctests

and so on...

However doctests absolutely rock for testing documentation / docstring 
examples. So I'm with Raymond on this one.

All the best,

Michael

 That serves two very good purposes in one.  How can you beat that?
 The issues of teardown and setup are fixable and even more beautifully
 solved with doctests -- just use the lexical scoping of the program to
 determine the execution environment for the doctests.
 
 picking-your-poison-ly y'rs  - tim
 
 Cheers,
 
 Mark
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Ordering keyword dicts

2013-05-20 Thread Chris Angelico

On Mon, May 20, 2013 at 11:35 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
 Joao S. O. Bueno wrote:

 Actually, when I was thinking on the subject I came to the same idea, of
 having
 some functions marked differently so they would use a different call
 mechanism -
 but them I wondered around having a different opcode for the ordered-dict
 calls.

 Would that be feasible?


 No, because the callee is the only one that knows whether it
 requires its keyword args to be ordered.

 In fact, not even the callee might know at the time of the
 call. Consider a function that takes **kwds and passes them
 on to another function that requires ordered keywords.

I wouldn't be bothered by that case, as it's no different from any
other means of stuffing a dictionary through **kwds. If you want to
preserve order through a wrapper, the wrapper needs to be declared to
preserve order. The trouble is that there can't be any compile-time
lookup to determine what (type of) function will be called, ergo this
can't be resolved with a unique bytecode based on the destination.

How big a deal would it be to bless OrderedDict with a special literal
notation? Something like:

od = o{'a': 1, 'b': 2, 'c': 3}

Much of the need for ordered kwargs is for constructing OrderedDict
itself after all (cf Antoine).

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

I don't think a python-dev discussion about the value of doctests is going to
change minds one way or the other, but I just *had* to respond to this one
point:

On May 20, 2013, at 11:26 PM, Michael Foord wrote:

* Doctests practically beg you to write your code first and then copy and
* paste terminal sessions - they're the enemy of TDD

In a sense, they're your best friend too.

Countless times, when I'm designing an API, writing the documentation first
helps clarify how I want the library to work, or where I need to think about
the API more deeply.  In much the same way that TDD is ideal when you know
what you're aiming for, when you *don't* exactly know, it's a huge benefit to
write the documentation first.  Doing so will bring into stark contrast what
needs improvement in your API.

The fact that you can then test much of this documentation as you go, brings
the win of TDD to your documentation.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

2013-05-20 Thread Glenn Linderman


On 5/19/2013 9:08 PM, Ethan Furman wrote:

On 05/19/2013 05:24 PM, Nick Coghlan wrote:


This is the point I was trying to make: once you use IntEnum (as you
would in any case where you need bitwise operators), Enum gets out of
the way for everything other than __str__, __repr__, and one other
slot (that escapes me for the moment...).


__getnewargs__ and __new__

But if you do math, the result is no longer an Enum of any type.


And thus completely loses the debugging benefits of having a nice 
__repr__.  IntEnum isn't useful for bitfields.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

Hi !
... sorry , I could not avoid to reply this message ...

On 5/20/13, Michael Foord fuzzy...@voidspace.org.uk wrote:

 On 20 May 2013, at 18:26, Mark Janssen dreamingforw...@gmail.com wrote:

 I'm hoping that core developers don't get caught-up in the doctests are
 bad
 meme.

 Instead, we should be clear about their primary purpose which is to
 test
 the examples given in docstrings.
 In other words, doctests have a perfectly legitimate use case.

 But more than just one ;-)  Another great use has nothing to do with
 docstrings:  using an entire file as a doctest.   This encourages
 writing lots of text explaining what you're doing,. with snippets of
 code interspersed to illustrate that the code really does behave in
 the ways you've claimed.

 +1, very true.  I think doctest excel in almost every way above
 UnitTests.  I don't understand the popularity of  UnitTests, except
 perhaps for GUI testing which doctest can't handle.  I think people
 just aren't very *imaginative* about how to create good doctests that
 are *also* good documentation.



With enhanced doctests solution in mind ...

 Doc tests have lots of problems for unit testing.

 * Every line is a test with *all* output part of the test - in unit tests
 you only assert the specific details you're interested in

custom output checkers

 * Unordered types are a pain with doctest unless you jump through hoops

( custom output checkers + doctest runner ) | (dutest __tc__ global var)

 * Tool support for editing within doctests is *generally* worse

this is true , let's do it !

 * A failure on one line doesn't halt execution, so you can get many many
 reported errors from a single failure

it should if REPORT_ONLY_FIRST_FAILURE option [1]_ is set .

 * Try adding diagnostic prints and then running your doctests!

I have ... dutest suites for my Trac plugins do so . However logging
information is outputted to /path/to/trac/env/log/trac.log ... so a
tail -f is always handy .

 * Tools support in terms of test discovery and running individual tests is
 not as smooth

dutest offers two options since years ago MultiTestLoader combines
multiple test loaders to *load* different kinds of tests at once from
a module , whereas a package loader performs test discovery . These
loader objects are composable , so if an instance of MultiTestLoader
is supplied in to the package test loader then multiple types of tests
are loaded out of modules all over across the package hierarchy .

Indeed , in +10 years of Python development I've never used
unittest(2) discovery, and even recently implemented the one that's
used in Apache™ Bloodhound test suite . Unfortunately I've had no much
time to spend on improving all this support in dutest et al.

 * Typing  and ... all the time is really annoying

... I have faith ... there should be something like this for vim ... I
have faith ... ;)

 * Doctests practically beg you to write your code first and then copy and
 paste terminal sessions - they're the enemy of TDD

Of course , not , all the opposite . If the approach is understood
correctly then the first thing test author will do is to write the
code «expected» to get something done . When everything is ok with API
code style then write the code . Many problems in the API and
inconsistencies are thus detected early .

 * Failure messages are not over helpful and you lose the benefit of some of
 the new asserts (and their diagnostic output) in unittest

(custom ouput checkers) | ( dutest __tc__ variable )

 * Tests with non-linear code paths (branches) are more painful to express in
 doctests


that's a fact , not just branches , but also exceptions

Beyond this ...

My really short answer is that I do not agree with this . Like I just
said in previous messages with enhanced support like the one offered
by dutest (i.e. __tc__ global var bound to an instance of
unittest.TestCase) it's possible to invoke each and every unittest
assertion method . So this may be seen all the other way round
«unittest machinery is already used without even declaring a single
test class» ... and so on ...

... so , in concept , there is no real benefit in using unittest over
doctest *if* doctest module is eventually upgraded .

[...]

 However doctests absolutely rock for testing documentation / docstring
 examples.


FWIW , +1

[...]

.. [1] doctest.REPORT_ONLY_FIRST_FAILURE

(http://docs.python.org/2/library/doctest.html#doctest.REPORT_ONLY_FIRST_FAILURE)

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]