On 16.04.2010 17:58, ext Hugo Parente Lima wrote:
IMO, thinking with the foots in the implementation land, we have some options,
but I can't see a good one at the moment:
- Provide both API's for the same python version: will add a lot of complexity
to the bindings implementation, and some points in APIv2 only makes sense with
python 3, so I don't know if this is really a option.
Hmh, I see I'm being out-voted with this one... Oh well. :-)
Is there any other issue with API 2 on Python 2.x than Python strings
not being Unicode? How does PyQt deal with the issue when using API 2 on
Python 2.x?
Anyway, can't we simply accept regular strs by applying a default
unicode conversion, or just requiring any input strings to be unicode?
- Provide different API for different versions: will be like a fork, but the
worst, we will fork the project ourselves but remaining with the same number
of developers, so the development of the whole PySide will slow down for sure.
How do you feel about the development effort regarding this option as
compared to the first one? Probably somewhat simpler but is the
difference significant?
My opinion about this is a bit radical, just get one version of the API, 1 or
2, I'm inclined to 2, adapt/improve them, then stay with them on all python
versions.
If only one would be picked, I'd also definitely opt for API 2. However,
this contradicts with your claim that API 2 might not make sense on
Python 2. :->
I suppose one single backwards-incompatible change could be acceptable
if it happened very soon but how would we later on deal e.g. with the
exception changes? Breaking the API repeatedly is obviously not an
option. Should we then provide a way to simultaneously install different
PySide major versions? How would this be implemented on the Python side
(module naming)?
Cheers,
ma.
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
