View source for Qt Contributors Summit 2019 Program/Qt for Python and beyond

Following the notes from the Qt for Python session

 - Continuation of the plenary session
 - Right now status is same as PyQt
 - What can we do to make a difference and improve on QtfP
 - Tooling
    - Around pyside and…
    - Make it easier to mix C++ and python
        - Currently a lot of black magic
        - Pyside2config etc…
 - Using it from the outside it is too complicated
     - Xml descriptions unclear, even with documentation
     - Proposal: Create generators for type system
     - Going through widgets as an example
     - The code is the documentation right now
 - What about editing the type-system, not only one-time generation?
     - Does it need to be a graphical solution?
     - Whatever it is, auto-completion is important/beneficial
     - Whatever happens, keeping C++ API and xml description in sync is troublesome and should be addressed
 - Embed the export information into the cpp?
 - Doesn't need to be xml, could be changed
 - Adding annotations for all Qt classes is not what we want
     - Developers will not learn/use it, there needs to be automatism
 - Proposal: Be not as verbose in the xml description
     - Use sane defaults and only annotate corrections
 - What is the amount of changes needed
     - Ownership is a good example, needs to be read from the documentation and manually adapted in the xml
 - We want to encourage users to start using Python extensions
 - What about using the metaobject system for auto-exposing to Python?
     - Currently not the case
     - But what about adding items which can be introspected?
     - Basically re-use Q_PROPERTY, Q_INVOKABLE,…
 - Tooling around python development?
     - Comparison to Rust: Cargo
     - Creates projects, manages compilation, deployment etc
     - Cookiecutter in python, which creates base templates
     - Idea: Add tools to create project templates
         - Potentially extract what Qt Creator does in the template
     - Have it create a folder structure including src/tests/….
     - What about creating a template for cookiecutter instead of writing a new tool?
     -  Cookiecutter maintainer is in Berlin as well ,potentially meet
 - Modules
     - Would there be any feedback on modules to add?
     - What about new pure python modules within the Qt context?
     - Example: Interaction with other python types, getting "python data" into QAbstractItemModel
     - Example: dataframes
     - Generally adaptors for existing python solutions
         - Does it have marketing reception impact? Qt moving "away" from C++?
     - Could be a separate solution, like Qt Lottie. Not part of the core product, but existent
     - Does this need to be associated with PySide?
         - If new modules are created which uses Qt/QtfP, why does it have to be in Pyside itself
         - And not standalone
     - Talking about the other way around
         - Qt Charts has its limitations
         - Use Qt / C++ for the heavy work and  Figure/Canvas from matplot to visualize
 - Improvements to python itself
     - C++ components in Qt exposed to Python?
          - Generally a C++ module exposing a "pythonish" API using Qt to do the work
          - Integrate into PySide then
     - Why not improve Cpython?
          - It's open source after all
     - Getting sidetracked
          - Project based approach, if a project needs improvement let the project identify where to fix it
 - Currently any python export requires manual shiboken compilation
     - We should improve here and make it easier
     - Idea: Some maintenance tool component which gets you latest shiboken and shiboken generator, etc…
         - Qt ships clang already, why not add the rest to the standard package?
     - Running out of time
 - Deploying Python applications is a mess
 - Python transpilers
     - Use-case: What about my python application which I need on a phone
     - Proposal: Wait for what others do and just use that
     - Beeware: Python VM in JS