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

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

Maintaining a backported module

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

Contents

  Maintaining a backported module Steven D'Aprano <steve@pearwood.info> - 2013-10-24 04:54 +0000
    Re: Maintaining a backported module Ben Finney <ben+python@benfinney.id.au> - 2013-10-24 16:09 +1100
      Re: Maintaining a backported module Metallicow <metaliobovinus@gmail.com> - 2013-10-23 22:46 -0700
        Re: Maintaining a backported module Metallicow <metaliobovinus@gmail.com> - 2013-10-30 03:32 -0700
    Re: Maintaining a backported module Paul Rubin <no.email@nospam.invalid> - 2013-10-23 22:38 -0700
    Re: Maintaining a backported module Ethan Furman <ethan@stoneleaf.us> - 2013-10-23 23:30 -0700
    Re: Maintaining a backported module Ben Finney <ben+python@benfinney.id.au> - 2013-10-24 17:59 +1100
      Re: Maintaining a backported module Steven D'Aprano <steve@pearwood.info> - 2013-10-24 09:38 +0000
        Re: Maintaining a backported module Ben Finney <ben+python@benfinney.id.au> - 2013-10-24 21:01 +1100
    Re: Maintaining a backported module Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-24 09:00 +0200
    Re: Maintaining a backported module Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-24 09:37 +0100
    Re: Maintaining a backported module Ned Batchelder <ned@nedbatchelder.com> - 2013-10-24 06:36 -0400
      Re: Maintaining a backported module Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-24 11:46 +0000
        Re: Maintaining a backported module rusi <rustompmody@gmail.com> - 2013-10-24 05:25 -0700
        Re: Maintaining a backported module Ned Batchelder <ned@nedbatchelder.com> - 2013-10-24 13:46 -0400
        Re: Maintaining a backported module Terry Reedy <tjreedy@udel.edu> - 2013-10-24 16:37 -0400
        Python Coverage: testing a program (was: Maintaining a backported module) Ben Finney <ben+python@benfinney.id.au> - 2013-10-25 07:54 +1100
        Re: Python Coverage: testing a program Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-24 22:55 +0100
        Re: Python Coverage: testing a program Terry Reedy <tjreedy@udel.edu> - 2013-10-24 18:36 -0400
        Re: Python Coverage: testing a program Ethan Furman <ethan@stoneleaf.us> - 2013-10-24 15:28 -0700
        Re: Python Coverage: testing a program Ben Finney <ben+python@benfinney.id.au> - 2013-10-25 10:27 +1100
        Re: Python Coverage: testing a program Ben Finney <ben+python@benfinney.id.au> - 2013-10-25 10:30 +1100
        Re: Python Coverage: testing a program Ned Batchelder <ned@nedbatchelder.com> - 2013-10-24 19:53 -0400
        Re: Python Coverage: testing a program Terry Reedy <tjreedy@udel.edu> - 2013-10-24 19:55 -0400
        Re: Maintaining a backported module Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-25 08:49 +0100
    Re: Maintaining a backported module Christian Heimes <christian@python.org> - 2013-10-24 12:47 +0200
    Re: Maintaining a backported module Ethan Furman <ethan@stoneleaf.us> - 2013-10-24 12:42 -0700

Page 2 of 2 — ← Prev page 1 [2]

#57479 — Re: Python Coverage: testing a program

Terry Reedy <tjreedy@udel.edu> writes:

> OK, I added .coveragerc and that works. In the process of verifying
> this, I was reminded that there is an overt bug in the html report
[…]

At this point, it's probably best to direct this sequence of bug reports
to <URL:https://bitbucket.org/ned/coveragepy/issues/>.

-- 
 \        “I don't accept the currently fashionable assertion that any |
  `\       view is automatically as worthy of respect as any equal and |
_o__)                                   opposite view.” —Douglas Adams |
Ben Finney

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

#57480 — Re: Python Coverage: testing a program

Ethan Furman <ethan@stoneleaf.us> writes:

> On 10/24/2013 01:54 PM, Ben Finney wrote:
> > You can do this already with current Coverage: tell Coverage to
> > exclude <URL:http://nedbatchelder.com/code/coverage/excluding.html>
> > specific statements, and it won't count them for coverage
> > calculations.
>
> While that's neat (being able to exclude items) is there any reason to
> ever count the `if __name__ == '__main__'` clause?

I'd rather Coverage not go down the track of accumulating special cases
based on how they're written. A simple pragma fixes the problem, no
matter what the exact statement looks like.

-- 
 \           “Prediction is very difficult, especially of the future.” |
  `\                                                       —Niels Bohr |
_o__)                                                                  |
Ben Finney

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

#57481 — Re: Python Coverage: testing a program

On 10/24/13 6:28 PM, Ethan Furman wrote:
> On 10/24/2013 01:54 PM, Ben Finney wrote:
>> Terry Reedy <tjreedy@udel.edu> writes:
>>
>>> On 10/24/2013 1:46 PM, Ned Batchelder wrote:
>>>> It's been fun dropping the contortions for coverage.py 4.x, though!
>>>
>>> One request: ignore "if __name__ == '__main__':" clauses at the end of
>>> files, which cannot be run under coverage.py, so 100% coverage is
>>> reported as 100% instead of 9x%.
>>
>> You can do this already with current Coverage: tell Coverage to exclude
>> <URL:http://nedbatchelder.com/code/coverage/excluding.html> specific
>> statements, and it won't count them for coverage calculations.
>
> While that's neat (being able to exclude items) is there any reason to 
> ever count the `if __name__ == '__main__'` clause?  Are there any 
> circumstances where it could run under Coverage? (Apologies if this is 
> a dumb question, I know nothing about Coverage myself -- but I'm going 
> to go look it up now.  ;)
>

