Re: [Python-Dev] PEP 393 close to pronouncement
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 mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 a poor > API just for the sake of continuity. I have some criticisms of the linspace > API. +1 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 equally spaces dates or datetime points. It would be nice if a new function would allow start and stop to be any type that supports subtraction and whose differences support division by numbers. Also, in terms of implementation, 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 where step is (stop-start)/(num-1). This works because numpy arrays (produced by arange()) support linear algebra and we are not going to copy that. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 be a noun rather than a
verb. ("Comb" (noun) brings up the right image, but is probably too
informal and may be confused with a short for "combination.")
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 choose, I think it should be a noun rather than a
verb. ("Comb" (noun) brings up the right image, but is probably too
informal and may be confused with a short for "combination.")
segment? srange?
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 nice and short, but may suggest 2-dimentional result.
>> Whatever word we choose, I think it should be a noun rather than a
>> verb. ("Comb" (noun) brings up the right image, but is probably too
>> informal and may be confused with a short for "combination.")
>
> segment? srange?
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 the default argument pattern is the same as
range: frange(10.0, 20.0, 0.5)
There could be an optional argument to compute the interval: frange(10.0,
20.0, numpoints=20)
And possibly a option to include both endpoints: frange(10.0, 20.0, 0.5,
inclusive=True)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 choose, I think it should be a noun rather than a
verb. ("Comb" (noun) brings up the right image, but is probably too
informal and may be confused with a short for "combination.")
I came up with "spread".
Here's my second attempt, which offers both count/start/end and
count/start/step APIs:
http://code.activestate.com/recipes/577881-equally-spaced-floats-part-2/
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 be nice and short, but may suggest 2-dimentional result.
Whatever word we choose, I think it should be a noun rather than a
verb. ("Comb" (noun) brings up the right image, but is probably too
informal and may be confused with a short for "combination.")
segment? srange?
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 the default argument pattern is the same as
range: frange(10.0, 20.0, 0.5)
There could be an optional argument to compute the interval: frange(10.0,
20.0, numpoints=20)
And possibly a option to include both endpoints: frange(10.0, 20.0, 0.5, inclusive=True)
I like the numpoints option.
I also like Alexander's idea of making this new range able to work with
other types that support addition/division -- but in that case does the
'f' prefix still make sense?
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 the default argument pattern is the same as > range: frange(10.0, 20.0, 0.5) +1 on adding frange() to math module or to the recently contemplated stats module. For something that aspires to becoming a builtin one day, I would like to see something not focused on floats exclusively and something with a proper English name. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 equally spaces dates or datetime points. It would be nice if a new function would allow start and stop to be any type that supports subtraction and whose differences support division by numbers. I think a polymorphic numeric range function would be useful. 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. Who is going to think to import math if you want a range of dates? -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 to generate a list of equally spaces dates or datetime points. It would be nice if a new function would allow start and stop to be any type that supports subtraction and whose differences support division by numbers. I think a polymorphic numeric range function would be useful. 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. Who is going to think to import math if you want a range of dates? If it's generic, why should it live in math? ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 have a similar function there and nobody knows about it. > Who is going to > think to import math if you want a range of dates? No one. That's why I said that if the new function ends up in math or stats, I am +1 on frange(). However, I did in the past try to give dates for start and stop and a timedelta for step expecting range() to work. This would be similar to the way sum works for non-numeric types when an appropriate start value is given. BTW, at the time when I worked on extending (x)range to long integers, I attempted to make it work on dates, but at that time timedelta did not support division by integer, so I refocused on that instead. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 variant of range() that creates floats. >> >> That works reasonably well if the default argument pattern is the same as >> range: frange(10.0, 20.0, 0.5) > > +1 on adding frange() to math module or to the recently contemplated > stats module. For something that aspires to becoming a builtin one > day, I would like to see something not focused on floats exclusively > and something with a proper English name. 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 start/stop/step. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 Greenfield ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 start/stop/step. 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 arguments and documentation, I don't see why it can't be called frange() *and* support count. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 with a name for an API that takes start/stop/count >> arguments instead of start/stop/step. > > 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 arguments and documentation, I don't see why it can't be > called frange() *and* support count. But I do. :-) Calling it frange() is pretty much *begging* people to assume that the 3rd parameter has the same meaning as for range(). Now, there are a few cases where that doesn't matter, e.g. frange(0, 100, 10) will do the expected thing under both interpretations, but frange(0, 100, 5) will not. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 arguments and documentation, I don't see why it can't be called frange() *and* support count. But I do. :-) Calling it frange() is pretty much *begging* people to assume that the 3rd parameter has the same meaning as for range(). Now, there are a few cases where that doesn't matter, e.g. frange(0, 100, 10) will do the expected thing under both interpretations, but frange(0, 100, 5) will not. 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. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 range *by far* is for counting, and in Python we count 0, 1, 2, ... Similarly, we usually count every item, so a default step of 1 is useful. But for numeric work, neither of those defaults are useful. This proposed spread/frange/whatever function will be used for generating a sequence of equally spaced numbers, and not for counting. A starting value of 0.0 is generally no more special than any other starting value. There is no good reason to single out default start=0. Likewise a step-size of 1.0 is also arbitrary. It isn't useful to hammer the square peg of numeric ranges into the round hole of integer counts. We should not try to force this float range to use the same API as builtin range. (In hindsight, it is a shame that range is called "range" instead of "count". itertools got the name right.) -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 the most common use for range *by far* is for counting, and in Python we count 0, 1, 2, ... Similarly, we usually count every item, so a default step of 1 is useful. But for numeric work, neither of those defaults are useful. This proposed spread/frange/whatever function will be used for generating a sequence of equally spaced numbers, and not for counting. A starting value of 0.0 is generally no more special than any other starting value. There is no good reason to single out default start=0. Likewise a step-size of 1.0 is also arbitrary. It isn't useful to hammer the square peg of numeric ranges into the round hole of integer counts. We should not try to force this float range to use the same API as builtin range. (In hindsight, it is a shame that range is called "range" instead of "count". itertools got the name right.) 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. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 "unexpected extra point" problem due to floating point inaccuracies. For your own good, we want you to state the count and let us deliver the number of points you want. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 can be elided. This will make for a nice symmetry: between stop, step and count any two can be provided but stop+step may be problematic and we can warn about this choice in the docs. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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. For your own good, we want you to state the count > and let us deliver the number of points you want. But the likely result will be that a non-wizard will find that range() does not work with floats, reach for some_name_here(), find the absence of step option, curse the developers, write count=int((stop-start)/step) and leave this with a nagging thought that (s)he forgot +/-1 somewhere. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 "unexpected extra point" problem due to floating >> point inaccuracies. For your own good, we want you to state the count >> and let us deliver the number of points you want. > > But the likely result will be that a non-wizard will find that range() > does not work with floats, reach for some_name_here(), find the > absence of step option, curse the developers, write > count=int((stop-start)/step) and leave this with a nagging thought > that (s)he forgot +/-1 somewhere. But the *user* can just force this to round by using int((stop-start+0.5)/step) or by using int(round()); either of these is an easy pattern to teach and learn and useful in many other places. The problem is that frange() cannot do that rounding for you, since its contract (if it is to be analogous to range() at all) is that there is no assumption that stop is anywhere close to start + a multiple of step. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unittest missing assertNotRaises
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 attached a simple patch against Python 3's trunk to give an idea of
what I have in mind.
Thanks
Wilfred
diff -r 84280fac98b9 Lib/unittest/case.py
--- a/Lib/unittest/case.py Tue Sep 27 07:30:00 2011 +0200
+++ b/Lib/unittest/case.py Tue Sep 27 19:45:03 2011 +0100
@@ -542,6 +542,18 @@
except UnicodeDecodeError:
return '%s : %s' % (safe_repr(standardMsg), safe_repr(msg))
+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.
+
+"""
+try:
+callableObj(*args, **kwargs)
+except excClass:
+raise self.failureException("%s was raised" % excClass)
+
+
def assertRaises(self, excClass, callableObj=None, *args, **kwargs):
"""Fail unless an exception of class excClass is thrown
by callableObj when invoked with arguments args and keyword
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest missing assertNotRaises
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-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest missing assertNotRaises
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.
> +
> +"""
> +try:
> +callableObj(*args, **kwargs)
> +except excClass:
> +raise self.failureException("%s was raised" % excClass)
> +
> +
What if I want to assert my test raises neither OSError nor IOError?
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 needed to avoid the "unexpected extra point" problem due to floating point inaccuracies. For your own good, we want you to state the count and let us deliver the number of points you want. Well, actually, I'd be using it with dates. ;) ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 of points is 1 more.] I agree with others that we should not just have a floatrange. An exact-as-possible floatrange is trivially based on exact computations with fractions: def floatrange(a, b, n): '''Yield floats a, b, and n-1 equally spaced floats in between.''' for num,dem in fracrange(a.as_integer_ratio(), b.as_integer_ratio(), n): yield num/dem There are good reasons to expose the latter. If fracrange is done with the Fraction class, each ratio will be reduced to lowest terms, which means that the denominator will vary for each pair. In some situations, one might prefer a constant denominator across the series. Once a constant denominator is calculated (eash though not trivial), fracrange is trivially based on range. The following makes the denominator as small as possible if the inputs are in lowest terms: def fracrange(frac1, frac2, n): '''Yield fractions frac1, frac2 and n-1 equally spaced fractions in between. Fractions are represented as (numerator, denominator > 0) pairs. For output, use the smallest common denominator of the inputs that makes the numerator range an even multiple of n. ''' n1, d1 = frac1 n2, d2 = frac2 dem = d1 * d2 // gcd(d1, d2) start = n1 * (dem // d1) stop = n2 * (dem // d2) rang = stop - start q, r = divmod(rang, n) if r: gcd_r_n = gcd(r, n) m = n // gcd_r_n dem *= m start *= m stop *= m step = rang // gcd_r_n # rang * m // n else: step = q # if r==0: gcd(r,n)==n, m==1, rang//n == q for num in range(start, stop+1, step): yield num,dem Two example uses: for i,j in fracrange((1,10), (22,10), 7): print(i,j) print() for i,j in fracrange((1,5), (1,1), 6): print(i,j) ## print 1 10 4 10 7 10 10 10 13 10 16 10 19 10 22 10 3 15 5 15 7 15 9 15 11 15 13 15 15 15 If nothing else, the above is easy to check for correctness ;-). Note that for fraction output, one will normally want to be able to enter an explicit pair such as (1,5) or even (2,10) The decimal equivalent, .2, after conversion to float, gets converted by .as_integer_ratio() back to (3602879701896397, 18014398509481984). -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393 close to pronouncement
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) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 probably aren't doing the error analysis >>> needed to avoid the "unexpected extra point" problem due to floating >>> point inaccuracies. For your own good, we want you to state the count >>> and let us deliver the number of points you want. I don't disagree that the ability to provide count= option is useful. I am just saying that there are also cases where float step is known exactly and count (or stop) can be deduced from stop (or count) without any floating point issues. Iteration over integers that happen to be represented by floats is one use case, but using integer range may be a better option in this case. In US it is still popular to measure things in power of two fractions. Simulating a carpenter's yard does not suffer from rounding when done in floats. Counting by .5 and .25 has its uses too. Maybe frange() should just signal the FP inexact exception if we expect users to need hand holding to such a degree. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest missing assertNotRaises
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 conditions. For instance -1 and particularly 3 should not be in range(3). Including 3 is a realistic possible error. If you partition a set into subsets < x and > x, x should not be in either, but an easy mistake would put it in either or both. Is there any particular motivation for not putting it in? You have 'motivation' backwards. There are an infinity of things we could add. We need a positive, substantial reason with real use cases to add something. An expression should return a particular value or return a particular expression. If it returns a value, testing that it is the correct value eliminates all exceptions. And testing for an expected exception eliminates all others. If there is an occasional needed for the proposal, one can write the same code you did, but with the possibility of excluding more than one exception. So I do not see any need for the proposal. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 approach that extends the generic replacement idea a bit. I like the idea of the "some_name_here" function as a builtin in conjunction with Alexander's idea of a generic function, a la len() or repr(). Like those other builtin generic functions, it would leverage special methods (whether new or existing) to use the "range protocol" of objects. The builtin would either replace range() (and assume its name) or be a new builtin with a parallel name to range(). Either way, it would return an object of the new/refactored range type, which would reflect the above signature. If the new builtin were to rely on a new range-related protocol (i.e. if it were needed), that protocol could distinguish support for stepping from support for counting. Then floats could simply not support the stepping portion. And the fate of range()? As far as the existing builtin range() goes, either we would leave it alone, we would make range() a wrapper function around a new range type, or the new range type would completely replace the old. If we were to leave it alone, the new builtin would have a name that parallels the old name. Then we wouldn't have to worry about backward compatibility for performance, type, or signature. Going the wrapper function route would preserve backward compatibility for the function signature, but isinstance(obj, range) wouldn't work anymore. Whether leaving range() alone or making it a wrapper, we could replace it with the new builtin in Python 4, if it made sense (like happened with xrange). If we entirely replaced the current range() with the new (more generic) range type, the biggest concern is maintaining backward compatibility with the function signature, in both Python and the C-API. That would be tricky since the above signature seems incompatible with the current one. -eric > > ~Ethan~ > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 *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. For your own good, we want you to state the count and let us deliver the number of points you want. > > I don't disagree that the ability to provide count= option is useful. > I am just saying that there are also cases where float step is known > exactly and count (or stop) can be deduced from stop (or count) > without any floating point issues. Iteration over integers that > happen to be represented by floats is one use case, but using integer > range may be a better option in this case. In US it is still popular > to measure things in power of two fractions. Simulating a carpenter's > yard does not suffer from rounding when done in floats. Counting by > .5 and .25 has its uses too. Maybe frange() should just signal the FP > inexact exception if we expect users to need hand holding to such a > degree. 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" ?) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 call it xrange() or maybe range_ex(). But seriously, > here's an approach that extends the generic replacement idea a bit. > > I like the idea of the "some_name_here" function as a builtin in > conjunction with Alexander's idea of a generic function, a la len() or > repr(). Like those other builtin generic functions, it would leverage > special methods (whether new or existing) to use the "range protocol" > of objects. > > The builtin would either replace range() (and assume its name) or be a > new builtin with a parallel name to range(). Either way, it would > return an object of the new/refactored range type, which would reflect > the above signature. > > If the new builtin were to rely on a new range-related protocol (i.e. > if it were needed), that protocol could distinguish support for > stepping from support for counting. Then floats could simply not > support the stepping portion. This sound like a rather over-designed API. > And the fate of range()? > > As far as the existing builtin range() goes, either we would leave it > alone, we would make range() a wrapper function around a new range > type, or the new range type would completely replace the old. If we > were to leave it alone, the new builtin would have a name that > parallels the old name. Then we wouldn't have to worry about backward > compatibility for performance, type, or signature. > > Going the wrapper function route would preserve backward compatibility > for the function signature, but isinstance(obj, range) wouldn't work > anymore. Whether leaving range() alone or making it a wrapper, we > could replace it with the new builtin in Python 4, if it made sense > (like happened with xrange). > > If we entirely replaced the current range() with the new (more > generic) range type, the biggest concern is maintaining backward > compatibility with the function signature, in both Python and the > C-API. That would be tricky since the above signature seems > incompatible with the current one. > > -eric > >> >> ~Ethan~ >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com >> > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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" ?) And how many steps in "from 37 3/4 inches to 90 1/4 inches" ? I don't want to have to calculate that. That's what computers are for. Your last example is no different than today's range(2, 10, 3) -- we don't get 10 or 9. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 some special technique to maximise numerical accuracy. But from this it seems like it's just using the naive algorithm that we've already decided is not the best. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 >> what if they tried to say "from 0 to 3 1/4 inches in 1/2 inch steps" >> ?) > > And how many steps in "from 37 3/4 inches to 90 1/4 inches" ? I don't want > to have to calculate that. That's what computers are for. That's just silly. The number of steps is (stop - start) / step. > Your last example is no different than today's range(2, 10, 3) -- we don't > get 10 or 9. The difference is that most operations on integers, by their nature, give give exact results, except for division (which is defined as producing a float in Python 3). Whether float operations give exact results or not is a lot harder to know, and the various IEEE states are hard to access. Just because the US measurement system happens to use only values that are exactly representable as floats doesn't mean floats are great to represent measurements. (What if you have to cut a length of string in three equal pieces?) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 steps". (And what if they tried to say "from 0 to 3 1/4 inches in 1/2 inch steps" ?) And how many steps in "from 37 3/4 inches to 90 1/4 inches" ? I don't want to have to calculate that. That's what computers are for. That's just silly. The number of steps is (stop - start) / step. Not silly at all -- it begs for an api of (start, stop, step), not (start, stop, count). Personally, I have no problems with typing either 'step=...' or 'stop=...', but I think losing step as an option is a *ahem* step backwards. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
-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 always think of the Midwest US farm country, cut into even one-mile sections by dirt roads, and think of 'grange'. :) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6CRUMACgkQ+gerLs4ltQ7EYgCgi/iJqg4Wq8LVF25kd6gS0yN/ MQ4An1kl/+8uBcFzAJPPNPL1iBqSNwJM =2IUq -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 393 memory savings update
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 some excerpts: A. 32-bit builds, storage for Unicode objects 3.x, 32-bit wchar_t: 6378540 3.x, 16-bit wchar_t: 3694694 PEP 393: 2216807 Compared to the previous results, there are now some significant savings even compared to a narrow unicode build. B. 3.x, number of strings by maxchar: ASCII: 35713 (1,300,000 chars) Latin-1: 235 (11,000 chars) BMP: 260 (700 chars) other: 0 total: 36,000 (1,310,000 chars) This explains why the savings for shortening ASCII objects are significant in this application. I have no good intuition how this effect would show for "real" applications. It may be that the percentage of ASCII strings (in number and chars) grows proportionally with the total number of strings; it may also be that the majority of these strings is a certain fixed overhead (resulting from Python identifiers and other interned strings). C. String-ish objects in 2.7 and 3.3-trunk: 2.x 3.x #unicode 370 36,000 #bytes 43,000 14,000 #total 43,400 50,000 len(unicode) 5,300 1,306,000 len(bytes) 2,040,000 860,000 len(total) 2,046,000 2,200,000 (Note: the computations in the results are slightly messed up: the number of bytes for bytes objectts is actually the sum of the lengths, not the sum of the sizeofs; this gets added in the "total" lines to the sum of sizeofs of unicode strings, which is non-sensical. The table above corrects this) As you can see, Python 3 creates more string objects in total. D. Memory consumption for 2.x, 3.x, PEP 393, accounting both unicode and bytes objects, using 32-bit builds and 32-bit wchar_t: 2.x: 3,620,000 bytes 3.x: 7,750,000 bytes PEP 393: 3,340,000 bytes This suggests that PEP 393 actually reduces memory consumption below what 2.7 uses. This is offset though by "other" (non-string) objects, which take 300KB more in 3.x. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyCon 2012 Proposals Due October 12
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 possible. Our call for proposals (http://us.pycon.org/2012/cfp/) lays out the details it takes to be included in the lineup for the conference in Santa Clara, CA on March 7-15, 2012. If you’re unsure of what to write about, our recent survey yielded a large list of potential talk topics (http://pycon.blogspot.com/2011/09/need-talk-ideas.html), and plenty of ideas for tutorials (INSERT TUTORIAL POST). We’ve also come up with general tips on proposal writing at http://pycon.blogspot.com/2011/08/writing-good-proposal.html to ensure everyone has the most complete proposal when it comes time for review. As always, the program committee wants to put together an incredible conference, so they’ll be working with submitters to fine tune proposal details and help you produce the best submissions. We’ve had plenty of great news to share since we first announced the call for proposals. Paul Graham of Y Combinator was recently announced as a keynote speaker (http://pycon.blogspot.com/2011/09/announcing-first-pycon-2012-keynote.html), making his return after a 2003 keynote. David Beazley, famous for his mind-blowing talks on CPython’s Global Interpreter Lock, was added to the plenary talk series (http://pycon.blogspot.com/2011/09/announcing-first-pycon-2012-plenary.html). Sponsors can now list their job openings on the “Job Fair” section of the PyCon site (http://pycon.blogspot.com/2011/09/announcing-pycon-2012-fair-page-sponsor.html). We’re hard at work to bring you the best conference yet, so stay tuned to PyCon news at http://pycon.blogspot.com/ and on Twitter at https://twitter.com/#!/pycon. We recently eclipsed last year’s sponsorship count of 40 and are currently at a record 52 organizations supporting PyCon. If you or your organization are interested in sponsoring PyCon, we’d love to hear from you, so check out our sponsorship page (http://us.pycon.org/2012/sponsors/). A quick thanks to all of our awesome PyCon 2012 Sponsors: - Diamond Level: Google and Dropbox. - Platinum Level: New Relic, SurveyMonkey, Microsoft, Eventbrite, Nasuni and Gondor.io - Gold Level: Walt Disney Animation Studios, CCP Games, Linode, Enthought, Canonical, Dotcloud, Loggly, Revsys, ZeOmega, Bitly, ActiveState, JetBrains, Caktus, Disqus, Spotify, Snoball, Evite, and PlaidCloud - Silver Level: Imaginary Landscape, WiserTogether, Net-ng, Olark, AG Interactive, Bitbucket, Open Bastion, 10Gen, gocept, Lex Machina, fwix, github, toast driven, Aarki, Threadless, Cox Media, myYearBook, Accense Technology, Wingware, FreshBooks, and BigDoor - Lanyard: Dreamhost - Sprints: Reddit - FLOSS: OSU/OSL, OpenHatch The PyCon Organizers - http://us.pycon.org/2012 Jesse Noller - Chairman - jnol...@python.org Brian Curtin - Publicity Coordinator - br...@python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393 memory savings update
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 list of results is at > > http://www.dcl.hpi.uni-potsdam.de/home/loewis/djmemprof/ > > Here are some excerpts: > > A. 32-bit builds, storage for Unicode objects > 3.x, 32-bit wchar_t: 6378540 > 3.x, 16-bit wchar_t: 3694694 > PEP 393: 2216807 > > Compared to the previous results, there are now some > significant savings even compared to a narrow unicode build. > > B. 3.x, number of strings by maxchar: > ASCII: 35713 (1,300,000 chars) > Latin-1: 235 (11,000 chars) > BMP: 260 (700 chars) > other: 0 > total: 36,000 (1,310,000 chars) > > This explains why the savings for shortening ASCII objects > are significant in this application. I have no good intuition > how this effect would show for "real" applications. It may be > that the percentage of ASCII strings (in number and chars) grows > proportionally with the total number of strings; it may also > be that the majority of these strings is a certain fixed overhead > (resulting from Python identifiers and other interned strings). > > C. String-ish objects in 2.7 and 3.3-trunk: > 2.x 3.x > #unicode 370 36,000 > #bytes 43,000 14,000 > #total 43,400 50,000 > > len(unicode) 5,300 1,306,000 > len(bytes) 2,040,000 860,000 > len(total) 2,046,000 2,200,000 > > (Note: the computations in the results are slightly messed up: > the number of bytes for bytes objectts is actually the sum > of the lengths, not the sum of the sizeofs; this gets added > in the "total" lines to the sum of sizeofs of unicode strings, > which is non-sensical. The table above corrects this) > > As you can see, Python 3 creates more string objects in total. > > D. Memory consumption for 2.x, 3.x, PEP 393, accounting both > unicode and bytes objects, using 32-bit builds and 32-bit > wchar_t: > 2.x: 3,620,000 bytes > 3.x: 7,750,000 bytes > PEP 393: 3,340,000 bytes > > This suggests that PEP 393 actually reduces memory consumption > below what 2.7 uses. This is offset though by "other" (non-string) > objects, which take 300KB more in 3.x. > > Regards, > Martin > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest missing assertNotRaises
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
+arguments kwargs.
+
+"""
+try:
+callableObj(*args, **kwargs)
+except excClass:
+raise self.failureException("%s was raised" % excClass)
+
+
What if I want to assert my test raises neither OSError nor IOError?
Passing (OSError, IOError) as excClass should do it.
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, but any other exception is a bug."
makes perfect sense. assertNotRaises doesn't seem sensible or useful to me:
"IOError is a failed test, but any other exception is a bug."
What's the point? When would you use that?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest missing assertNotRaises
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, but any other exception is a bug." > > makes perfect sense. assertNotRaises doesn't seem sensible or useful to me: > > "IOError is a failed test, but any other exception is a bug." > > What's the point? When would you use that? > I've run across a few cases where this is the correct behavior. The most recent one that comes to mind is while testing some code which has specific silencing options: specifically, writing a main file and a backup file, where failure to write the backup is not an error, but failure to write the main is. As such, the test suite should have the following tests: - Failure to write the main should assert that the code raises the failure error. No error is a failure, any other error is an error, that error is a success. (it may also check that the backup was written) - Failure to write the backup should assert that the code does not raise the failure error. No error is a success, that error is a failure, any other error is a error. (it may also check that the main was written) - Both succeeding should assert that the files were actually written, and that no error was raised. Any other result is an error. Now, the difference between a Failure and an Error is more or less a mute point, however I would expect an Error to be any unexpected result, while a Failure is a predicted (either via forethought or prior tests) but incorrect result. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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
>>> list(takewhile(lambda x: x<=10.0, count(0.0, 0.5)))
[0.0, 0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5.0, 5.5, 6.0, 6.5, 7.0,
7.5, 8.0, 8.5, 9.0, 9.5, 10.0]
>>> list(takewhile(lambda x: x<=Decimal(1), count(Decimal(0), Decimal('0.1'
[Decimal('0'), Decimal('0.1'), Decimal('0.2'), Decimal('0.3'), Decimal('0.4'),
Decimal('0.5'), Decimal('0.6'), Decimal('0.7'), Decimal('0.8'), Decimal('0.9'),
Decimal('1.0')]
>>> list(takewhile(lambda x: x<=Fraction(2), count(Fraction(0), Fraction(1,3
[Fraction(0, 1), Fraction(1, 3), Fraction(2, 3), Fraction(1, 1), Fraction(4,
3), Fraction(5, 3), Fraction(2, 1)]
>>> from datetime import date, timedelta
>>> list(takewhile(lambda x: x<=date(2011,12,31), count(date(2011,9,27),
>>> timedelta(days=7
Traceback (most recent call last):
File "", line 1, in
list(takewhile(lambda x: x<=date(2011,12,31), count(date(2011,9,27),
timedelta(days=7
TypeError: a number is required
Raymond___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest missing assertNotRaises
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 that. assertRaises is useful: "IOError is allowed, but any other exception is a bug." makes perfect sense. assertNotRaises doesn't seem sensible or useful to me: "IOError is a failed test, but any other exception is a bug." What's the point? When would you use that? I've run across a few cases where this is the correct behavior. The most recent one that comes to mind is while testing some code which has specific silencing options: specifically, writing a main file and a backup file, where failure to write the backup is not an error, but failure to write the main is. As such, the test suite should have the following tests: - Failure to write the main should assert that the code raises the failure error. No error is a failure, any other error is an error, that error is a success. (it may also check that the backup was written) This is assertRaises, not assertNotRaises. - Failure to write the backup should assert that the code does not raise the failure error. No error is a success, that error is a failure, any other error is a error. (it may also check that the main was written) This is calling the function and asserting something about the result. - Both succeeding should assert that the files were actually written, and that no error was raised. Any other result is an error. Now, the difference between a Failure and an Error is more or less a mute point, however I would expect an Error to be any unexpected result, while a Failure is a predicted (either via forethought or prior tests) but incorrect result. 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 merit a dedicated helper in the unittest library. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
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 to be
sure myself) that if you look at the various use cases for such
functions, they're different enough that it's going to be hard to come
up with a single API that is good, let alone optimal, for them all.
Then people keep coming back with "but look at X, where this API is
clearly very useful", for values of X restricted to "stuff they do".
That's good module design; it's not a good idea for the language
(including builtins). Remember, something like range (Python 3) or
range (Python 2) was *really necessary*[1] to express in Python the
same algorithm that the C construct 'for' does. I agree with Steven
d' that count would have been a somewhat better name (at least in my
dialect it is possible, though somewhat unusual, to say "count up from
10 to 20 by 3s"), but that doesn't become clear until you want to talk
about polymorphic versions of the concept. Also, in statistics
"range" refers to a much smaller set (ie, {min, max}) than it does in
Python, not that I really care.
As far as a name for a more general concept, perhaps "interval" would
be an interesting choice (although in analysis it has a connotation of
continuity that would be inappropriate for a discrete set of floats).
Footnotes:
[1] FSVO "necessary" that includes "let's not do arithmetic on the
index variable inside the loop".
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest missing assertNotRaises
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 merit a dedicated helper in the unittest library. > > Jean-Paul > +1 for keeping it simple. TOOWTDI. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Implement PEP 393.
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-api/unicode.rst > --- a/Doc/c-api/unicode.rst > +++ b/Doc/c-api/unicode.rst > @@ -1072,6 +1072,15 @@ > occurred and an exception has been set. > > > +.. c:function:: Py_ssize_t PyUnicode_FindChar(PyObject *str, Py_UCS4 ch, > Py_ssize_t start, Py_ssize_t end, int direction) > + > + Return the first position of the character *ch* in ``str[start:end]`` > using > + the given *direction* (*direction* == 1 means to do a forward search, > + *direction* == -1 a backward search). The return value is the index of > the > + first match; a value of ``-1`` indicates that no match was found, and > ``-2`` > + indicates that an error occurred and an exception has been set. > + > + > .. c:function:: Py_ssize_t PyUnicode_Count(PyObject *str, PyObject *substr, > Py_ssize_t start, Py_ssize_t end) > > Return the number of non-overlapping occurrences of *substr* in This is the only doc change for this change (and it doesn't have a versionadded). Surely there must be more new APIs and changes that need documenting? Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
