Hi Hugo,
On 2010-04-28, Hugo Parente Lima wrote:
> On Monday 26 April 2010 09:37:01 Matti Airas wrote:
> > On 23.04.2010 16:18, Airas Matti.P (Nokia-D/Tampere) wrote:
> > > On 23.04.2010 15:37, ext Mark Summerfield wrote:
> > >> Thanks, now I can do vim -d and see exactly what you changed (and I'm
> > >> happy with what you've done). (However, I'd suggest moving from "If
> > >> the need arises..." to "mapped to None)." to the end of the "No
> > >> QString and almost no QVariant" section.
> > >
> > > OK, did that. It's more logical now.
> > >
> > > http://www.pyside.org/docs/pseps/psep-0101.html
> > > http://www.pyside.org/docs/pseps/psep-0101.txt
> >
> > Assuming there're no more pending changes/improvements to this, I'll
> > mark this Accepted once I get an OK from the core dev team members.
>
> Just some questions about the final version of this PSEP.
>
> - QTextStream::bin, hex, etc wasn't removed?
PSEP 101 implies that these would be available, e.g.:
from PySide.Compatibility import bin_, hex_ # these are PyQt4's names
AFAIK the only reason for supporting QTextStream at all is for
compatibility with PyQt and for prototyping C++/Qt programs. I am not
aware of any reason why for plain text files PySide can't just use the
standard Python APIs.
> - I don't really see the need for pyQtConfigure method;
>
> IMO, integrate Qt properties with python is much more important.
> For example, instead of write:
>
> obj = QObject()
> obj.setObjectName("foo")
> print obj.objectName()
>
> we just need to write:
>
> obj = QObject()
> obj.objectName = "foo"
> print obj.objectName
>
> This is not hard to implement and IMO represents a great gain to this
> abstract and subjective thing called by us "pythonic API".
I agree that this would be really nice. I'm pretty sure that Phil wanted
to do this but hit conflicts between method names and property names,
but if it is doable it'd be great. But I think this should be the
subject of a separate PSEP (from you maybe:-)? since this is additional
to API 2. Nor does it conflict with API 2 supporting pyqtConfigure();
but if it did come it it would mean that pyqtConfigure() could be kept
purely for compatibility and not recommended for use in any other
context.
> Another point, this time regarding keyword arguments, I guess that we
> should follow Qt names, not the PyQt names, ok, I must admit that I'm
> saying this just because follow the Qt ones is easier to implement,
> hehehe, because the C++ parser knows the Qt argument names, but not the
> PyQt ones. Anyway I guess that PyQt is using the Qt argument names.
PyQt is _mostly_ using the Qt names (I think Phil fixed some silly ones)
*but*, even if the Qt names change in a later release, PyQt's names
*won't* change! This is because once a name is used in a Python API,
changing it can break code.
# Python:
def func(apple=5): return apple
// C++
int func(int apple=5) { return apple; }
In a later Qt release the Trolls might change the parameter name:
// C++
int func(int apple_count=5) { return apple_count; }
But we _cannot_ change the parameter name in Python without risking
breaking people's code, i.e., someone had used:
# Python
apples = func(apple=7) # [A]
and we'd renamed, e.g.
def func(apple_count=5): return apple_count
The call above [A] will be broken:
TypeError: got an unexpected keyword argument 'apple'
Of course people who've done:
apples = func(7)
are fine, but it would be wrong to assume that people don't use keyword
arguments esp. for more complex functions and constructors (e.g.,
QAction constructor).
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Rapid GUI Programming with Python and Qt" - ISBN 0132354187
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
