Re: [Python-Dev] [Python-checkins] peps: Apply Chris's changes, including an acceptance mark
Chris, Could you please add a link to the email where the PEP was accepted? Thanks, Yury On 2015-05-16 10:12 PM, chris.angelico wrote: https://hg.python.org/peps/rev/f876276ce076 changeset: 5854:f876276ce076 user:Chris Angelico date:Sun May 17 12:12:19 2015 +1000 summary: Apply Chris's changes, including an acceptance mark files: pep-0485.txt | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/pep-0485.txt b/pep-0485.txt --- a/pep-0485.txt +++ b/pep-0485.txt @@ -3,7 +3,7 @@ Version: $Revision$ Last-Modified: $Date$ Author: Christopher Barker -Status: Draft +Status: Accepted Type: Standards Track Content-Type: text/x-rst Created: 20-Jan-2015 @@ -391,9 +391,9 @@ The most common use case is expected to be small tolerances -- on order of the default 1e-9. However there may be use cases where a user wants to know if two fairly disparate values are within a particular range of each other: "is a -within 200% (rel_tol = 2.0) of b? In this case, the string test would never +within 200% (rel_tol = 2.0) of b? In this case, the strong test would never indicate that two values are within that range of each other if one of them is -zero. The strong case, however would use the larger (non-zero) value for the +zero. The weak case, however would use the larger (non-zero) value for the test, and thus return true if one value is zero. For example: is 0 within 200% of 10? 200% of ten is 20, so the range within 200% of ten is -10 to +30. Zero falls within that range, so it will return True. ___ Python-checkins mailing list python-check...@python.org https://mail.python.org/mailman/listinfo/python-checkins ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Apply Chris's changes, including an acceptance mark
On Mon, May 18, 2015 at 1:04 AM, Yury Selivanov wrote: > Chris, > > Could you please add a link to the email where the PEP was accepted? Sure. A Resolution: header is the right way to do this? Done. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (merge 3.4 -> default): Added tests for more builtin types.
On 5/17/2015 1:57 AM, Serhiy Storchaka wrote: On 17.05.15 02:44, Ned Deily wrote: In article <20150516183940.21146.77...@psf.io>, serhiy.storchaka wrote: https://hg.python.org/cpython/rev/7b350f712c0e changeset: 96099:7b350f712c0e parent: 96096:f0c94892ac31 parent: 96098:955dffec3d94 user:Serhiy Storchaka date:Sat May 16 21:35:56 2015 +0300 summary: Added tests for more builtin types. Made test_pprint discoverable. files: Lib/test/test_pprint.py | 17 - 1 files changed, 8 insertions(+), 9 deletions(-) == ERROR: test_coverage (test.test_trace.TestCoverage) -- Traceback (most recent call last): File "/py/dev/3x/root/uxd/lib/python3.5/test/test_trace.py", line 312, in test_coverage self._coverage(tracer) File "/py/dev/3x/root/uxd/lib/python3.5/test/test_trace.py", line 305, in _coverage tracer.run(cmd) File "/py/dev/3x/root/uxd/lib/python3.5/trace.py", line 500, in run self.runctx(cmd, dict, dict) File "/py/dev/3x/root/uxd/lib/python3.5/trace.py", line 508, in runctx exec(cmd, globals, locals) File "", line 1, in AttributeError: module 'test.test_pprint' has no attribute 'test_main' == ERROR: test_coverage_ignore (test.test_trace.TestCoverage) -- Traceback (most recent call last): File "/py/dev/3x/root/uxd/lib/python3.5/test/test_trace.py", line 327, in test_coverage_ignore self._coverage(tracer) File "/py/dev/3x/root/uxd/lib/python3.5/test/test_trace.py", line 305, in _coverage tracer.run(cmd) File "/py/dev/3x/root/uxd/lib/python3.5/trace.py", line 500, in run self.runctx(cmd, dict, dict) File "/py/dev/3x/root/uxd/lib/python3.5/trace.py", line 508, in runctx exec(cmd, globals, locals) File "", line 1, in AttributeError: module 'test.test_pprint' has no attribute 'test_main' Also breaks 3.4. Thank you Ned. Opened issue24215 for this because just restoring test_main perhaps not the best way. test_trace can be easily modified to use test_pprint as revised. See issue. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-versus-CPython question for __mul__ dispatch
On Sat, May 16, 2015 at 1:31 AM, Nick Coghlan wrote: > On 16 May 2015 at 07:35, Nathaniel Smith wrote: >> On Thu, May 14, 2015 at 11:53 PM, Nathaniel Smith wrote: >>> On Thu, May 14, 2015 at 9:29 PM, Guido van Rossum wrote: I expect you can make something that behaves like list by defining __mul__ and __rmul__ and returning NotImplemented. >>> >>> Hmm, it's fairly tricky, and part of the trick is that you can never >>> return NotImplemented (because you have to pretty much take over and >>> entirely replace the normal dispatch rules inside __mul__ and >>> __rmul__), but see attached for something I think should work. >>> >>> So I guess this is just how Python's list, tuple, etc. work, and PyPy >>> and friends need to match... >> >> For the record, it looks like PyPy does already have a hack to >> implement this -- they do it by having a hidden flag on the built-in >> sequence types which the implementations of '*' and '+' check for, and >> if it's found it triggers a different rule for dispatching to the >> __op__ methods: >> >> https://bitbucket.org/pypy/pypy/src/a1a494787f4112e42f50c6583e0fea18db3fb4fa/pypy/objspace/descroperation.py?at=default#cl-692 > > Oh, that's rather annoying that the PyPy team implemented bug-for-bug > compatibility there, and didn't follow up on the operand precedence > bug report to say that they had done so. We also hadn't previously > been made aware that NumPy is relying on this operand precedence bug > to implement publicly documented API behaviour, so fixing it *would* > break end user code :( I don't think any of us were aware of it either :-). It is a fairly obscure case -- it only comes up specifically if you have a single-element integer array that you are trying to multiply by a list that you expect to be auto-coerced to an array. If Python semantics were such that this became impossible to handle correctly then we would survive. (We've certainly survived worse, e.g. arr[array_of_indices] += 1 silently gives the wrong/unexpected result when array_of_indices has duplicate entries, and this bites people constantly. Unfortunately I can't see any reasonable way to fix this within Python's semantics, so... oh well.) But yeah, given that we're at a point where list dispatch actually has worked this way forever and across multiple interpreter implementations, I think it's de facto going to end up part of the language specification unless someone does something pretty quick... > I guess that means someone in the numeric community will need to write > a PEP to make this "try the other operand first" "feature" part of the > language specification, so that other interpreters can implement it up > front, rather than all having to come up with their own independent > custom hacks just to make NumPy work. I'll make a note... > P.S. It would also be nice if someone could take on the PEP for a > Python level buffer API for 3.6: http://bugs.python.org/issue13797 At a guess, if you want to find people who have this itch strong enough to try scratching it, then probably numpy users are actually not your best bet, b/c if you have numpy then you already have workarounds. In particular, numpy still supports a legacy Python level buffer export API: http://docs.scipy.org/doc/numpy/reference/arrays.interface.html#python-side So if all you want is to hand a buffer to numpy (rather than to an arbitrary PEP 3118 consumer) then this works fine, and if you do need an arbitrary PEP 3118 consumer then you can use numpy as an adaptor (use __array_interface__ to convert your object to ndarray -> ndarray supports the PEP 3118 API). -n -- Nathaniel J. Smith -- http://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 484 wishes
Looking at PEP 484, I came up with two use cases that I felt were not catered for: 1. Specifying that a parameter should be a subclass of another (example: Type[dict] would match dict or OrderedDict; plain "Type" would equal "type" from builtins) 2. Specifying that a callable should take at least the specified arguments but would not be limited to them: Callable[[str, int, ...], Any] Case #2 works already (Callable[[str, int], Any] if the unspecified arguments are optional, but not if they're mandatory. Any thoughts? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 485 isclose() implementation review requested
Folks,
After a huge delay, I finally found the time to implement the PEP 485
isclose() function, in C. I tihnk it's time for some review. I appologise
for the fact that I have little experience with C, and haven't used the raw
C API for years, but it's a pretty simple function, and there's lots of
code to copy, so I think it's in OK shape. I hav not yet integrated it with
the cPyton source code -- it belongs in mathmodule.c, but I found it easier
to put it in a separate module while figuring it out.
You can find the code in the same gitHub repo as the draft PEP and python
prototyping code:
https://github.com/PythonCHB/close_pep
the code is in:
is_close_module.c
There is a test module in:
test_isclose_c.py
and it can be built with:
python3 setup.py build_ext --inplace
Let me know if I should restructure it or put it anywhere else before it
gets reviewed but in the meantime, i welcome any feedback.
Thanks,
-Chris
A few questions I have off the bat:
C-API (and plain C) questions:
=
* Is there a better way to create a False or True than::
PyBool_FromLong(0) and PyBool_FromLong(1)
* Style question: should I put brackets in an if clause that has only one
line?::
if (some_check) {
just_this_one_expression
}
* I can't find docs for PyDoc_STRVAR: but it looks like it should use it --
how?
* I'm getting a warning in my PyMethodDef clause::
static PyMethodDef IsCloseMethods[] = {
{"isclose", isclose_c, METH_VARARGS | METH_KEYWORDS,
"determine if two floating point numbers are close"},
{NULL, NULL, 0, NULL}/* Sentinel */
};
is_close_module.c:61:17: warning: incompatible pointer types initializing
'PyCFunction' (aka 'PyObject *(*)(PyObject *, PyObject *)') with an
expression of type 'PyObject *(PyObject *, PyObject *, PyObject *)'
[-Wincompatible-pointer-types]
{"isclose", isclose_c, METH_VARARGS | METH_KEYWORDS,
but it seems to be working -- and I've copied, as well as I can, the
examples.
Functionality Questions:
* What do do with other numeric types?
- Integers cast fine...
- Decimal and Fraction cast fine, too -- but precision is presumably
lost.
- Complex ? -- add it to cmath?
* It's raising an Exception for negative tolerances: which don't make sense,
but don't really cause harm either (fabs() is used anyway). I can't say I
recall why I did that
for the python prototype, but I reproduced in the C version. Should I?
* What about zero tolerance? should equal values still be considered close?
They are now, and tests reflect that.
--
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.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 485 isclose() implementation review requested
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-05-18 01:02, Chris Barker wrote:
> * Is there a better way to create a False or True than::
>
> PyBool_FromLong(0) and PyBool_FromLong(1)
You can use the macros Py_RETURN_TRUE and Py_RETURN_FALSE instead of
return PyBool_FromLong(0).
> * Style question: should I put brackets in an if clause that has
> only one line?::
>
> if (some_check) { just_this_one_expression }
I prefer the extra brackets because they make the code more explicit.
It's really a matter of taste.
> * I can't find docs for PyDoc_STRVAR: but it looks like it should
> use it -- how?
PyDoc_STRVAR(functionname_doc,
"isclose(foo) -> bool\n\
\n\
long doc string.");
> * I'm getting a warning in my PyMethodDef clause::
>
> static PyMethodDef IsCloseMethods[] = { {"isclose", isclose_c,
> METH_VARARGS | METH_KEYWORDS, "determine if two floating point
> numbers are close"}, {NULL, NULL, 0, NULL}/* Sentinel */
> };
You have to type cast the function pointer to a PyCFunction here:
(PyCFunction)isclose_c
The type cast is required for KEYWORD functions and NOARGS functions.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 wishes
On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm wrote: > Looking at PEP 484, I came up with two use cases that I felt were not > catered for: > >1. Specifying that a parameter should be a subclass of another >(example: Type[dict] would match dict or OrderedDict; plain "Type" would >equal "type" from builtins) > > I don't understand. What is "Type"? Can you work this out in a full example? This code is already okay: def foo(a: dict): ... foo(OrderedDict()) > >1. Specifying that a callable should take at least the specified >arguments but would not be limited to them: Callable[[str, int, ...], Any] > > Case #2 works already (Callable[[str, int], Any] if the unspecified > arguments are optional, but not if they're mandatory. Any thoughts? > For #2 we explicitly debated this and found that there aren't use cases known that are strong enough to need additional flexibility in the args of a callable. (How is the code calling the callable going to know what arguments are safe to pass?) If there really is a need we can address in a future revision. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
