Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Anthony == Anthony Baxter [EMAIL PROTECTED] writes: Anthony It's probably worth mentioning that right now, we don't Anthony even come close to compiling with a C++ compiler. A bunch Anthony of the bugs are shallow (casting result from malloc, that Anthony sort of thing) but a bunch more look a tad uglier. Is Anthony this something worth trying to fix? Um ... I really only know the results for XEmacs. C++ warnings and errors do catch a number of real bugs. But most of the *work* was done before I got really involved in the C code. Martin Buchholz [EMAIL PROTECTED] probably knows best, although he's been inactive for a couple of years. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Hello, should we perhaps switch to (careful use of) C++ in 3.0 ? I can't see many advantages in moving to C++, but a lot of disadvantages: - Size increase, especially when we start using templates - Performance decrease - Problems with name mangling together with dynamic loading and cross module API's - Everything has to be build with the same compiler, binaries created with different compilers can't interoperate - Possibly all extensions modules have to be (re)written in C++ - Moving to C++ will change Python's well known API substantially Same opinion. C++ is evil, please don't use it. You get a lot of new problems and nearly not benefit. Better go to jython or consider the way of pypy. -- bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
martin == martin [EMAIL PROTECTED] writes: martin I don't understand. How can you use a C++ compiler, but martin not the C++ language? An abbreviation for those features that aren't in C. martin As the recent const dilemma shows, C99 and C++98 have, martin unfortunately, different interpretations of const (with martin the C interpretation being more strict). Yeah, that's really unfortunate. I suppose we'll probably run into it fairly quickly. Nevertheless, the restriction to programs that are both legal C89 and legal C++ of similar vintage has paid off for us, in the sense that we went from GCC 2.95 to GCC 3.4 without having significant problems where the compiler suddenly decided our code was unacceptable. (Similar experience with other vendors' compilers.) Recently we've seen a significant rise in warnings that need to be fixed, and occasional errors, as GCC 4.x has become more common. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
It's probably worth mentioning that right now, we don't even come close to compiling with a C++ compiler. A bunch of the bugs are shallow (casting result from malloc, that sort of thing) but a bunch more look a tad uglier. Is this something worth trying to fix? Fixing the shallow bugs at least might be worthwhile... Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Fredrik Lundh wrote: someone also pointed out in private mail (I think; it doesn't seem to have made it to this list) that CPython's extensive use of inheritance by aggregation is invalid C. switching to C++ would be one way to address that, of course. A rather heavyweight solution to a problem that does not seem to have been a problem in practice so far, only in theory. Practicality beats purity once again... -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Zitat von Fredrik Lundh [EMAIL PROTECTED]: I'm not saying Python 3 should be written in C++, I'm only saying that doing so would have not just disadvantages. someone also pointed out in private mail (I think; it doesn't seem to have made it to this list) that CPython's extensive use of inheritance by aggregation is invalid C. switching to C++ would be one way to address that, of course. My preferred way of fixing it is to do it the proper C way, i.e. make PyObject the first member of each derived type. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Zitat von Greg Ewing [EMAIL PROTECTED]: A rather heavyweight solution to a problem that does not seem to have been a problem in practice so far, only in theory. The problem does exist in practice. Python is deliberately build with -fno-strict-aliasing when GCC is used, and might get compiled incorrectly on any other advanced C compiler. The problem with that bug is that it is both very hard to find when it exists, and very hard to dismiss as theoretical, unless an extensive source code review is performed. Have you done this review in the Python source code to know that there is no potential for misinterpretation to make the claim the problem is only theoretical? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Zitat von Stephen J. Turnbull [EMAIL PROTECTED]: martin - increased type-safety, in particular for API that isn't martin type-checked at all at the moment (e.g. PyArg_ParseTuple) That's merely an advantage to having a C++ *compiler*. No need to actually use the C++ *language*. :-) I don't understand. How can you use a C++ compiler, but not the C++ language? Either a program is required to conform to the C++ syntax (in which case it is a C++ program), or it isn't. In the specific example of ParseTuple, I don't see a C++ solution without templates, FWIW. XEmacs has had a policy of compiling without warnings under *both* C and C++ for about 5 years now, and it catches a lot of stupidity before it leaves the developer's sandbox. Right. It might be possible to write C++ programs that are also C programs, and it is then possible to release binaries of these through the C compiler. However, in the Python case, I doubt it would gain that much. As the recent const dilemma shows, C99 and C++98 have, unfortunately, different interpretations of const (with the C interpretation being more strict). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Hello, should we perhaps switch to (careful use of) C++ in 3.0 ? I can't see many advantages in moving to C++, but a lot of disadvantages: - Size increase, especially when we start using templates - Performance decrease - Problems with name mangling together with dynamic loading and cross module API's - Everything has to be build with the same compiler, binaries created with different compilers can't interoperate - Possibly all extensions modules have to be (re)written in C++ - Moving to C++ will change Python's well known API substantially Same opinion. C++ is evil, please don't use it. You get a lot of new problems and nearly not benefit. Better go to jython or consider the way of pypy. -- bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
On Feb 28, 2006, at 6:26 PM, Fredrik Lundh wrote: should we perhaps switch to (careful use of) C++ in 3.0 ? I hope not. It would make life more difficult for embedded/extended users like ourselves because it would force us to link our applications as C++ programs. That introduces lots of headaches on certain, shall we say, non-Windows platforms. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Zitat von Ulrich Berning [EMAIL PROTECTED]: I can't see many advantages in moving to C++, but a lot of disadvantages: There are a few advantages, though, mainly: - increased type-safety, in particular for API that isn't type-checked at all at the moment (e.g. PyArg_ParseTuple) - more reliable reference counting, due to destructors of local variables - native exception handling, making exceptions both less error-prone and possible more efficient. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
[EMAIL PROTECTED] wrote:
Zitat von Ulrich Berning [EMAIL PROTECTED]:
I can't see many advantages in moving to C++, but a lot of disadvantages:
There are a few advantages, though, mainly:
- increased type-safety, in particular for API that isn't type-checked
at all at the moment (e.g. PyArg_ParseTuple)
- more reliable reference counting, due to destructors of local
variables
Indeed, smart pointers should get rid of most reference counting problems.
- native exception handling, making exceptions both less error-prone
and possible more efficient.
Another advantage might be using inline functions instead of macros with
do {foo} while(0).
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
On 3/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: There are a few advantages, though, mainly: - increased type-safety, in particular for API that isn't type-checked at all at the moment (e.g. PyArg_ParseTuple) How would this be accomplished - by a function with a ton of optional templated arguments? By some sort of TupleParser(tuple) var1 var2 TupleParser::done? - more reliable reference counting, due to destructors of local variables Only true when the rules are consistent with what smart pointers or the like do. When there's more than a single rule, this goes out the window because you have to use the correct smart class... - native exception handling, making exceptions both less error-prone and possible more efficient. ...and exceptions make it impossible to not use smart classes. Since there isn't a nested level of C for each function call in Python, I don't see how exceptions in the implementation language would help exceptions in Python. Do I misunderstand your point, or is there some really cool trick I'm missing? (To explain my bias, I'm against the idea of the C++ rewrite as I also fail to see the advantages outweighing the disadvantages, especially in light of the amount of rewriting necessary to see the advantages cited so far.) Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Zitat von Michael Urman [EMAIL PROTECTED]:
On 3/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
How would this be accomplished - by a function with a ton of optional
templated arguments?
That's how I would do it. Actually, I would have PyArg_ParseTuple
overloaded with different numbers of arguments, say 0..64. Each
of them would be a template.
Only true when the rules are consistent with what smart pointers or
the like do. When there's more than a single rule, this goes out the
window because you have to use the correct smart class...
Sure. You have to use PyObject* now, so changing to usage of PyObject_ptr
wouldn't be that bad. Remember, we are talking about extension modules
*to python* here.
...and exceptions make it impossible to not use smart classes. Since
there isn't a nested level of C for each function call in Python, I
don't see how exceptions in the implementation language would help
exceptions in Python. Do I misunderstand your point, or is there some
really cool trick I'm missing?
Instead of checking for a NULL return value on all functions, a Python
exception could be expressed (on the C++ stack) as a C++ exception.
So instead of writing
n = PyString_FromString(name);
if (n == NULL)
return NULL;
for (ml = methods; ml-ml_name != NULL; ml++) {
if ((ml-ml_flags METH_CLASS) ||
(ml-ml_flags METH_STATIC)) {
PyErr_SetString(PyExc_ValueError,
module functions cannot set
METH_CLASS or METH_STATIC);
Py_DECREF(n);
return NULL;
}
v = PyCFunction_NewEx(ml, passthrough, n);
if (v == NULL) {
Py_DECREF(n);
return NULL;
}
if (PyDict_SetItemString(d, ml-ml_name, v) != 0) {
Py_DECREF(v);
Py_DECREF(n);
return NULL;
}
Py_DECREF(v);
}
Py_DECREF(n);
you would write
n = PyString_FromString(name);
for (ml = methods; ml-ml_name != NULL; ml++) {
if ((ml-ml_flags METH_CLASS) ||
(ml-ml_flags METH_STATIC))
raise new PyExc_ValueError(PyExc_ValueError,
module functions cannot set
METH_CLASS or METH_STATIC);
v = PyCFunction_NewEx(ml, passthrough, n);
PyDict_SetItemString(d, ml-ml_name, v);
}
(To explain my bias, I'm against the idea of the C++ rewrite as I also
fail to see the advantages outweighing the disadvantages, especially
in light of the amount of rewriting necessary to see the advantages
cited so far.)
That's why I'm explaining the advantages to you.
I'm not saying Python 3 should be written in C++, I'm only saying
that doing so would have not just disadvantages.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Fredrik Lundh wrote: should we perhaps switch to (careful use of) C++ in 3.0 ? I worry that if the Python core becomes dependent on C++, it will force all extensions to be written in C++, too. Not only is this inconvenient for people who don't know C++ or prefer not to use it, but I suspect this would lead to some severe interoperability problems. On most platforms, C code will happily link to just about anything else, but in my experience, C++ code will only interoperate with other C++ code when it's compiled by exactly the same compiler and uses the same runtime system. For another thing, I'm not sure that C++ polymorphism is flexible enough to implement Python's style of polymorphism. Think of all the tricks we play with type objects -- allocating them on the heap, extending them dynamically at runtime, etc. In C++, classes aren't even available as program-accessible entities. So we'd end up implementing our own form of dynamic dispatch anyway, and it would probably look a lot like the current C-based type objects. I don't see that C++ would help much. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
