On 24.11.2010 10:41, ext Thomas Perl wrote:
I think the operator overloading is okay - it maps more directly from
the C++ code, so it's easier to "port" application code from C++ to
Python and vice versa. You do the same for camelCase method names
(PEP-8 says you should use lower_case_with_underscore method names),
after all. If the operator overloading is used, I can use the PySide
bindings without having to look at PySide-specific documentation
(least surprise), but if these new method names (filterLessOrEqual)
are introduced, I have to look them up and they have to be well
documented and I have to know that things are different if I port
(parts of) my Python code to C++.
I agree with Thomas here: I'd prefer following the C++ API. I think
there's actually the same level of surprise in the C++ API itself: you'd
expect the operators to return boolean values instead of objects there, too.
I'd regard this case a bit similar to the pyparsing module: it also
overloads the operators for its own purposes, and the result is a very
clear and usable syntax.
If operator overloading is to be avoided at all costs, how about making
a simple comparison function instead:
request.setFilter(gallery.year, "<=", "2010")
This would be more readable (IMO), but also more error-prone and even
less future-proof.
Also, is it possible in the C++ API to do something like this?
request.setFilter(gallery.year<= "2010" || gallery.author == "John")
If it is possible, how would that map to your proposed solution?
Currently, there are only simple comparisons:
http://doc.qt.nokia.com/qtmobility-1.1.0/qgalleryproperty.html
However, there's always the risk that more advanced operators are added
later on. Of course, the proposed syntax could be extended to have other
operators too (gallery.year.filterAnd, gallery.year.filterOr), but the
expressions can get pretty ugly pretty soon in that case.
ma.
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
