[Python-Dev] folding cElementTree behind ElementTree in 3.3 (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Mon Feb 20 13:50:43 CET 2012
- Previous message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Next message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Next message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]