[issue23935] Clean up Clinic's type expressions of buffers
Larry Hastings added the comment: While cleaning this up I noticed that es# and et# should both require nullable. Fixed that too. I sure hope it's all correct now! -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Roundup Robot added the comment: New changeset 4f74452a11e5 by Larry Hastings in branch 'default': Issue #23935: Argument Clinic's understanding of format units https://hg.python.org/cpython/rev/4f74452a11e5 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Serhiy Storchaka added the comment: Many people will see Argument Clinic syntax in declarations in C files. My recent patches (for _io, _ssl and _codecs modules) adds many types=. But I agree that there are many reasons to make this change. The patch LGTM. You can factorize it more if you like. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Serhiy Storchaka added the comment: Added few comments on Rietveld. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Larry Hastings added the comment: Latest patch, with another round of lovely comments from Serhiy. -- Added file: http://bugs.python.org/file39030/larry.clinic.buffer.conceptual.cleanup.4.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Larry Hastings added the comment:
In the case of namedtuple and Enum, the parameter represents a sequence of
strings--order is significant. With the 'types' parameter for converters, the
internal model was always meant to be a *set* of strings. The order was
explicitly *not* significant. So types=str robuffer and types=robuffer str
should be identical. Your harder to search in sources was already true.
Argument Clinic isn't something very many people will learn. Lots of people
will read the conversions, but few will ever write a conversion, and they won't
do it often and they'll forget the funny details. So we shouldn't make the API
quirky and succinct at the expense of readability. The best API will be one
that makes the code easier to read.
I think requiring types to be a set of strings makes it easier to read because
it makes the semantics obvious. If you see
types=str robuffer
you aren't sure if order is significant, but if you see
types={'str', 'robuffer'}
you are certain it is not.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23935
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Larry Hastings added the comment: New patch revision, including the new API change (the types argument to a constructor must now be a set of strings). -- Added file: http://bugs.python.org/file39001/larry.clinic.buffer.conceptual.cleanup.3.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Changes by Peter McCormick pe...@pdmccormick.com: -- nosy: +pdmccormick ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Serhiy Storchaka added the comment:
The new API change looks doubtful for me. It is more verbose. And less
readable. It makes harder to search in sources, because {'str', 'robuffer'} is
the same as {'robuffer', 'str'}. If Argument Clinic would a tool with
programmatic API, sets would make sense, but for now the main interface of
Argument Clinic is text inclusions in C files.
If you want to convert the types parameter into a set, is it possible to
continue to accept strings? Many user-friendly APIs accept either a sequence of
string names or a string containing space-separated names. For example
namedtuple, Enum.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23935
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Larry Hastings added the comment: Updated the patch a little, to make it enforce compatible types parameters. The previous patch had some functions that would permit passing in types='blah de blah' or other nonsense. -- Added file: http://bugs.python.org/file38948/larry.clinic.buffer.conceptual.cleanup.2.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
New submission from Larry Hastings: Clinic was previously pretty confused about what things accepted bytes, bytearray, buffer, robuffer, and rwbuffer. This is because the documentation itself was somewhat confusing. The documentation was recently cleaned up on these in trunk (including one final fix from me this morning). This patch cleans up Clinic's understanding of how the types map to the format units. My notes on how the format units map to types is copy pasted below. -- the documentation for format units is a little confused, and it is therefore confusing inside: getbuffer (buffer) y* s* z* uses PyObject_GetBuffer(arg, view, PyBUF_SIMPLE) requires PyBuffer_IsContiguous(view, 'C') doesn't check specifically for bytes objects handles bytes objects accepts bytesarray convertbuffer (robuffer) y y# s# z# handles read-only buffer object, all it really does is ensure it doesn't have a pb_releasebuffer, then call getbuffer() above so it doesn't accept bytesarray, *just because* doesn't accept bytes s z es es# requires writeable buffer (rwbuffer) w* actually checks / specifically handles bytes objects S actually checks / specifically handles bytearray objects Y actually checks / specifically handles bytes and bytearray objects c et et# -- assignee: larry components: Argument Clinic messages: 240660 nosy: larry, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: Clean up Clinic's type expressions of buffers type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23935] Clean up Clinic's type expressions of buffers
Larry Hastings added the comment: Huh. Why didn't it attach my patch? Here it is. -- Added file: http://bugs.python.org/file38933/larry.clinic.buffer.conceptual.cleanup.1.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
