Forgot to add the main point - that would be AWESOME! =) -- anatoly t.
On Wed, Mar 20, 2013 at 11:46 AM, anatoly techtonik <[email protected]>wrote: > On Wed, Mar 20, 2013 at 10:41 AM, Christian Tismer > <[email protected]>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. >
_______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
