Mailman 3 June 2004 - Python-Dev

Re: [Python-Dev] doctest improvements
by "Martin v. Löwis" 01 Jun '04

01 Jun '04

Edward Loper wrote: > I thought that it would be more efficient to get feedback on whether the > patch is a good idea before writing the docs & tests. But I guess that > that's now how things are done w/ Python development. I'll go ahead and > add test cases & docs, and update the patches. It's more efficient for the patch submitter, but less efficient for the reviewer, because the reviewer needs to spend more time understanding the patch in detail. Therefore, patches that are formally complete get better attention; patches where the author couldn't find the time to write documentation might never get reviewed. Regards, Martin

1 0

Re: [Python-Dev] doctest improvements
by "Martin v. Löwis" 01 Jun '04

01 Jun '04

Dave Harrison wrote: > I'm interested in getting involved in python dev, how do you go about > reviewing patches etc ? Pick a patch that interests you, and that hasn't seen any comments (if you run out of those, consider patches that have comments and appear to have fizzled out). For these patches: - check whether they are formally complete, i.e. whether they include test cases and documentation. - check whether they actually work. Apply them, and run the test suite. At some point, run the entire Python test suite, to see whether they break anything else. - if they are bug fixes, check whether they actually fix the bug they claim to fix (if they claim to fix bugs but don't actually state which bug they fix, make the submitter explain the problem first) - if they add new features, determine: a) whether the feature could have negative effects on existing code, and b) whether the feature is desirable in your POV - review the actual code: a) check whether it follows the style guide b) if it is C code, check for common mistakes, e.g. refcounting bugs c) check whether tricky aspects are properly commented d) check whether there are any border cases that would need consideration When you have done your analysis, put your report as a comment into the patch. This could be one of three outcomes: a) the patch is acceptable b) the patch should be rejected c) the patch is acceptable in principle, and needs more work, or is just incomplete (so it needs more work but hasn't been fully reviewed) For cases a) and b), if you have a list of five or so patches, post them to python-dev, asking for somebody to commit the a)-cases, and close the b)-cases as rejected. For case c), see whether the author is willing to follow up. If not, ping the author again after two months or so. If the author is still not responsive, consider completing the patch for yourself. If you find that the patch is not important enough, consider rejection (I often do that, assuming that somebody will do the work eventually if the feature is really desired). > I'm sure this question has been asked a million times before, but is > there a list of things that need to be done ? It's not that often asked as I'd like to, so I'm happy to answer it every time it comes up. However, people have also added text to the web pages summarizing these principles, at http://www.python.org/dev/dev_intro.html in the section "Helping out". Regards, Martin

1 0

rounding problem
by Norlin Abd Rahim 01 Jun '04

01 Jun '04

Hi, I'm using python with zope. I used _.round and it seems like it is look unstable. For example if i have one number, 1130.975 and rounded it to 2 decimal places, it will be 1130.97 and not 1130.98. But for certain numbers it will rounded correctly if the last digit is 5. I even used fixedpoint.py but still i've got the same problem. This applies only to numbers that have digit 5 after the decimal places that needs to be rounded. Any idea why? TIA

4 5

Re: [Python-Dev] doctest improvements
by Edward Loper 01 Jun '04

01 Jun '04

Tim Peters wrote: > [...] Making a doctest > reader learn a special "doctest markup language" is A Problem in this case. > Offhand, I'd be happier with an almost-self-evident (say) > > <blank line> Perhaps you'd be happier with a different value of BLANKLINE_MARKER, then? E.g. "blank>": def test(): r""" A different marker: >>> print 'a\n\nb' a blank> b """ Although this means that you have to indent the doctest quite far. Perhaps it would be better if I changed the patch so the marker doesn't need to dedented all the way? E.g.: def test(): r""" A different marker: >>> print 'a\n\nb' a <blank line> b """ Another option to consider might be: def test(): r""" A different marker: >>> print 'a\n\nb' | a | | b """ I.e., the user can optionally preceed each line with a "|" (or some other marker), dedented past the prompt, to mark the extent of the output. I don't think this looks as wysiwyg, though. -Edward

2 1

RE: [Python-Dev] rounding problem
by Tony Meyer 01 Jun '04

01 Jun '04

[I think this would be better in python-list, not python-dev] > the number actually comes from multiplication between > 237.50 and 4.762 which will get 1130.975. So it suppose > to be 1130.98 isnt it if it'll get rounded to 2 decimal > places. Gary is correct: >>> 237.50 * 4.762 1130.9749999999999 >>> round(_,2) 1130.97 >>> print 237.50 * 4.762 1130.975 The answer correctly rounds to 1130.97 because the next digit is 4, not 5. When you print it, it rounds to 3 decimal places, so you get the .9749 rounding to .975. This is just floating point arithmetic. You might want to try the Decimal module, or something like that, to avoid this. =Tony Meyer

1 0

Uninformative error message about subclassing
by Edward C. Jones 01 Jun '04

01 Jun '04

Here are two small python files: ---- a.py: class A(object): pass ---- b.py: import a class B(a): pass ---- If I run "python b.py" I get the uninformative error message: Traceback (most recent call last): File "./b.py", line 5, in ? class B(a): TypeError: function takes at most 2 arguments (3 given) I think the message should say that "a" is not a class.

3 3

doctest improvements
by Edward Loper 01 Jun '04

01 Jun '04

About a month and a half ago, I filed several patches for doctest, and they haven't gotten any comments; so I was wondering if anyone could look at them. The most interesting is #933238, which addresses the often-noted problem that doctest can't handle blank lines. It adds a special blank-line marker (currently "-"), which must be *dedented* with respect to the doctest block. Here's an example use (the "x"s are to prevent mail readers from interpreting ">>>" as a quotation). x def test_blankline_marker(): x r""" x Use a dedented "-" to signify a blank line: x x >>> print 'First line\n\nThis is after a blank line\n' x First line x - x This is after a blank line x - x """ (Note that both internal and trailing blank lines can be handled.) This change is backwards compatible, since currently any line in a doctest block that's dedented past the prompt (">>>") is an error. If anyone has time to take a look at this, let me know what you think. Thanks. -Edward My doctest patches: [ 933238 ] doctest: add a special (dedented) marker for blank lines http://sourceforge.net/tracker/?func=detail&aid=933238&group_id=5470&atid=3… [ 932930 ] doctest: suggest the use of rawstrings for backslashes http://sourceforge.net/tracker/?func=detail&aid=932930&group_id=5470&atid=3… [ 932935 ] doctest: allow custom matchers for testing if got==want http://sourceforge.net/tracker/?func=detail&aid=932935&group_id=5470&atid=3… [ 932932 ] doctest: Add Tester params to DocTestSuite http://sourceforge.net/tracker/?func=detail&aid=932932&group_id=5470&atid=3…

3 2