On Mon, Feb 20, 2012 at 9:43 PM, Xavier Morel <python-dev at masklinn.net> wrote: > I'm not sure that's much of an issue, Element (and most of the top-level > utility "constructors") are documented as being frontend interfaces with > no specific type of their own, and indeed they are simply functions in > lxml, just as they are in cElementTree. > > Others will probably disagree, but as far as I am concerned these can stay > functions, avoid issues when switching to lxml or between ElementTree and > lxml (from one project to the next). For a similar situation (only the other way around), we're probably going to add a pure Python variant of functools.partial as a staticmethod, while the C version is a callable extension type. (see http://bugs.python.org/issue12428) Basically, if something is just documented as being callable without subclassing or instance checks being mentioned as supported in the docs, it can be implemented as either a type or an ordinary function, or pretty much any other kind of callable without being deemed an API change (obviously that's not a free pass to go make such implementation changes without a compelling reason, but C vs Python often *is* such a reason). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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