Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
On Sat, 18 May 2013 23:41:59 -0700 Raymond Hettinger 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]
-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 > 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 Design"http://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
Hi all, On Sun, May 19, 2013 at 4:59 PM, Maciej Fijalkowski 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?
20.05.13 01:33, Benjamin Peterson написав(ла): 2013/5/19 Demian Brecht : 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?
On 20.05.13 14:37, Serhiy Storchaka wrote: 20.05.13 01:33, Benjamin Peterson написав(ла): 2013/5/19 Demian Brecht : 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]
On 20/05/13 20:45, Antoine Pitrou wrote:
On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger 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 wrote: > On 20/05/13 20:45, Antoine Pitrou wrote: > > On Sat, 18 May 2013 23:41:59 -0700 > > Raymond Hettinger 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 wrote: > On Sat, 18 May 2013 23:41:59 -0700 > Raymond Hettinger 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 wrote: > On 20.05.13 14:37, Serhiy Storchaka wrote: > > 20.05.13 01:33, Benjamin Peterson напиÑав(ла): > >> 2013/5/19 Demian Brecht : > >>> 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
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. 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 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" wrote:
> On Mon, 20 May 2013 12:45:57 +0200, Antoine Pitrou
> wrote:
> > On Sat, 18 May 2013 23:41:59 -0700
> > Raymond Hettinger 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 wrote:
> On Mon, 20 May 2013 09:37:32 -0400
> "R. David Murray" wrote:
> > On Mon, 20 May 2013 12:45:57 +0200, Antoine Pitrou
> > wrote:
> > > On Sat, 18 May 2013 23:41:59 -0700
> > > Raymond Hettinger 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 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
On Mon, May 20, 2013 at 6:39 AM, Barry Warsaw 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 . >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
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" wrote: > On Mon, May 20, 2013 at 6:39 AM, Barry Warsaw 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
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 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]
On 20/05/13 23:38, Antoine Pitrou wrote:
On Mon, 20 May 2013 23:32:10 +1000
Steven D'Aprano wrote:
On 20/05/13 20:45, Antoine Pitrou wrote:
On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger 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 wrote: > On 20/05/13 23:38, Antoine Pitrou wrote: > > On Mon, 20 May 2013 23:32:10 +1000 > > Steven D'Aprano wrote: > >> On 20/05/13 20:45, Antoine Pitrou wrote: > >>> On Sat, 18 May 2013 23:41:59 -0700 > >>> Raymond Hettinger 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 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 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 '' or '' (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. Encaps
Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
-- Forwarded message -- From: Olemis Lang Date: Mon, 20 May 2013 11:33:42 -0500 Subject: Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum] To: Antoine Pitrou On 5/20/13, Antoine Pitrou wrote: > On Sat, 18 May 2013 23:41:59 -0700 > Raymond Hettinger 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]
>> 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
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 ().
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 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 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), "") > > > 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
Re: [Python-Dev] What if we didn't have repr?
> 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
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
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
On May 20, 2013, at 11:46 AM, Antoine Pitrou 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 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
On 21 May 2013 05:01, "Ethan Furman" 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]
On 20 May 2013, at 18:26, Mark Janssen 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
On Mon, May 20, 2013 at 11:35 AM, Greg Ewing
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]
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 wrote: > > On 20 May 2013, at 18:26, Mark Janssen 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]
On 5/20/13, Olemis Lang wrote: [...] > On 5/20/13, Michael Foord wrote: [...] > >> * Tool support for editing within doctests is *generally* worse > > this is true , let's do it ! > [...] >> * Typing >>> and ... all the time is really annoying > > ... I have faith ... there should be something like this for vim ... I > have faith ... ;) > FWIW ... an option could be to combine >>> auto-completion (in the end that's yet another indentation ;) to this http://architects.dzone.com/articles/real-time-doctest-checking-vim ... and I could better enjoy my vim + python development experience ;) -- 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]
>> * 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 . Now all we need is a test() built-in, a companion to help() and we have the primo platform for doctest-code-test cycle for TDD and agile development. --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 435 - ref impl disc 2
On 5/14/2013 7:16 AM, Ethan Furman wrote: Thank you for being persistent. You are correct, the value should be an IntET (at least, with a custom __new__ ;). You know, when you look at something you wrote the night before, and have no idea what you were trying to say, you know you were tired. Ignore my parenthetical remark. Gladly. And we now have several more days to have forgotten what we were doing/talking about... Okay, the value is now an IntET, as expected and appropriate. Maybe. I upgraded my ref435.py from yours at https://bitbucket.org/stoneleaf/ref435 (and your test file there references enum.py which is not there). My demo1.py still doesn't work. The first 4 lines are fine, but not the last two. I still cannot do a lookup (via __call__ syntax) by either int or IntET value. You have my old misnamed NEI class in your test file now, and the tests you use with it work... but you don't have a lookup test. My demo1 does, and that fails. After instrumenting Enum.__new__ it seems that the member.value is still the constructor parameters... Maybe I picked up the wrong version of your code? Oh and demo1.py has leftover __new__ and __init__ definitions for NIE, modeled after your earlier suggestions. Leaving them in causes everything to be named 'temp'. Taking them out makes things not work differently. ___ 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
