Am 28.09.2011 08:35, schrieb martin.v.loewis:
> http://hg.python.org/cpython/rev/8beaa9a37387
> changeset: 72475:8beaa9a37387
> user:Martin v. Löwis
> date:Wed Sep 28 07:41:54 2011 +0200
> summary:
> Implement PEP 393.
>
[...]
>
> diff --git a/Doc/c-api/unicode.rst b/Doc/c-ap
On Sep 27, 2011 5:56 PM, 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 years) that it doesn't mer
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 27 Sep, 11:58 pm, ckay...@zindagigames.com wrote:
On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano
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 th
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 Fra
On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano 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:
>
> "IOError is allowed,
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
+
Great news, Martin!
On Tue, Sep 27, 2011 at 3:56 PM, "Martin v. Löwis" 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
> versions. The full
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 po
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
-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
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 1:21 PM, Ethan Furman 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
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
http
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 mai
On Tue, Sep 27, 2011 at 1:21 PM, Ethan Furman 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". (And
>
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
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
On Tue, Sep 27, 2011 at 1:12 PM, Eric Snow wrote:
> On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman 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 cal
On Tue, Sep 27, 2011 at 1:05 PM, Alexander Belopolsky
wrote:
> On Tue, Sep 27, 2011 at 2:53 PM, Guido van Rossum wrote:
>> On Tue, Sep 27, 2011 at 11:48 AM, Alexander Belopolsky
>> wrote:
>>> On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum wrote:
>>> ..
But that's exactly what we don't *
On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman 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().But seriously,
here's an
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
condition
On Tue, Sep 27, 2011 at 2:53 PM, Guido van Rossum wrote:
> On Tue, Sep 27, 2011 at 11:48 AM, Alexander Belopolsky
> wrote:
>> On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum wrote:
>> ..
>>> But that's exactly what we don't *want* you to do! Because (unless you
>>> are a numerical wizard) you
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 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 o
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 11:20 AM, Ethan Furman 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
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 k
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
http://mail.python.org/mailman/listinfo/python
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
On Tue, Sep 27, 2011 at 11:48 AM, Alexander Belopolsky
wrote:
> On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum 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 "u
On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum 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 inaccuracies. F
On Tue, Sep 27, 2011 at 2:20 PM, Ethan Furman 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 is
given, stop
On Tue, Sep 27, 2011 at 11:20 AM, Ethan Furman 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 to avoid the "unex
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 t
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
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
optiona
On Tue, Sep 27, 2011 at 10:11 AM, Alexander Belopolsky
wrote:
> On Tue, Sep 27, 2011 at 1:03 PM, Guido van Rossum 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 wit
On Tue, Sep 27, 2011 at 1:03 PM, Guido van Rossum 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
> arguments instead of
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 Gre
On Tue, Sep 27, 2011 at 9:16 AM, Alexander Belopolsky
wrote:
> On Tue, Sep 27, 2011 at 11:44 AM, Raymond Hettinger
> 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 varia
On Tue, Sep 27, 2011 at 12:20 PM, Steven D'Aprano 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 we may already hav
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 t
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 equ
On Tue, Sep 27, 2011 at 11:44 AM, Raymond Hettinger
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 works reasonably well if th
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 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 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 c
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
>> wrote:
>> ..
>>> And I don't like "linspace" either. Something more self
>>> explanatory such as "subdivide" or "interpolate" might
>>> be better.
>> "Grid" would be
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing 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 c
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing 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 think it should b
On Mon, Sep 26, 2011 at 9:25 PM, Steven D'Aprano 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
>
> While continuity of API might be a good thing, we shouldn't accept
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 maili
50 matches
Mail list logo
