Named enums with 'Flags' in the name use `enum.IntFlag`, all other enums
use `enum.IntEnum`. We have to bring the enum members into the containing
scope to match the original behaviour. Further, since these enums are typing
information only, and not actually in wx proper, we prevent them from appearing
to leak the the user by marking as non-exported (prepend '_' to the name), then
make a TypeAlias to the enum or an int. This way type signatures still claim
to accept integers as appropriate.
I like this solution best, because we preserved the information about which
enum members are expected for method/function parameters, while not leaking
non-existant classes out of the type-stubs, and not complaining about using
integers.
There's still a few undefined but referenced enums (ex:
richtext.TextAttrDimensionFlags). These are most likely a union of some of
the other flags/enum types already defined, but the work to pull that information
from the C++ source is probably too much.
Use the more generic type rather than a literal type. Before, a type-checker
would infer an int defined this way as `Literal[0]` vs the more correctly
generic `int` for example.
By directly referencing their setter and getter methods,
and due to the typing work already done for methods, we now have
type information attached to properties.
There are a few edge cases of setters/getters not having the proper
number of arguments for a getter(0) or setter(1), but most cases are
handled. The incorrect number of arguments may be missing default
arguments from what the extraction code figures out from the C++ code?
With the work from the previous commits, it's as simple as
no longer lopping off the args string at the '->' marker.
(And one minor fixup to the makePyArgsString code).
These will be changing to annotation statements, so FixWxPrefix needs to
be able to detect this still (proper thing to look for in this case is
`ast.AnnAssign`).
One unexpected type of '...' required adding a new transformation
that modifies both the name and the type to just '*args', so added
a preferred method `FixWxPrefix.parseNameAndType` which processes
both strings at once.
Also fixes cleanType to recursively call cleanType on sub-types
(was improperly calling cleanName).
With this, method and function signatures now have type annotations
which are mostly correct (100% correct in the "it compiles" sense).
Thankfully, the incorrect type-hints don't cause errors due to using
stringized annotations (by importing annotations from __future__).
Importantly, the overload signatures now have been fully sanitized.
Before this, there was one instance of a variable named `is`, and another
named `/Transfer/` - both invalid identifiers. I stopped looking after
those. Since theses signatures are valid Python code, this opens up the
opportunity to use `typing.overload` to fully expose those.
Edge-cases in type-hints will be addressed in later commits.
Leverages the `writeSection` machinery, with a tweak to specify to add a
new section to the beginning of a file, after the header. This ensures
the required imports gets updated (and also only imported once per file)
if new imports are needed for type-hints. Hint: there's a few more to come.
This allows for building `FixWxPrefix.cleanType` on top of it, for use
in processing type-hint strings in the future. It also exposes the method
to `FunctionDef.makePyArgString` in the future, which has easier access to
the types of arguments and returns. And possibly further in the future,
other `***Def` classes can make use of it (constant definitions, etc).
The line-wrapping causes issues once the python signatures become too long,
as textwrap isn't smart enough to split the lines on valid continuation points
for code. I had one instance of splitting a line in the middle of a string ->
SyntaxError on next run of etg due to the generated PYI file having an
unterminated string.
Specificially, disable splitting for lines that start (ignoring spaces) with
a specific string - in this case any line starting with the name of the
function or method this is a docstring for.
When I added this code in 5e190eb, it was intended to be used in all cases
except for constructors and destructors. Instead, it was used in all cases.
This broke the wxRegion constructor and possibly other things.
Fixes#1878.
Parameter names should not be mangled, as this causes mismatches between
extractor and xml data:
```
SEVERE: Incompatibility between function/method signature and list of parameters in `wx.html.HtmlHelpWindow.__init__`:
The parameter `WindowID` appears in the method signature but could not be found in the parameter list.
==> Function/Method signature from `extractors`: __init__(parent, WindowID, pos=wx.DefaultPosition, size=wx.DefaultSize, style=wx.TAB_TRAVERSAL|wx.BORDER_NONE, helpStyle=HF_DEFAULT_STYLE, data=None)
==> Parameter list from wxWidgets XML items: ['parent', 'wxWindowID', 'pos', 'size', 'style', 'helpStyle', 'data']
```
```
==> Function/Method signature from `extractors`: SetAssertMode(AppAssertMode)
==> Parameter list from wxWidgets XML items: ['wxAppAssertMode']
```
In the implementation of wx.CustomData.SetData, we need to check the
sipSelfWasArg variable to determine whether to call the parent class
implementation of SetData. To do this, we switched to using addCppMethod_sip
which allows us to access the sipSelfWasArg variable. The sip generator
stuff for CppMethod_sip needed some additions to match the behavior of
CppMethod.
statements with the safer "with open(filename) as fid:" blocks.
Also removed unnecessary "try: ... finally: pass" statements
and refactored code from img2py function into _write_image and _replace_non_alphanumeric_with_underscore
Fixes#1574
