Guido van Rossum wrote:
Or, maybe what I'm trying to say is, if the
user has start/end/count but the API wants start/step/count, after
computing step = (end-start) / count, the value of start + count*step
might not quite equal to end; whereas if the user has start/step/count
but the API wants
GDB Debugging Hooks It's not done yet.
I can do these if need be, but IIRC you (Victor) said on #python-dev
that you were already working on them.
I already changed it for an earlier version of the PEP. It still needs
to sort out the various compact representations. I could do them as
well, so
Le mardi 27 septembre 2011 00:19:02, Victor Stinner a écrit :
On Windows, there is just one failure in test_configparser, I
didn't investigate it yet
Oh, it was a real bug in io.IncrementalNewlineDecoder. It is now fixed.
Victor
___
Python-Dev
On Mon, Sep 26, 2011 at 9:25 PM, Steven D'Aprano st...@pearwood.info wrote:
..
The audience for numpy is a small minority of Python users, and they tend to
be more sophisticated. I'm sure they can cope with two functions with
different APIs wink
While continuity of API might be a good thing,
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
..
And I don't like linspace either. Something more self
explanatory such as subdivide or interpolate might
be better.
Grid would be nice and short, but may suggest 2-dimentional result.
Whatever word we choose, I
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
..
And I don't like linspace either. Something more self
explanatory such as subdivide or interpolate might
be better.
Grid would be nice and short, but may suggest 2-dimentional result.
On Sep 27, 2011, at 11:24 AM, Ethan Furman wrote:
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
..
And I don't like linspace either. Something more self
explanatory such as subdivide or interpolate might
be better.
Grid would
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
..
And I don't like linspace either. Something more self
explanatory such as subdivide or interpolate might
be better.
Grid would be nice and short, but may suggest 2-dimentional result.
Raymond Hettinger wrote:
On Sep 27, 2011, at 11:24 AM, Ethan Furman wrote:
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
..
And I don't like linspace either. Something more self
explanatory such as subdivide or interpolate might
be
On Tue, Sep 27, 2011 at 11:44 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
In the math module, we used an f prefix to differentiate math.fsum() from the
built-in sum() function. That suggests frange() as a possible name for a
variant of range() that creates floats.
That
Alexander Belopolsky wrote:
In addition to Steven's criticisms of numpy.linspace(), I would like a
new function to work with types other than float. It certainly makes
sense to have range-like functionality for fractions and decimal
floats, but also I often find a need to generate a list of
Steven D'Aprano wrote:
Alexander Belopolsky wrote:
In addition to Steven's criticisms of numpy.linspace(), I would like a
new function to work with types other than float. It certainly makes
sense to have range-like functionality for fractions and decimal
floats, but also I often find a need
On Tue, Sep 27, 2011 at 12:20 PM, Steven D'Aprano st...@pearwood.info wrote:
If it happened
to support dates, that would be great, but I think that a daterange()
function in the datetime module would be more appropriate.
Or even more appropriately in the calendar module. The problem is
that
On Tue, Sep 27, 2011 at 9:16 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Sep 27, 2011 at 11:44 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
In the math module, we used an f prefix to differentiate math.fsum() from
the built-in sum() function. That
I as well think the construct should support other types as it sounds an
awful lot like the missing for(;;) loop construct.
Concerning the api, if we use spread(start, step, count) we don't rely on a
division method even though the caller probably does. Just mentioning
another option.
--Yuval
On Tue, Sep 27, 2011 at 1:03 PM, Guido van Rossum gu...@python.org wrote:
..
Um, I think you better read the thread. :-) I successfully argued that
mimicking the behavior of range() for floats is a bad idea, and that
we need to come up with a name for an API that takes start/stop/count
On Tue, Sep 27, 2011 at 10:11 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Sep 27, 2011 at 1:03 PM, Guido van Rossum gu...@python.org wrote:
..
Um, I think you better read the thread. :-) I successfully argued that
mimicking the behavior of range() for floats is a bad
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 10:11 AM, Alexander Belopolsky wrote:
The name frange does not necessarily imply that we have to mimic the
API completely. As long as frange(10.0) and frange(1.0, 10.0) works
as expected while addressing floating point subtleties through
optional
Ethan Furman wrote:
What about the idea of this signature?
frange([start], stop, step=None, count=None)
Then when count is desired, it can be specified, and when step is
sufficient, no change is necessary.
A default of start=0 makes sense for integer range, because the most
common use for
Steven D'Aprano wrote:
Ethan Furman wrote:
What about the idea of this signature?
frange([start], stop, step=None, count=None)
Then when count is desired, it can be specified, and when step is
sufficient, no change is necessary.
A default of start=0 makes sense for integer range, because
On Tue, Sep 27, 2011 at 11:20 AM, Ethan Furman et...@stoneleaf.us wrote:
I personally would use the step value far more often than the count
value.
But that's exactly what we don't *want* you to do! Because (unless you
are a numerical wizard) you probably aren't doing the error analysis
needed
On Tue, Sep 27, 2011 at 2:20 PM, Ethan Furman et...@stoneleaf.us wrote:
..
Good points. So how about:
some_name_here(start, stop, *, step=None, count=None)
+1
The unusual optional first arguments is one of the things I dislike
about range(). Shouldn't step default to 1.0? Also, when count
On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum gu...@python.org wrote:
..
But that's exactly what we don't *want* you to do! Because (unless you
are a numerical wizard) you probably aren't doing the error analysis
needed to avoid the unexpected extra point problem due to floating
point
On Tue, Sep 27, 2011 at 11:48 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum gu...@python.org wrote:
..
But that's exactly what we don't *want* you to do! Because (unless you
are a numerical wizard) you probably aren't doing the
Hi folks
I wasn't sure if this warranted a bug in the tracker, so I thought I'd raise
it here first.
unittest has assertIn, assertNotIn, assertEqual, assertNotEqual and so on.
So, it seems odd to me that there isn't assertNotRaises. Is there any
particular motivation for not putting it in?
I've
Sure, you just *do* it. The only advantage I see in assertNotRaises is that
when that exception is raised, you should (and would) get a failure, not an
error.
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, Sep 27, 2011 at 07:46:52PM +0100, Wilfred Hughes wrote:
+def assertNotRaises(self, excClass, callableObj=None, *args, **kwargs):
+Fail if an exception of class excClass is thrown by
+callableObj when invoked with arguments args and keyword
+arguments kwargs.
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 11:20 AM, Ethan Furman et...@stoneleaf.us wrote:
I personally would use the step value far more often than the count
value.
But that's exactly what we don't *want* you to do! Because (unless you
are a numerical wizard) you probably aren't doing
On 9/27/2011 1:03 PM, Guido van Rossum wrote:
mimicking the behavior of range() for floats is a bad idea, and that
we need to come up with a name for an API that takes start/stop/count
arguments instead of start/stop/step.
[In the following, I use count as the number of intervals; the number
Given the feedback so far, I am happy to pronounce PEP 393 as
accepted. Martin, congratulations! Go ahead and mark ity as Accepted.
(But please do fix up the small nits that Victor reported in his
earlier message.)
--
--Guido van Rossum (python.org/~guido)
On Tue, Sep 27, 2011 at 2:53 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Sep 27, 2011 at 11:48 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum gu...@python.org wrote:
..
But that's exactly what we don't *want* you to
On 9/27/2011 2:46 PM, Wilfred Hughes wrote:
Hi folks
I wasn't sure if this warranted a bug in the tracker, so I thought I'd
raise it here first.
unittest has assertIn, assertNotIn, assertEqual, assertNotEqual and so
These all test possible specification conditions and sensible test
On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman et...@stoneleaf.us wrote:
Good points. So how about:
some_name_here(start, stop, *, step=None, count=None)
? I personally would use the step value far more often than the count
value.
Let's call it xrange() or maybe range_ex(). wink But
On Tue, Sep 27, 2011 at 1:05 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Sep 27, 2011 at 2:53 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Sep 27, 2011 at 11:48 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Sep 27, 2011 at 2:36 PM,
On Tue, Sep 27, 2011 at 1:12 PM, Eric Snow ericsnowcurren...@gmail.com wrote:
On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman et...@stoneleaf.us wrote:
Good points. So how about:
some_name_here(start, stop, *, step=None, count=None)
? I personally would use the step value far more often
Guido van Rossum wrote:
But why offer an API that is an attractive nuisance? I don't think
that it is a burden to the user to have to specify from 0 to 2 inches
in 8 steps instead of from 0 to 2 inches in 1/4 inch steps. (And
what if they tried to say from 0 to 3 1/4 inches in 1/2 inch steps
?)
Alexander Belopolsky wrote:
I don't think we'll gain anything by
copying numpy code because linspace(start, stop, num) is effectively
just
arange(0, num) * step + start
I don't think the intention was to literally copy the
code, but to investigate borrowing the algorithm, in case
it was using
On Tue, Sep 27, 2011 at 1:21 PM, Ethan Furman et...@stoneleaf.us wrote:
Guido van Rossum wrote:
But why offer an API that is an attractive nuisance? I don't think
that it is a burden to the user to have to specify from 0 to 2 inches
in 8 steps instead of from 0 to 2 inches in 1/4 inch steps.
Alexander Belopolsky wrote:
(Comb (noun) brings up the right image, but is probably too
informal and may be confused with a short for combination.)
And also with comb filter for those who are into
signal processing.
--
Greg
___
Python-Dev mailing
Ethan Furman wrote:
If it's generic, why should it live in math?
Generic? Maybe that's it: grange()
It's also an English word, unfortunately one with a
completely unrelated meaning. :-(
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 1:21 PM, Ethan Furman et...@stoneleaf.us wrote:
Guido van Rossum wrote:
But why offer an API that is an attractive nuisance? I don't think
that it is a burden to the user to have to specify from 0 to 2 inches
in 8 steps instead of from 0 to 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/27/2011 05:39 PM, Greg Ewing wrote:
Ethan Furman wrote:
If it's generic, why should it live in math?
Generic? Maybe that's it: grange()
It's also an English word, unfortunately one with a completely
unrelated meaning. :-(
One could
I have redone my memory benchmark, and added a few new
counters.
The application is a very small Django application. The same
source code of the app and Django itself is used on all Python
versions. The full list of results is at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/djmemprof/
Here are
The deadline for PyCon 2012 tutorial, talk, and poster proposals is
under 15 days away, so be sure to get your submissions in by October
12, 2011. Whether you’re a first-timer or an experienced veteran,
PyCon is depends on you, the community, coming together to build the
best conference schedule
Great news, Martin!
On Tue, Sep 27, 2011 at 3:56 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I have redone my memory benchmark, and added a few new
counters.
The application is a very small Django application. The same
source code of the app and Django itself is used on all Python
Oleg Broytman wrote:
On Tue, Sep 27, 2011 at 07:46:52PM +0100, Wilfred Hughes wrote:
+def assertNotRaises(self, excClass, callableObj=None, *args, **kwargs):
+Fail if an exception of class excClass is thrown by
+callableObj when invoked with arguments args and keyword
+
On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano st...@pearwood.info wrote:
But I can't see this being a useful test. As written, exceptions are still
treated as errors, except for excClass, which is treated as a test failure. I
can't see the use-case for that. assertRaises is useful:
On Sep 27, 2011, at 3:22 PM, Ethan Furman wrote:
Well, actually, I'd be using it with dates. ;)
FWIW, an approach using itertools is pretty general but even it doesn't work
for dates :-)
from itertools import count, takewhile
from decimal import Decimal
from fractions import Fraction
On 27 Sep, 11:58 pm, ckay...@zindagigames.com wrote:
On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano st...@pearwood.info
wrote:
But I can't see this being a useful test. As written, exceptions are
still treated as errors, except for excClass, which is treated as a
test failure. I can't see
Ethan Furman writes:
Well, actually, I'd be using it with dates. ;)
Why are you representing dates with floats?
(That's a rhetorical question, don't answer it.)
This is the whole problem with this discussion. Guido is saying (and
I think it's plausible though I don't have enough experience
On Sep 27, 2011 5:56 PM, exar...@twistedmatrix.com wrote:
assertNotRaises doesn't make anything possible that isn't possible now. It
probably doesn't even make anything easier - but if it does, it's so obscure
(and I've read and written thousands of tests for all kinds of libraries
over the
51 matches
Mail list logo
