Mailman 3 January 2015 - Python-ideas

Re: [Python-ideas] PEP 484 (Type Hints) -- first draft round
by Martin Teichmann Jan. 19, 2015

Jan. 19, 2015

Hi everybody, I'm writing something like remote procedure calls, so type hinting would be very interesting to me - I could send out the function parameter types to the remote side, which could already check the type of the parameters before even sending out a request. I would however be interested in even more detailed information. Like the range in which a number should lie - so giving a maximum and a minimum value for an int. Would it be possible with a PEP 484 system to add information like that? For example by inheriting from int? Greetings Martin Teichmann

2 1

Fwd: Way to check for floating point "closeness"?
by Chris Barker Jan. 19, 2015

Jan. 19, 2015

oops, forgot ot reply-all ---------- Forwarded message ---------- From: Chris Barker <chris.barker(a)noaa.gov> Date: Sat, Jan 17, 2015 at 8:38 PM Subject: Re: [Python-ideas] Way to check for floating point "closeness"? To: Terry Reedy <tjreedy(a)udel.edu> On Fri, Jan 16, 2015 at 8:09 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: > As near as I can tell, > assertAlmostEqual(first, second, places=7, msg=None, delta=None) > does one of two possible absolute difference checks > (round(first, places) - round(second, places)) == 0.0 > abs(first - second) < = delta > > There has been discussion of making it more complicated, but I remember > that being rejected because other tests require more thought and can be > implemented with the above anyway. > anything could be implemented with a simple absolute tolerance method, and for that matter, that is simple enough that there's not much point in having a built in function for it.anted (and a bit harder to write yourself) > > assertAlmostEqual((a-b)/d, 0, delta = tol) > where d is a, b, and (a+b)/2 as one thinks is appropriate. > while yopu're at it, why not jsut write your own assertion: assert (a-b)/b <= tol that function buys you nothing but potential confusion. > The discussion on the thread seems mostly divorced from the multiple use > cases. What do each of a and b represent? Different numbers? or > successive approximations of the same number? Are they theoretical 'exact' > numbers, approximations of theoretical numbers, or calculations from > measurements with error? If the latter, how big is the error? And why are > we asking anyway? We are usually asking 'close enough' for some purpose, > but purposes differ. > yes, they sure do -- but anything in the standard library would be for general use, where the details don't matter too much -- if you are doing something really specific, write your own test. > (Someone claimed that 'nothing is close to zero'. This is nonsensical > both in applied math and everyday life.) I'm pretty sure someone (more than one of use) asserted that "nothing is *relatively* close to zero -- very different. And indeed, that is still a primary stumbling block (at least for me) to putting a relative tolerance function into the stdlib: it will work fine in most cases, and be easy to understand and reason about, but it will not work if one of the input values is zero, and casual users may get tripped up by that. But at this point, i think that just needs note in the docs -- after all, they are likely to get tripped up by that if they write the code themselves anyway. And I really wanted a way to have a default behavior that would do a reasonable transition to an absolute tolerance near zero, but I no longer thing that's possible. (numpy's implimentaion kind of does that, but it is really wrong for small numbers, and if you made the default min_tolerance the smallest possible representable number, it really wouldn't be useful. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

4 4

Extending traceback to (optionally) format and show locals.
by Robert Collins Jan. 18, 2015

Jan. 18, 2015

For context please see http://bugs.python.org/issue22937 and http://bugs.python.org/issue22936. I have two questions I'm hoping to get answered through this thread: - does the change in question need a PEP? Antoine seemed to think it didn't, as long as it was opt-in (via the unittest CLI etc) - Is my implementation approach sound (for traceback, unittest I think I have covered :))? Implementation wise, I think its useful to work in the current traceback module layout - that is to alter extract_stack to (optionally) include rendered data about locals and then look for that and format it in format_list. I'm sure there is code out there that depends on the quadruple nature of extract_stack though, so I think we need to preserve that. Three strategies occured to me; one is to have parallel functions, one quadruple, one quintuple. A second one is to have the return value of extract_stack be a quintuple when a new keyword parameter include_locals is included. Lastly, and this is my preferred one, if we return a tuple subclass with an attribute containing a dict with the rendered data on the locals; this can be present but None, or even just absent when extract_stack was not asked to include locals. The last option is my preferred one because the other two both imply having a data structure which is likely to break existing code - and while you'd have to opt into having them it seems likely to require a systematic set of upgrades vs having an optional attribute that can be looked up. So - thoughts? -Rob -- Robert Collins <rbtcollins(a)hp.com> Distinguished Technologist HP Converged Cloud

