Hi all,
Assuming that Mark is back, should we try to get the API 2 PSEP draft
completed? Is everyone OK with my proposal of pushing the API 2 PSEP
through as is and then addressing the other raised issues separately? I
believe that would be the easiest way to proceed with the improvements.
About the pyqtConfigure: what should we then do with it? If it really is
completely unneeded, should it simply be dropped? A minimal API is a
clean one. :-)
Cheers,
ma.
On 30.04.2010 15:44, Airas Matti.P (Nokia-D/Tampere) wrote:
Hi,
sorry about the delay in my reply, I have been preoccupied with other stuff.
I'd still suggest that since Renato's ideas don't contradict with the
current PSEP, we still move forward with it (after settling the
pyqtConfigure issue Hugo raised). That way we can keep things more
compact and manageable. Renato can then prepare new PSEPs to push the
discussion about them forward. :-)
Cheers,
ma.
On 28.04.2010 16:36, ext 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.
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.
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.
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.
BR
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
