On Monday 19 April 2010 07:10:40 Matti Airas wrote: > 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?
Reading Mark posts, I guess APIv2 is not impossible to be implemented on python-v2, at least regarding strings and bytes, what is byte on python3 can be strings on python2 and what is string on python 2, we convert to unicode (as we already do) when creating a QString. Of course we need to identify all the corner cases and possible showstoppers before take a decision. Another problem, we are going to do a release very soon and as Matt said, break the API every release isn't a good thing to do, so all steps should be carefully planned. > 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. -- 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
