At 01:16 PM 12/14/2005 -0800, Brett Cannon wrote: >On 12/14/05, Michael Chermside <mcherm at mcherm.com> wrote: > > We already know that Python is particularly susceptable to "too slow" > > memes, even invalid ones. I think the best all-around solution is to > > include cElementTree and use it wherever possible unless the user > > specially imports the pure-python version. Perhaps importing > > "xml.etree" gets you cElementTree unless that isn't compiled on your > > platform, but you can import "xml.pure_python.etree" or something > > like that to get the pure Python version if you really want it. > >I don't think this will necessarily happen. You are assuming people >are going to know there is a faster way than ET written in Python. Actually, he's said that the C version should be the default, with the Python version only used if you have subclassing needs that can't be met by the C version. >And since I have always voted on the side of "have a C version only if >someone wants to maintain a C version but don't have both C and >Python", I say /F should include which ever he wants, but I personally >vote for only one version. So if /F is going to continue to maintain >cElementTree and since it is already written I say use that and just >get the speed boost and eliminate the isssue of people relying on that >1% semantic difference between the Python and C version. Having a Python version available for Jython, PyPy, etc., is a good idea; Michael's proposal lets us have your cake (C version be the default) and eat it too (have the pure Python available for other platforms and for explicit use by subclassers.
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