[lxml-dev] 2.0 release plans

[Stefan Behnel]

Hi Holger,

jholg at gmx.de wrote:
> 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?

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