Sure, if that line appears in program.py, then it will be run if you 
execute program.py:  $ coverage run program.py

You can run coverage a number of times, even with different main 
programs, then combine all the data to produce a combined report. This 
way you could cover all of the __main__ clauses in a number of files.

--Ned.

> -- 
> ~Ethan~
>
>

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

#57482 — Re: Python Coverage: testing a program

On 10/24/2013 6:36 PM, Terry Reedy wrote:

> OK, I added .coveragerc and that works. In the process of verifying
> this, I was reminded that there is an overt bug in the html report as
> displayed by Firefox. The fonts used for line numbers
> ("class='linenos'") and line text ("class='text'") are slightly
> different and, more importantly, with difference sizes (line numbers are
> larger). So corresponding numbers and text do not line up with each
> other. This makes the J,K hotkeys and missing branch notations much less
> useful than intended. If I use cntl-scrollwheel to change text size,
> both change in the same proportion, so the mismatch is maintained.

I found the style.css file and the linenos entry that works to make 
numbers and text line us is, *after correction*:

/* Source file styles */
.linenos p {
     text-align: right;
     margin: 0;
     padding: 0 .5em 0 .5em;
     color: #999999;
     font-family: verdana, sans-serif;
     font-size: .625em;   /* 10/16 */
     /* line-height: 1.6em;  /* 16/10 */
     }

Padding was '0 .5em', which I gather is the same as '0 .5em .5em .5em', 
which adds padding to both top and bottom, instead of just one of the 
two. The corresponding text padding is '0 0 0 .5em'. The extra .5 for 
numbers puts padding needed on the right to separate numbers from the 
vertical green bars. The commented-out line-height added to mis-alignment.

The verdana numerals *are* larger than those for the inherited page 
default (font: 'inherit' at the top of the file). But they do not cause 
misalignment.

-- 
Terry Jan Reedy

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

#57502

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

On Oct 24, 2013 9:38 PM, "Terry Reedy" <tjreedy@udel.edu> wrote:
>
> On 10/24/2013 1:46 PM, Ned Batchelder wrote:
>>>
>>> On Thu, 24 Oct 2013 06:36:04 -0400, Ned Batchelder wrote:
>>>>
>>>> coverage.py currently runs on 2.3 through 3.4
>
>
> I want to thank you for this package. I have used it when writing test
modules for idlelib modules and aiming for 100% coverage forces me to
really understand the code tested to hit all the conditional lines.
>
>
>> It's been fun dropping the contortions for coverage.py 4.x, though!
>
>
> One request: ignore "if __name__ == '__main__':" clauses at the end of
files, which cannot be run under coverage.py, so 100% coverage is reported
as 100% instead of 9x%.

Coverage already does this. You have to put it in your coveragerc.
Personally I arrange to ensure that I am testing that part though. You can
enable coverage for these with the pth file and the environment variable
whose name temporarily escapes me. Or you can just invoke coverage directly
on the script.

Oscar

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

#57446

Am 24.10.2013 06:54, schrieb Steven D'Aprano:
> As some of you are aware, I have a module accepted into the standard 
> library:
> 
> http://docs.python.org/3.4/library/statistics.html
> 
> I'm now at the point where I wish to backport this module to support 
> versions of Python back to 3.1 at least and possibly 2.7, and put it up 
> on PyPI.
> 
> I'm looking for advice on best practices for doing so. Any suggestions 
> for managing bug fixes and enhancements to two separate code-bases 
> without them diverging too much?

Hi Steven,

your module doesn't process text and doesn't use any fancy 3.x features
except raise from None. It should be just a matter of an hour or two to
port and package your code.

1) Add

    from __future__ import divisision

    import sys as _sys
    if _sys.version_info[0] == 2:
        range = xrange

to the top of your files to use 3.x integer division and generator range


2) Remove

  from None

in the exception handling code


3) Perhaps for 2.7 use iteritems in _sum()

  sorted(partials.items())


For testing under 2.6 you can use the unittest2 package. It offers all
the nice new features like assertIsInstance() and assertIn(). I highly
recommand tox + py.test for testing. You can test your package with all
versions of Python with just one command.

We already have a namespace for backports that you can use: backports.
:) Feel free to contact me via mail in #python-dev if you have any
questions.

Christian

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

#57469

On 10/24/2013 01:37 AM, Mark Lawrence wrote:
> On 24/10/2013 07:30, Ethan Furman wrote:
>> On 10/23/2013 09:54 PM, Steven D'Aprano wrote:
>>>
>>> I'm looking for advice on best practices for doing so. Any suggestions
>>> for managing bug fixes and enhancements to two separate code-bases
>>> without them diverging too much?
>>
>> Confining your code to the intersection of 2.7 and 3.x is probably going
>> to be the easiest thing to do as 2.7 has a bunch of 3.x features.
>>
>> Sadly, when I backported Enum I was targeting 2.5 - 3.x because I have
>> systems still running 2.5.  That was *not* a fun experience.  :(
>>
>> --
>> ~Ethan~
>
> Have you or could you publish anything regarding your experiences, I
> suspect it would be an enlightening read for a lot of us?

The only thing I can add to what's already been posted in this thread 
(and it was advice I got from Barry -- Thanks, Barry! :) is when your 
class structure cannot be written the same in both 2 and 3 (because, for 
example, you are using metaclasses) then you have to define your 
methods outside of a class, store them in a dictionary, and then use 
type to create the class.  You can look at Enum for an example (his or 
mine ;).

--
~Ethan~

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web