<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Serhiy Storchaka ran into a ticklish problem with Argument Clinic
and inspect.Signature information for builtins.<br>
<br>
Consider pattern_match() in Modules/_sre.c. This implements the
match method on a pattern object; in other words,
re.compile().match(). The third parameter, endpos, defaults to
PY_SSIZE_T_MAX in C. What should inspect.Signature() report as the
default value for endpos? And how should it get that value?<br>
<br>
Before you answer, consider how inspect.Signature works for
builtins. Argument Clinic hides a signature for the function as the
first line of the docstring; the initialization of the code object
strips that off and puts it in a separate member called
__text_signature__. inspect.Signature pulls that out string and
passes it in to ast.parse, then walks the tree it gets back, pulls
out the arguments and their default values and goes on from there.<br>
<br>
We can't turn PY_SSIZE_T_MAX into an integer at Argument Clinic
preprocessing time, because this could be done on a completely
different architecture than the computer where Python is running.
We can't stuff it in at compile time because the macro could devolve
into an arbitrary expression (with | or + or something) so while
that might work here that's not a general solution. We can't do it
at runtime becuase the docstring is a static string.<br>
<br>
The best solution seems to be: allow simple symbolic constants as
default values. For example, for endpos we'd use sys.maxsize. The
code in inspect.Signature would have to support getting an Attribute
node, and look up the first field ("sys" in this case) in
sys.modules. You could then specify PY_SSIZE_T_MAX as the default
for generated C code, and life would be a dream.<br>
<br>
I've posted a prototype patch on the tracker:<br>
<blockquote>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://bugs.python.org/issue20144">http://bugs.python.org/issue20144</a></blockquote>
It need tests and such but I think the basic technology is fine.<br>
<br>
<br>
The thing is, I feel like this is borderline between bug fix and new
feature. But without adding this, we would make a lot of the
Argument Clinic conversions pretty messy. So I want to check it
in. I just don't want to piss everybody off in the process.<br>
<br>
Can you guys live with this?<br>
<br>
<br>
<br>
/arry<br>
<br>
p.s.<br>
<br>
For what it's worth, the documentation for match() dodges this
problem by outright lying. It claims that the prototype for the
function is:<br>
<br>
match(string[, pos[, endpos]])<br>
<br>
which is a lie. pattern_match() parses its arguments by calling
PyArg_ParseTupleAndKeywords() with a format string of "O|nn". Which
means, for example, you could call:<br>
<br>
match("abc", endpos=5)<br>
<br>
The documentation suggests this is invalid but it works fine. So my
feeling is, this is a legitimate problem, and those who came before
me swept it under the rug.<br>
</body>
</html>