On Thursday, October 24, 2013 12:46:51 AM UTC-5, Metallicow wrote:
> +1 for stdev Steven. Thanks for the extra legs.
> Hope all goes well with introductions... I'm sure it will.
> :) Good Job.
Well, what I am trying to get at is whether it is better as...
stddev or stdev...? 6(3standard abc) vs 5
On Oct 24, 2013 9:38 PM, "Terry Reedy" 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
modu
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
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
re
On 10/24/13 7:46 AM, Steven D'Aprano wrote:
On Thu, 24 Oct 2013 06:36:04 -0400, Ned Batchelder wrote:
coverage.py currently runs on 2.3 through 3.4
You support all the way back to 2.3???
I don't know whether to admire your dedication, or back away slowly since
you're obviously a crazy person
On Thursday, October 24, 2013 5:16:58 PM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 24 Oct 2013 06:36:04 -0400, Ned Batchelder wrote:
>
> > coverage.py currently runs on 2.3 through 3.4
>
> You support all the way back to 2.3???
>
> I don't know whether to admire your dedication, or back away sl
On Thu, 24 Oct 2013 06:36:04 -0400, Ned Batchelder wrote:
> coverage.py currently runs on 2.3 through 3.4
You support all the way back to 2.3???
I don't know whether to admire your dedication, or back away slowly since
you're obviously a crazy person :-)
--
Steven
--
https://mail.python.or
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 lea
On 10/24/13 2:59 AM, Ben Finney wrote:
Steven D'Aprano writes:
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.
Ned Batchelder has managed something at least as ambitious (supporting
Python ve
Steven D'Aprano writes:
> 1) statistics.py in the standard library, which is written for
>Python 3.3/3.4 only, and should be as clean as possible;
>
> 2) a backport of it, on PyPI, which will support older Pythons, and
>may be slower/uglier if need be.
>
> My problem is not supporting 2.
On Thu, 24 Oct 2013 17:59:59 +1100, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> 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.
>
> Ned Batchelder has managed something at least as a
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 interse
Op 24-10-13 06:54, Steven D'Aprano schreef:
> 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
Steven D'Aprano writes:
> 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.
Ned Batchelder has managed something at least as ambitious (supporting
Python versions 2.4 through 3.3), which shoul
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
On Thursday, October 24, 2013 12:09:55 AM UTC-5, Ben Finney wrote:
> A useful library for this purpose is ‘six’ (as in “3 × 2”)
> http://pythonhosted.org/six/>. You can use its features to do
> things that are useful or better in Python 3, but which need special
> implementation to work on Python 2
Steven D'Aprano writes:
> As some of you are aware, I have a module accepted into the standard
> library:
> http://docs.python.org/3.4/library/statistics.html
Wow, neat, I had seen something about the module and thought it looked
great, but I didn't realize you were the author. Awesome!
> Any
Steven D'Aprano writes:
> 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
18 matches
Mail list logo
