Repository navigation
Derby: Convert the _sre module to use Argument Clinic #64347
Description
Activity
Here is preliminary patch which converts the _sre module to use Argument Clinic. 22 functions are converted.
There are thre problems:
- addedextension-modulesC modules in the Modules dirC modules in the Modules dirtype-featureA feature request or enhancementA feature request or enhancement
on Jan 6, 2014 Obviously we can't live with manually editing the output from Argument Clinic, so I'll get you a fix for O! today.
Maybe we could use a better literal value? Like 2**31 - 1?
I don't understand the pydoc thing. Can you elaborate?
Maybe we could use a better literal value? Like 2**31 - 1?
This only a placeholder. It will be replaced by named constant in final patch.
2**31 - 1 is not better here than any other arbitrary value.I don't understand the pydoc thing. Can you elaborate?
Pydoc for _sre.compile doesn't output signature and docstring, but only
mentioned above line. There is similar issue in audioop module (bpo-20133)
for the ratecv function.Can you refresh the patch? I think all the problems you cited are fixed, and also the comments Argument Clinic uses were all changed. I'll review when you have a fresh patch.
- changed the title
[-]Convert the _sre module to use Argument Clinic[/-][+]Derby: Convert the _sre module to use Argument Clinic[/+]on Jan 7, 2014 Here is refreshed patch.
Serhiy: Assigning to you because you wrote a patch; if you don't want the issue, sorry, please undo it.
Now all methods except Match.group() (which needs *args) use Argument Clinic.
Most important change is that first parameters of some Pattern methods are renamed from "pattern" or "source" to "string". This was obvious bug (bpo-20283). "string" conforms to the documentation and to the name of the Match.string attribute.
Here is updated patch.
Synchronized with the tip again.
9 remaining items
Sorry--you can simply remove that line, it's no longer needed.
Does your patch just move type definition to the end of the file? I think this is only the way to make happy GCC and MS compiler.
Strange that no IRC bot complained about compilation failure.
Yes, it moves the type declaration to the bottom of the file, and adds forward static declarations for the types to the top of the file.
AFAIK the only buildbot with a nearly-up-to-date MSVC is still marked as unstable (http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x). I keep meaning to get it promoted, but haven't quite gotten around to it yet...
Oh, this is only happening on the *beta* compiler? In that case, I genuinely suggest you file a bug.
We can still check in the workaround, but I really do think MSVS's behavior is wrong here. (Why is it only for forward static declarations of arrays of unspecified size?)
Then the patch LGTM. It is easier to make these changes by hand than make a review for moved code on Rietveld.
I'm not sure, but may be forward static declarations of arrays of unspecified size is C99-ism?
It fails on VC10, 11, 12 and 14, so I doubt it's going to be changed. That said, it looks like the non-static forward definition may be some sort of extension, since it causes a redefinition error (mismatched storage class) on all versions when using /Za to disable extensions.
It could be a C99 feature ("tentative definitions" I think), as Serhiy suggests, but if so then it's very likely not going to be added between the RC (released last week) and final versions of the compiler.
According to http://compgroups.net/comp.std.c/why-does-the-standard-prohibit-static-int-a/2569729, it's invalid in both C89 and C99, but some compilers accept it as an extension.
IMO we should avoid relying on compiler extensions, at least in the code files that are supposed to be portable.
I agree. I looked it up in the C99 standard. 6.9.2.2 says:
"If the declaration of an identifier for an object is a tentative definition and has internal linkage, the declared type shall not be an incomplete type."
And if you'd hurry up and bless my patch for Modules/_tkinter.c in bug bpo-20168, I'd check this fix in ;-)
(sorry, 6.9.2.3)
Sorry, wasn't watching the other issue. :)
New changeset 7a76c462c7f6 by Larry Hastings in branch 'default':
Fix Windows build breakage from checkins on Issues bpo-20148 and bpo-20168.
https://hg.python.org/cpython/rev/7a76c462c7f6Steve, please close this issue when you've confirmed it's now building correctly on Windows.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: