As discussed on python-dev, I am creating omnibus issues from the lists of crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues that I found while developing Python 3.5.2 support for PyPy.  These occur with CPython 3.5.2 but most of them are likely still here in trunk.

This is the issue containing the "strange behaviors" and some of them, or possibly most, will turn out to be my own feelings only and not python-dev's, which is fine by me.

(S1) ceval.c: GET_AITER: calls _PyCoro_GetAwaitableIter(), which might
  get an exception from calling the user-defined __await__() or checking
  what it returns; such an exception is completely eaten.

(S2) argument clinic turns the "bool" specifier into
  PyObject_IsTrue(), accepting any argument whatsoever.  This can easily
  get very confusing for the user, e.g. after messing up the number of
  arguments.  For example: os.symlink("/path1", "/path2", "/path3")
  doesn't fail, it just considers the 3rd argument as some true value.

(S3) hash({}.values()) works (but hash({}.keys()) correctly gives
  TypeError).  That's a bit confusing and, as far as I can tell, always
  pointless.  Also, related: d.keys()==d.keys() but
  d.values()!=d.values().

(S4) if you write ``from .a import b`` inside the Python prompt, or in
  a module not in any package, then you get a SystemError(!) with an
  error message that is unlikely to help newcomers.

(S5) pep 475: unclear why 'os.fchmod(fd)' retries automatically when
  it gets EINTR but the otherwise-equivalent 'os.chmod(fd)' does not.
  (The documentation says they are fully equivalent, so someone is
  wrong.)

(S4) was fixed in 3.6 (issue18018). But the fix was not applied to 3.5.

(S2) is related not to Argument Clinic itself, but to the 'p' format unit added in 3.3 (issue14705).

Victor & Yury for S1.

I'll take a look at s1 later tonight

+larry for (S2) regarding argument clinic's treatment of bool.

attaching a proposed fix for (S5).  os.chmod should have the same EINTR retry treatment as everything else.  That it does not appears to have been an oversight.

I assert that Argument Clinic's / PyArg_ParseTuple's handling of bool is correct.

* Python has a well-established concept of "truth":

  https://docs.python.org/3/library/stdtypes.html#truth-value-testing

  The C equivalent is, indeed, PyObject_IsTrue().

* When we added the 'p' format unit to PyArg_ParseTuple, I originally had a second format unit 'P' that would only accept boolean literal values.  But nobody could come up with a use case for it.  So we removed it.  See #14705 for the discussion.

* Existing code often does something half-assed here.  eg. stat_float_times uses the PyArg_ParseTuple "i" format unit for its boolean parameter, which accepts booleans and integers but not strings.  This is strange and inconsistent.  (Of course, you can do this with Argument Clinic, just specify the parameter as an int.  But, yuck.)

If you have a counter-proposal for how it should behave, I'd be interested to hear it.  But as far as I'm concerned, the two legitimate answers for "how to handle integers" are either a) accept literally only True and False--an approach which nobody has a use case for--or b) PyObject_IsTrue(), which behaves exactly like Python.

I created an issue to track S1: http://bugs.python.org/issue28893

(S5) gregory: actually there is also fchown/chown in the same situation.

(S3) is a side effect of implementing __eq__ in dict_keys and dict_items. Since __eq__ is not implemented in dict_values, __hash__ is inherited from object.

(S6) 'xxx' % b'foo' == 'xxx'
     b'xxx' % b'foo' raises TypeError

The first case is because PyMapping_Check() is true on b'foo', so it works like 'xxx' % {...}, which always just returns 'xxx'.  The second case is because _PyBytes_Format() contains more special cases, for bytes and bytearray, which are not present in PyUnicode_Format().

Armin, it would help if you report all cases as separate issues. Some of them are already resolved, some can be closed with "won't fix" resolution, others need special discussions. This issue can be left as a metaissue.

> Armin, it would help if you report all cases as separate issues.

I asked on python-dev before creating these three issues, and got the opposite answer.  If you decide it was a bad idea after all, I will open separate issues in the future.

I think if you're up for doing individual issues, Armin, that's preferred. But if it's too much work we will take it all in this single issue instead of risking the loss of the information. And if you want to use this issue as a meta one to track everything you report that's obviously fine.