[lxml-dev] 2.0 release plans

Hi, for the system I'm supporting that is based on lxml.objectify we need to get out a new release soon (alpha by the end of the week, final in mid-November). For this release I definitely want to have the shiny new 2.0-objectify behaviour. With the high quality I've come to know of lxml I wouldn't be really afraid to base that on a 2.0alpha or beta; however, I'd like to know if major changes are still waiting to happen for 2.0. To be on the safe side, I could also backport the functionality I need to the 1.3 series (maybe make it publicly available if anyone is interested). Stefan, what would you recommend with regard to your plans for 2.0? Holger -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Hi Holger, jholg@gmx.de wrote:
There isn't currently a target date for the final release, but there are a couple of things left to do. The thing is that they might have enough impact on the API to make me prefer implementing them during the alpha cycle rather than after the final release. One is iterparse(). Now that the target parser interface is in place, I'd like to reimplement iterparse() and allow you to pass in a parser (instead of "iterparse" *being* the parser). That would simplify both the API and the implementation quite a bit here. Also note the keyword-only argument changes that I applied to the trunk now. They haven't been alpha-released yet and I hope people won't come up shouting at me when they notice that lxml and Python start throwing TypeErrors at them because they accidentally passed keyword arguments in as positional arguments. The reason is that cElementTree distinguishes here, and that I think that this distinction makes the API much clearer. (BTW, internally, it uses Python 3 syntax, which I first had to implement for Pyrex... :) lxml is even a bit stricter here, as cElementTree relies on Python code for serialisation, for example, which doesn't support kw-only args. Another thing is that I'd like to wait a bit longer for Fredrik to get some work done on ET 1.3. I would hate having to re-adapt things for compatibility after releasing lxml 2.0. And finally, Pyrex is currently making steps towards being usable again for lxml. That shouldn't have much impact on the Python API, but making lxml build with a future Pyrex version will almost certainly impact the C-API, so that should be fixed before 2.0 fixes the C-level API here... Well, apart from that, I don't see any major obstacles for the release, and I don't think these things have much impact on objectify. Stefan

jholg@gmx.de wrote:
With the high quality I've come to know of lxml I wouldn't be really afraid to base that on a 2.0alpha or beta; however, I'd like to know if major changes are still waiting to happen for 2.0.
Another thing: I've started reworking the slicing code this weekend, but I'm not sure it'll work out. I'm trying to get rid of the __{get|set|del}slice__() methods (which will disappear in Py3 anyway), and to enable extended slicing. I hope it'll meet your quality expectations, "__setitem__(slice)" is a pretty tough algorithm... If I can manage to get it running, I'd also try to adapt objectify in that regard. But that's left to decide.
To be on the safe side, I could also backport the functionality I need to the 1.3 series (maybe make it publicly available if anyone is interested).
I wouldn't mind that. We could even ship a patch with the next 1.3 release, or start an intermediate 1.4 series with safe patches that change behaviour. I hope I get 2.0 out of the door soon enough, though, so that this won't be necessary. Stefan

Stefan Behnel wrote:
Extended slicing has just landed on the trunk. Anyone for a test? BTW, ET doesn't support extended slice assignment for now. Guess we have to be better here.
If I can manage to get it running, I'd also try to adapt objectify in that regard. But that's left to decide.
I'll have a look how this would turn out. Stefan

Hi Holger, jholg@gmx.de wrote:
There isn't currently a target date for the final release, but there are a couple of things left to do. The thing is that they might have enough impact on the API to make me prefer implementing them during the alpha cycle rather than after the final release. One is iterparse(). Now that the target parser interface is in place, I'd like to reimplement iterparse() and allow you to pass in a parser (instead of "iterparse" *being* the parser). That would simplify both the API and the implementation quite a bit here. Also note the keyword-only argument changes that I applied to the trunk now. They haven't been alpha-released yet and I hope people won't come up shouting at me when they notice that lxml and Python start throwing TypeErrors at them because they accidentally passed keyword arguments in as positional arguments. The reason is that cElementTree distinguishes here, and that I think that this distinction makes the API much clearer. (BTW, internally, it uses Python 3 syntax, which I first had to implement for Pyrex... :) lxml is even a bit stricter here, as cElementTree relies on Python code for serialisation, for example, which doesn't support kw-only args. Another thing is that I'd like to wait a bit longer for Fredrik to get some work done on ET 1.3. I would hate having to re-adapt things for compatibility after releasing lxml 2.0. And finally, Pyrex is currently making steps towards being usable again for lxml. That shouldn't have much impact on the Python API, but making lxml build with a future Pyrex version will almost certainly impact the C-API, so that should be fixed before 2.0 fixes the C-level API here... Well, apart from that, I don't see any major obstacles for the release, and I don't think these things have much impact on objectify. Stefan

jholg@gmx.de wrote:
With the high quality I've come to know of lxml I wouldn't be really afraid to base that on a 2.0alpha or beta; however, I'd like to know if major changes are still waiting to happen for 2.0.
Another thing: I've started reworking the slicing code this weekend, but I'm not sure it'll work out. I'm trying to get rid of the __{get|set|del}slice__() methods (which will disappear in Py3 anyway), and to enable extended slicing. I hope it'll meet your quality expectations, "__setitem__(slice)" is a pretty tough algorithm... If I can manage to get it running, I'd also try to adapt objectify in that regard. But that's left to decide.
To be on the safe side, I could also backport the functionality I need to the 1.3 series (maybe make it publicly available if anyone is interested).
I wouldn't mind that. We could even ship a patch with the next 1.3 release, or start an intermediate 1.4 series with safe patches that change behaviour. I hope I get 2.0 out of the door soon enough, though, so that this won't be necessary. Stefan

Stefan Behnel wrote:
Extended slicing has just landed on the trunk. Anyone for a test? BTW, ET doesn't support extended slice assignment for now. Guess we have to be better here.
If I can manage to get it running, I'd also try to adapt objectify in that regard. But that's left to decide.
I'll have a look how this would turn out. Stefan
participants (2)
-
jholg@gmx.de
-
Stefan Behnel