[PySide] Honkin Idea for PySide's thriving

anatoly techtonik techtonik at gmail.com
Wed Mar 20 09:46:27 CET 2013


On Wed, Mar 20, 2013 at 10:41 AM, Christian Tismer <tismer at stackless.com>wrote:

> Hey friends, it struck me, and I want to share before it's gone.
>
> I am writing this in the spirit of the PyCon US pyside BOF:
>
> Besides the technical issues and the things we discussed to create a real
> PySide community, I would like to add a hew goal.
>
> Make PySide the new standard Gui toolkit for Python!
>
> I see a lot of my core Python friends sharing my impression that PySide
> Is a great thing. If we can push it enough, it could even be an officially
> supported toolkit for python-dev!
>
> Either as a replacement or a supported alternative to Tcl/Tk, it could
> quite rapidly grow a pretty large community!
>
> This is a very rough and fresh idea, and I would like to know what would be
> Stopping us from doing that?
>
> I see a lot of advantages by going this far. We could even move away from
> PySide's object layout and invent a really pythonic new implementation.
>
> Comments are welcome -- chris
>

Few concerns.
1. Security
- all Qt security bugs are actual for PySide (all?)
- Python release cycle is longer than PySide
  = there should be a mechanism to have faster release cycle for PySide
than for the Python
     - this means shipping Python with PySide in site-packages/
       - which creates problems with all operating systems except Windows
         - and requires Python to invent its guidelines for those systems
           - which means it should have an understanding how different
systems handle it
             - which means there that some guidelines for OS developers
from Python should appear
               to help people *understand* Python distribution model and
*why* it is important
               - because often docs fail to explain why, and it is essential
     - this also means ability to detect when PySide needs updating
       - https://code.google.com/p/winpython/wiki/ControlPanel

2. Run-time size
- i don't want my server process to accidentally load PySide and eat all
the memory
  - which means that PySide (and GUI stuff in general) should not be copied
to virtualenv
    - which means that stdlib probably needs a split into core and GUI
things
      - and scientific community probably knows the problem and can show
some approaches
  - probably virtualenv should have an ability to copy stdlib without heavy
GUI or other stuff
    - for that stdlib needs partitioning
      - which means you can operate on stdlib module information
      - and query different info (which partition a module belongs, which
module is a file belongs, ..)
        - https://bitbucket.org/techtonik/python-stdlib

3. OpenGL canvas can be more useful
- direct access to hardware
- cross-platform API without intermediates
- requires a good user story based approach though, as it is not that simple

There were more concerns here. I am not sure if they are actual. In fact, I
have to go, so I can not even reread this.
http://mail.python.org/pipermail/python-dev/2009-November/094011.html

Some more ideas.

- IPython folks should be interested - if they are at PyCon, please talk to
them.
- Hugo said that the code base in fading out from his memory. That's
something that should be acted upon rather soon. We need to increase the
bus factor, and that means put more effort in simplifying codebase or at
least documenting it while it is still possible. Maybe some software
preservation fund, I don't know. Never worked with funds.
- A X/MIT-like license (not even PSF license) will definitely steer more
interest.
-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20130320/a3944a5f/attachment.html>


More information about the PySide mailing list