4 7

Way to check for floating point "closeness"?
by Chris Barker Jan. 18, 2015

Jan. 18, 2015

Now that we're talking about floating point conveniences (math.nan, linspace): What about putting an almost_equal(x,y,tol=1e14) (or close(), or...) in the math module. AFAICT, in the standard library, there is only: unittest.TestCase.assertAlmostEqual but it: A) is buried in the unittest.TestCase class B) is an assertion, so you can't use it as a general test (easily) C) uses number of decimal digits or an absolute delta, but does not provide a significant figures comparison, which is most likely what's wanted (and a bit harder to write yourself) numpy provides allclose() (and isclose() ), which is pretty much what I'm suggesting. Anyone else think this would be a good idea to add to the stdlib? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

14 65

Better comand line version of python -c
by Russell Stewart Jan. 17, 2015

Jan. 17, 2015

I am the original dev for pypi.python.org/pypi/pythonpy, which offers much of the same functionality as python -c, but in a more convenient form. I'd be really interested in figuring out whether the core python tools could support many of the use cases that pythonpy covers, so that users wouldn't have to install it as a separate tool. I don't have a concrete idea of what it would look like, but many of my users have said they would much prefer an officially supported tool. Perhaps someone on this mailing list can provide some insight into the available options. Best, Russell

7 16

Float range class
by Todd Jan. 16, 2015

Jan. 16, 2015

