On Wednesday 28 April 2010 10:00:06 Mark Summerfield wrote: > 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.
Phil must had been hit another problem if him tried to implement it, because
methods names conflicts are near impossible (in Qt) due to how you declare
properties using the Q_PROPERTY macro. Anyway, as Matt said, this can be
discussed in another PSEP, I don't know if I am a good candidate to write one
due to my lack of patience to write long documents... hehe
> > 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).
--
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
