>> It's not frozen, it's actually maintained. > > Indeed, it sounds like the most appropriate course (if we don't hear > otherwise from Fredrik) may be to just update PEP 360 to acknowledge > current reality (i.e. the most current release of ElementTree is > actually the one maintained by Florent in the stdlib). > > I'll note that this change isn't *quite* as simple as Eli's > description earlier in the thread may suggest, though - the test suite > also needs to be updated to ensure that the Python version is still > fully exercised without the C acceleration applied. Sure thing. I suppose similar machinery already exists for things like pickle / cPickle. I still maintain that it's a simple change :-) > And such an an > alteration would definitely be an explicit fork, even though the user > facing API doesn't change - we're changing the structure of the code > in a way that means some upstream deltas (if they happen to occur) may > not apply cleanly. This is a very minimal delta, however. I think it can even be made simpler by replacing ElementTree with a facade module that either imports _elementtree or the Python ElementTree. So the delta vs. upstream would only be in file placement. But these are two conflicting discussions - if changes were made in stdlib *already* that were not propagated upstream, what use is a clean delta? Eli
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4