[Tim]
> Note: this kind of thing is much easier to do in C++ ...
[Thomas Wouters]
> Is that a veiled suggestion to compile Python as C++ ? ;)
Na, just a data point. If P3K is a reimplementation from the ground up, C++
is certainly worth considering.
At the O'Reilly conference, it was announced that the Perl rewrite in C++
(codenamed Topaz) has been abandoned. I didn't attend that session, but my
impression from others is that they attempted to model Perl objects directly
by C++ objects, and were frustrated by the consequent lack of low-level
control. That's more ambitious than I would have tried. Using C++ just as
"a better C" actually works, keeping the OO stuff simple and internal (e.g.,
I'd still expose a plain-C interface, and ignore the last 5 years of new C++
features <0.5 wink -- whether any given compiler handles them correctly is
still too much of a crap shoot>). So not really C++, but maybe C++--.
> I actually tried to do that, and it almost worked. Some of the current
> code uses a few C++ reserved words ('new', 'class') that need to be
> renamed, and a couple of expressions need some additional parentheses.
> (The Py_INCREF/DECREF macros, for instance, produced some
> incomprehensible g++ error.)
It would be good to clean that stuff up, to ease future experiments. I
haven't used C since 1994, *except* when working on Python, so stuff like
"new" and "class" used in non-C++ ways bothers my eyeballs.
mutual-back-scratching-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4