gmane.comp.python.devel

Re: PEP 409 and the stdlib

Nick Coghlan — 2013-05-20T21:37:38

done by the indexing mechanism. The whole point of
binascii.Error for too-large chars.

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.

http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

Re: PEP 409 and the stdlib

Eric V. Smith — 2013-05-20T19:31:48


On May 20, 2013, at 11:46 AM, Antoine Pitrou <solipsis< at >pitrou.net> wrote:


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

Eric.

Re: PEP 409 and the stdlib

Ethan Furman — 2013-05-20T18:58:24

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

--
~Ethan~

Re: What if we didn't have repr?

Ethan Furman — 2013-05-20T18:23:10

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

--
~Ethan~

Re: PEP 409 and the stdlib

Terry Jan Reedy — 2013-05-20T18:32:53

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

Re: PEP 409 and the stdlib

Serhiy Storchaka — 2013-05-20T18:31:44

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

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< at >python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: What if we didn't have repr?

Mark Janssen — 2013-05-20T18:14:49

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

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).

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

Olemis Lang — 2013-05-20T17:52:01

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


+1


Yes


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 mig

Re: PEP 409 and the stdlib

Georg Brandl — 2013-05-20T17:38:28

Am 20.05.2013 17:39, schrieb Steven D'Aprano:

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

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

Mark Janssen — 2013-05-20T17:26:51

+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.


Cheers,

Mark

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

Olemis Lang — 2013-05-20T16:37:53

---------- Forwarded message ----------
From: Olemis Lang <olemis< at >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 <solipsis< at >pitrou.net>

On 5/20/13, Antoine Pitrou <solipsis< at >pitrou.net> wrote:

+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)

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

Olemis Lang — 2013-05-20T16:27:33

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 <greg< at >krypto.org> wrote:

«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, ...)


This is something that could be easily mitigated by a cu

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

Antoine Pitrou — 2013-05-20T16:10:48

On Tue, 21 May 2013 02:00:32 +1000
Steven D'Aprano <steve< at >pearwood.info> wrote:


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.

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

Steven D'Aprano — 2013-05-20T16:00:32


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< at >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" %

Re: PEP 409 and the stdlib

Antoine Pitrou — 2013-05-20T15:46:38

On Mon, 20 May 2013 07:12:07 -0700
Ethan Furman <ethan< at >stoneleaf.us> wrote:

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.

Re: PEP 409 and the stdlib

Steven D'Aprano — 2013-05-20T15:39:03




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.

Re: PEP 409 and the stdlib

Ethan Furman — 2013-05-20T15:15:08

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~

Re: Ordering keyword dicts

Guido van Rossum — 2013-05-20T15:35:07

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, "fwierzbicki< at >gmail.com" <fwierzbicki< at >gmail.com>
wrote:

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

Barry Warsaw — 2013-05-20T15:30:37


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

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

Barry Warsaw — 2013-05-20T15:27:09


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>.


+1

A rule-of-thumb

Re: Ordering keyword dicts

2013-05-20T15:21:09

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