This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients Arfrever, effbot, eli.bendersky, eric.araujo, ezio.melotti, flox, scoder
Date 2012-02-11.08:39:14
SpamBayes Score 1.1523753e-09
Marked as misclassified No
Message-id <4F362922.9090100@users.sourceforge.net>
In-reply-to <1328947736.89.0.0896137937775.issue13988@psf.upfronthosting.co.za>
Content
Eli Bendersky, 11.02.2012 09:08:
> The more I think about it, the more the bootstrap code in _elementtree.c
> annoys me. It's the only instance of calling PyRun_String in Modules/ !
> 
> It's hackish and causes ugly import problems. If the C code needs stdlib
> functionality like copy.deepcopy, it should use PyImport_ImportModule
> like everyone else and not through a PyRun_String hack.

I find it perfectly legitimate to run Python code from a C module.
Certainly not a hack. We all know that most non-trivial functionality can
be expressed much easier in Python than in C, that's why we use Python
after all. In particular, defining a class with attributes and methods is a
couple of lines of code in Python, but a huge amount of code in C. Avoiding
the complexity of writing everything in C, or even of splitting the code in
a harder to understand way, is worth it.

That being said, I think it's worth removing any clear *redundancy* with
ET.py, as Florent's patch did. The goal is to keep _elementtree.c a pure
accelerator module that improves plain ElementTree, and redundancy is
counterproductive in this context. But if the implementation differs for
some reason, I would tend towards leaving it as is.

Stefan
History
Date User Action Args
2012-02-11 08:39:15scodersetrecipients: + scoder, effbot, ezio.melotti, eric.araujo, Arfrever, eli.bendersky, flox
2012-02-11 08:39:14scoderlinkissue13988 messages
2012-02-11 08:39:14scodercreate