Hi Armin,
So you're basically answering "no" :-)
no, I'm not saying no. (Okay, now I did twice. :) ) I did say that it was
high on my wish list, after all.
I know that there are many people who like to work the explicit way, which
is why such an interface needs to be provided. And it can be done, as it
already (mostly) exists, just scattered. Further, module level stuff already
lives on 'cppyy.' and C++ stuff lives on 'cppyy.gbl'. So I think that this
can be totally supported and faithfully follow CFFI, without clashing.
I just think that it's a historic artefact that folks want this, not that
they have good reasons for it.
CFFI has an additional advantage, by not having heavy dependencies. Good
luck writing your own pycppparser, though. :/ (Separate from ABI concerns.)
So if with C++, a full C++ compiler is pulled into the mix anyway, why
content with so much hand-coding?
As you're describing it, cppyy is at the "ctypes" level of providing
automatic everything
There's nothing automatic about ctypes. :?
What I mean is something like e.g. std::map<MyKey, MyValue>. Why would
anyone want to re-invent the pythonizations, if one can just do:
for key, value in my_cpp_map:
# ... whatever
directly from the automatic bindings and pythonizations provided by cppyy?
and lots of options and ways to work around them if they are not wanted
Right, but it's work either way? If no automation is provided, then that
work that could have been automated, needs to be provided by hand. To me
the equation seems to be that I rather have the automation get it 95% right,
with 5% (possibly frustrating) fixup, than doing 100% by hand even if that
gives me (non-frustrating) full control.
I know that some people do not agree with that, which is why I DO want to
have a CPPFFI, so that I can simply point them to that and let them have
at it. It's their own feet, after all. :)
I don't have enough practical knowledge of C++ to judge how viable a
"CPPFFI" would be.
C++11 is the big deal. I'm not saying that all of a sudden folks are going
to write better quality code (not to mention the installed base), but the
standards committee seems to have finally gotten it in their heads that if
intentions are not specified in the interface, it creates problems for
humans. I expect a lot of cleanup there, so that automation can grow from
95% right to 99% right or so, becoming a total no-brainer.
For example, with move semantics, returning an std::vector from a function
is almost as cheap as returning a pointer to an array, without any of the
questions about object ownership. (And don't fall over that "almost": most
likely the extra 8 bytes of the size data member that are copied over in
the case of the vector sit on the same cache line anyway, with the highest
cost being the pointer indirection in both cases.)
Of course, on top of all that, there will always be folks who think that
such automation produces something that "feels" too much like C++ and too
little like python. And they're highly likely to be right. But designing
such a python-like API is arguably more pleasant on top of C++-like python
than on C++ directly.
Anyway. :) As long as it is clear I didn't say "no", but said "after the
cling backend is in." (And yes, given the delays, I know that reads a bit
like "when pigs fly," but that's really not how I intend it.)
Best regards,
Wim
--
wlavrij...@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