Currently, the range class is limited to integers. However, in many applications, especially science and mathematics, ranges of float values are the norm. The current approaches for float ranges all have significant limitations. numpy.arange pre-allocates the values and doesn't use python floats, both of which affect performance. List comprehensions also have to be pre-allocated. Generators and values created in the body of a loop cannot be indexed or re-used and are much more verbose and harder to read. So it would be nice to have a float equivalent of the existing range class. Assuming such a class is worthwhile, I see three possible ways to handle float ranges, each with its own strengths and weaknesses. I am not sure which, if any, is preferable. The first is to extend the existing range class so it can support floats or to use duck-typing to support any class that has the necessary methods. However, I would be worried about making such a fundamental change to such a core class, and either approach could hurt performance. The second approach is to create a new class that handles floating-point ranges (perhaps called "frange") and/or a new class that handles duck-typed ranges (perhaps called "drange"). However, there isn't really a good place right now to put these as far as I can see. The third approach is to create a new module for various range classes. For example there could be a float range, a datetime range, a decimal range, a duck-typed range, an abstract base class for making new range classes, etc. However, this is a lot more work (although it wouldn't need to all be done at one time).

15 68

Re: [Python-ideas] Way to check for floating point "closeness"?
by Chris Barker Jan. 15, 2015

Jan. 15, 2015

On Wed, Jan 14, 2015 at 4:05 PM, Ron Adam <ron3200(a)gmail.com> wrote: > > Did you mean to take this off line? > no I really hate mailing lists that don't default to reply to the list -- drives me crazy... Bringing it back on list. If I'm checking the tolerance of a resistor, I would measure it's > resistance and calculate that against it's rated value. > > abs(rated-resistance - actual_resistance) / rated_resistance < .05 > > If they are equal, then I get 0.0. If it's 0, I get 1.0, or 100%. > well, I suspect that you never need to check a resistor that is rated for zero ohms. and if you get one that measures out to zero ohms, it probably is 100% error, or, in any case not "close" enough. so that's a particular use case, and I think my idea for a zero_tolerance, which is this case you'd set to zero, would support that. But the goal here is a method that will work most of the time, without a priory knowledge of how large the inputs are likely to be. If you know that, then you can use an absolute tolerance. You might get that by your computation above, but you could pass that in to a "close" function -- or not bother to write a close function, 'cause that's easy anyway. I would never be comparing a resistor to a rating of 0, and expect any > reasonable answer. Can you think of a real case which this come up? I > think it's in the realm of just don't do that. > Not in that case, of course, no. But in the general case of checking whether a computation produces about the same answer as expected (or as it did before you refactored the code), then zero mught cro up. But you have a point - maybe we could have a is_close function with a nice warning in the docs "don't expect this to work with zeros", and still have somethign useful. Would raising a ValueError on zero input be too pedantic? > It might be a case where you need more than two values. You just can't > assume a relative size with only two numbers. > the assumption is relative to the size of the input numbers -- which is mostly fine, but another way to deal with zero is to (optional) pass in a "relative to this" parameter -- but that essentially reverts to absolute tolerance anyway. Hmm -- new thought -- zero_tolerance can be the Minimum value that you use for the relative tolerance comparison -- that may be easy and at least give a continuous result... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

1 0

Re: [Python-ideas] Way to check for floating point "closeness"?
by Guido van Rossum Jan. 13, 2015

Jan. 13, 2015

But should probably use complex abs(). Adding it to cmath makes sense (if adding it to math happens). On Mon, Jan 12, 2015 at 2:39 PM, Chris Barker <chris.barker(a)noaa.gov> wrote: > On Mon, Jan 12, 2015 at 2:33 PM, Guido van Rossum <guido(a)python.org> > wrote: > >> I'm guessing this is also something that can go into math. >> > > makes sense to me. > > >> (However, what about complex?) >> > > first blush: > > is_close(x.real) and is_close(x.imag) > > -Chris > > > > >> On Mon, Jan 12, 2015 at 2:23 PM, Chris Barker <chris.barker(a)noaa.gov> >> wrote: >> >>> On Mon, Jan 12, 2015 at 12:04 PM, Guido van Rossum <guido(a)python.org> >>> wrote: >>> >>>> So is 1e-100 close to 1e-50 with the default tolerance? What about >>>> 1e+100 and (1e+100 plus one ulp)? >>>> >>> >>> sorry I should have not specified a specific default, and/or explained >>> more what I think it should mean. >>> >>> But I thought the first question was "might this be a good idea for the >>> standard library" -- and only if so, then we can work out how to do it. >>> >>> But anyway, the while point is that it would be some version "relative >>> error", NOT an absolute tolerance -- that is pretty easy to write. >>> >>> See Nathaniel's note for the too many options already in numpy. >>> >>> Nathaniel Smith wrote: >>> >>> Unfortunately this opens a tremendous can of worms. >>> >>> >>> Well, yes, but something generally useful for many cases would still be >>> nice. >>> >>> Boost has thought about this a lot and advocates a slightly different >>>> definition (actually, two slightly different definitions) from any of >>>> the above: >>>> >>>> http://www.boost.org/doc/libs/1_34_0/libs/test/doc/components/test_tools/fl… >>>> >>> >>> >>> It looks like they start with two, but end up with >>> >>> "the implementation is using modified version of the equations (1) and >>> (2) where all underflow, overflow conditions could be guarded safely" >>> >>> That looks good to me, and the origins in Knuth are a good sign. >>> >>> -Chris >>> >>> >>> -- >>> >>> Christopher Barker, Ph.D. >>> Oceanographer >>> >>> Emergency Response Division >>> NOAA/NOS/OR&R (206) 526-6959 voice >>> 7600 Sand Point Way NE (206) 526-6329 fax >>> Seattle, WA 98115 (206) 526-6317 main reception >>> >>> Chris.Barker(a)noaa.gov >>> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker(a)noaa.gov > -- --Guido van Rossum (python.org/~guido)

8 13

math.inf and math.nan constants
by Todd Jan. 13, 2015

Jan. 13, 2015

The current way to get infinite and nan floats are to do float("inf") and float("nan"), respectively. For many applications, this is sufficient. However, for scientific and mathematical computing, using inf and nan values is very common, and the current approach is very verbose. So for those applications, I think it would be useful if the math standard library module provided "math.nan" and "math.inf", which would return the same thing as float("nan") and float("inf"), respectively.

25 75

Need help converting HTML doc to ReST
by Guido van Rossum Jan. 10, 2015

Jan. 10, 2015

I'd like to convert my document "The Theory of TypeHinting" to ReST so I can include it in PEP 483. Can someone help me with the conversion? The source is https://quip.com/r69HA9GhGa7J and the destination is http://legacy.python.org/dev/peps/pep-0483/ (or, more correctly, https://hg.python.org/peps/file/7cbb166b30fd/pep-0483.txt). Thanks!! -- --Guido van Rossum (python.org/~guido)

4 12