On 2010-04-28, Renato Araujo Oliveira Filho wrote:
> Sorry guys but I think I had some difficulty to express myself in the last
> email. I will try to show my points in a clearer way.
>
> Like I wrote before this new PyQt API is a good change and I agree with
> that. The point is: we can use this PSEP to explore more changes into
> the API than PyQt did. We can split these points described on the current
> PSEP in other PSEP(s) to do real changes and create a more pythonic API.
>
> Like the removal of QString topic. Why remove only the QString and
> QVariant? There are lots of classes in QtCore which have a native
> python implementation in python modules like QFile, QDir, .... We
> can create a PSEP to list all classes potentially unnecessary in PySide
> and remove this from QtCore or create a separated module to keep the
> compatibility. With this we can get a great reduction of memory
> consumption and faster startup time, this is really important on small
> devices. The same can be done for other modules.
This seems like a very good idea to me. It would mean that for most of
the everyday file handling (just for example), people would use the
Python techniques they are already used to, while still making the Qt
classes available for those who want or need them.
Some candidates might be:
QByteArray (use bytes & bytearray in Python 3; str in Python 2)
QChar (use a str of length 1)
QDir
QDirIterator
QDom* (use Python's XML classes or Qt's QXmlStreamReader/Writer)
QExplicitlySharedDataPointer (irrelevant to Python?)
QFile (use open())
QFileInfo (use os & os.path modules)
QHash (PyQt doesn't support template containers anyway; use dict)
QHashIterator (see above)
QLatin1Char (use str of length 1)
QLatin1Strnig (use str)
QLibrary (use ctypes)
QLibraryInfo (use ctypes)
QMap (not in PyQt; no std. lib equiv.)
QMapIterator (see above)
... etc ...
I think that QDate and QDateTime (and therefore QTime) are worth keeping
since they provide more and better functionality than the standard
library's datetime module. For example, they handle timezones.
> Another point regarding this PSEP is: rename methods to avoid conflict
> with python reserved words. I don't know all the methods in Qt's API but
> certainly there are methods that need to be renamed too, like:
> QScriptEngine.evaluate, QValueObject.property, .... Then we need to list
> and verify all methods who need to be renamed, and discuss a new name
> or only append a "_" in the method name.
PyQt's approach is to append _, e.g., exec_(), and this seems
reasonable to me.
> And about Python and Qt's property I do not understand the whole
> problem, but in PySide we implement a dynamic meta object system and I
> think we can use that to create a new way to add dynamic properties into
> QObject (we need time to think about that), we do not need to follow the
> limitations of PyQt.
If Python programmers can deal with QObject properties in the same way
as they deal with object properties that would be much nicer.
> I think we can split this PSEP to discuss each topic separately and go
> beyond the idea of just adopting the PyQt API. We can start thinking
> about new pythonic API in all aspects to PySide, not only these ones
> that PyQt adopts.
>
> I agree about avoiding creating API incompatibilities and how this can
> cause problems to the current PyQt programmers, but we can create
> separated extensions to handle this. If some programmers want to write
> code
> like the C++ they can use this extension. In other words: we can be
> free to create a real pythonic API to python programmers.
That sounds like a really good approach:-)
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Programming in Python 3 (Second Edition)" - ISBN 0321680561
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
