Message194784
> I agree, but this assumes there is a "better API". I would like to see
> an API proposal and a patch before I give an opinion :-)
Well, I have already proposed an API throughout this thread, and then given a usage example and an almost complete sketch of the implementation. Please comment.
I really can't accept the current wart for lxml, that's why I'm asking to not have it in ET either. This would be the first time I can remember that ET has a wrong API that lxml won't copy.
I was asking for removal now, because if we can't manage to come up with a new implementation quickly enough and keep the code in, we'll end up with a quirk that we'll have to keep alive basically forever, in addition to whatever clean API we add later. Time's currently running against us. If we back out the current code, definitely before alpha 2, it'll start running for us again. I clearly prefer that situation. |
|
Date |
User |
Action |
Args |
2013-08-10 04:23:08 | scoder | set | recipients:
+ scoder, jcea, pitrou, eli.bendersky, flox, python-dev |
2013-08-10 04:23:08 | scoder | set | messageid: <1376108588.03.0.928431964103.issue17741@psf.upfronthosting.co.za> |
2013-08-10 04:23:08 | scoder | link | issue17741 messages |
2013-08-10 04:23:07 | scoder | create | |
|