diff options
author | Christian Tismer <tismer@stackless.com> | 2019-08-01 15:24:00 +0200 |
---|---|---|
committer | Christian Tismer <tismer@stackless.com> | 2019-08-07 15:19:34 +0200 |
commit | 87986cf77194b995785ae06e9eff07524b711dba (patch) | |
tree | c2af02dd852c62b9464adb72ffea0bed0a6af57a /sources/shiboken2/libshiboken/signature_doc.rst | |
parent | 21d948aa47dfe62b58286a31c729e76c9e3c13db (diff) |
Support Pointer Primitive Types by Arrays or Result Tuples
-- This change is part of the improved numpy support --
Most primitive types are handled in XML, but this was not reflected
by the signatures, error messages, doc strings and hinting stubs.
In order to enhance the information shown to be more correct,
the C++ parser part was rewritten for Python. It is written
closely to Python syntax, but keeps the existing information about
primitive types intact.
AbstractMetaType::NativePointerAsArrayPattern is now used to
mark a variable as an array. Heuristics are no longer used.
If a pointer variable is not marked as an array, the Python parser
generates a return value. If more than one value would be returned,
a result-tuple is generated.
Because we now have a deterministic categorization of types, the
"const" attribute is no more needed and the entries in mapping.py
are reduced.
A few missing <array/> markers were added.
The tool also now handles typing.List[] differently in arguments and
return types. While return types stay lists, they are for now changed
to typing.Sequence[] in argument lists.
A test was included.
These messages belong to the previous "deprecated functions" patch:
Further, QMatrixMxN.constData was removed from the typesystem
and replaced by a surrogate function that calls QMatrixMxN.data,
but also generates a warning.
The long forgotten generate_pyi.py was now published in the same
course.
Task-number: PYSIDE-795
Task-number: PYSIDE-951
Change-Id: Ia59fe4986919525a70ea7cc453c64cdf46e7fba0
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Diffstat (limited to 'sources/shiboken2/libshiboken/signature_doc.rst')
-rw-r--r-- | sources/shiboken2/libshiboken/signature_doc.rst | 10 |
1 files changed, 4 insertions, 6 deletions
diff --git a/sources/shiboken2/libshiboken/signature_doc.rst b/sources/shiboken2/libshiboken/signature_doc.rst index 9c42c5976..a984de4ce 100644 --- a/sources/shiboken2/libshiboken/signature_doc.rst +++ b/sources/shiboken2/libshiboken/signature_doc.rst @@ -73,8 +73,8 @@ It calls ``GetSignature_Function`` which returns the signature if it is found. Why this Code is Fast --------------------- -It costs a little time (maybe 4 seconds) to run througs every single signature -object, since these are more than 15000 Python objects. But all the signature +It costs a little time (maybe 6 seconds) to run througs every single signature +object, since these are more than 25000 Python objects. But all the signature objects will be rarely accessed but in special applications. The normal case are only a few accesses, and these are working pretty fast. @@ -111,10 +111,6 @@ the ``signature`` Python package. It has the following structure:: shiboken2/files.dir/shibokensupport/ backport_inspect.py - python_minilib_2_7.py - python_minilib_3_5.py - python_minilib_3_6.py - python_minilib_3_7.py signature/ loader.py @@ -125,6 +121,8 @@ the ``signature`` Python package. It has the following structure:: lib/ enum_sig.py + tool.py + Really important are the **parser**, **mapping**, **errorhandler**, **enum_sig**, |