Message153111
| 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 |
|