On Mon, Feb 20, 2012 at 9:43 PM, Xavier Morel <python-...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
