Python Poll results
Guido VanRossum
the congregation to raise hands to show their answers to various
questions. I've finally typed in the results -- see
http://www.foretec.com/python/workshops/1998-11/polls.html
Interpretation is up to the reader...
--Guido VanRossum (home page: http://www.python.org/~guido/)
David Arnold
Guido> Interpretation is up to the reader...
hmmm. i'd like to register an absentee vote for leaving Python 2.0 as
ANSI C.
my concern is that C++ compilers are a nightmare. it's enough trouble
to get a portable program in ANSI C, let alone attempting C++
i'm sympathetic to the argument that the object models could be drawn
closer together, but i don't think it outweighs the disadvantages.
my $0.02 (worth about USD 0.012 sadly ;-)
d
Bill Tutt
exporting classes from a DLL in VC++ is certainly a very huge pain. Its been
several times I've cursed and though of merging one of our DLLs that exports
C++ classes into a static library... *shudders*
Bill
Tim Peters
names and phone numbers of heretics who like curly braces) strong
support for moving CPython implementation to C++]
[David Arnold]
> hmmm. i'd like to register an absentee vote for leaving Python 2.0 as
> ANSI C.
>
> my concern is that C++ compilers are a nightmare. it's enough trouble
> to get a portable program in ANSI C, let alone attempting C++
Don't forget that Guido is Guido, though -- he's not likely to have any
interest in using C++'s worst features, or in abusing its best.
With a little work, we can identify a subset of C++ that's both powerful and
portable. E.g., stay away from fancy static initializers; stay away from
templates other than those in .h files that merely do inline redirection to
other stuff; don't dare define new conversions, and avoid operator
overloading in general; stick to ANSI C stdio; avoid diamond-shaped MI;
avoid non-local exceptions; and change Barry's c++ Emacs mode to insert the
keyword "virtual" everywhere the syntax allows it <0.9 wink>.
Given some iron restraint, C++ can be both portable and a much more
productive language than C.
everything-added-after-cfront-was-a-mistake<0.9++-wink>-ly y'rs - tim
Michael Scharf
Did you change your name?
Michael
--
''''\ Michael Scharf
` c-@@ TakeFive Software
` > http://www.TakeFive.com
\_ V mailto:Michael...@TakeFive.co.at
M.-A. Lemburg
be as fast as C++, so I guess JPython will rule...
Bill Tutt wrote:
>
> In addition, shared libraries and C++ don't mix very well either.
> exporting classes from a DLL in VC++ is certainly a very huge pain. Its been
> several times I've cursed and though of merging one of our DLLs that exports
> C++ classes into a static library... *shudders*
>
> Bill
>
> > From: David Arnold [mailto:arn...@dstc.edu.au]
> > Guido> Interpretation is up to the reader...
> >
> > hmmm. i'd like to register an absentee vote for leaving Python 2.0 as
> > ANSI C.
> >
> > my concern is that C++ compilers are a nightmare. it's enough trouble
> > to get a portable program in ANSI C, let alone attempting C++
> >
> > i'm sympathetic to the argument that the object models could be drawn
> > closer together, but i don't think it outweighs the disadvantages.
> >
> > my $0.02 (worth about USD 0.012 sadly ;-)
--
Marc-Andre Lemburg Y2000: 393 days left
---------------------------------------------------------------------
: Python Pages >>> http://starship.skyport.net/~lemburg/ :
---------------------------------------------------------
hin...@cnrs-orleans.fr
dav...@pobox.com wrote:
> hmmm. i'd like to register an absentee vote for leaving Python 2.0 as
> ANSI C.
Me too!
> my concern is that C++ compilers are a nightmare. it's enough trouble
> to get a portable program in ANSI C, let alone attempting C++
That's my experience as well, although I have to admit that I have
carefully avoided C++ programs for about a year, so I may have missed
a recent breakthrough in C++ portability.
Besides, I wonder what percentage of potential Python users actually
have a C++ compiler available. I don't, for example; for AIX 4.3
the only choice is IBM's compiler, which is too expensive for our budget.
(gcc doesn't support AIX 4.3 yet.) A while ago, I was contacted
by someone who wanted to use my DomainFinder program (written largely
in Python) but didn't even have a C compiler for his SGI machine!
So the assumption "every Unix machine comes with compilers" is no
longer true for C, much less for C++.
Then there is the problem of extension modules. If Python were written
in C++, every extension writer would have to have at least a basic
knowledge of C++. I know people who just want to call Fortran code,
and need help from others to get the C stuff done - I am sure they would
give up if they had to find a C++ expert first.
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hin...@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Cameron Laird
Tim Peters <tim...@email.msn.com> wrote:
.
.
.
>[David Arnold]
>> hmmm. i'd like to register an absentee vote for leaving Python 2.0 as
>> ANSI C.
>>
>> to get a portable program in ANSI C, let alone attempting C++
>
>interest in using C++'s worst features, or in abusing its best.
>
>With a little work, we can identify a subset of C++ that's both powerful and
>portable. E.g., stay away from fancy static initializers; stay away from
[details on semantics]
.
.
>Given some iron restraint, C++ can be both portable and a much more
>productive language than C.
>
>everything-added-after-cfront-was-a-mistake<0.9++-wink>-ly y'rs - tim
>
>
That's half the story, and you tell it accurately: Guido's
C++ would be aesthetically righteous, semantically grounded,
concisely expressed, ...
The worrisome other half is that:
a. C++ name-mangling schemes aren't standardized,
so objects from different compilers can't be
used together (mostly; I'm coming to think
that I can live with the work-arounds for this);
and
b. as near as I can tell, no human understands dynam-
ically-loaded C++ objects across a sufficiently
broad range of platforms to reassure me (while I
might be willing to sacrifice OpenVMS, the span
of AIX, HP-UX, and W95 is a good warm-up). This
isn't a particularly deep subject, not even as
interesting as, say, arguing about which tem-
plates and operator overloading are safe. It
*is* a royal pain, though ...
Aspects of the problem: getting dynamically-
loaded static C++ objects to construct themselves
correctly; all kinds of issues about correct
resolution of references between shared-object
libraries; ...
The good news about this challenge is that I
think the open-source community collectively
now understands all the issues. If Python does
move forward in this direction, it'll be pos-
sible to get help (from bright, co-operative
individuals, of course, not from vendors com-
mitted to promoting wise use of their products;
*that* would definitely be an alternate universe)
slogging through all the details.
I write C++ (in preference to C) whenever I can (constrained
by compiler availability, mostly). I've written little C++
the last six months, to my mild dismay.
(There's another half--you know how project-management
arithmetic is--that has to do with the practical availability
of C++ compared to C on the oddball platforms that interest
many of us. I'll not mention that in a follow-up addressed
to tim_one, 'cause it's too much like attention to usefulness.)
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX
Cameron Laird
.
[various apt concerns,
with which I'm sure
Guido is more or less
familiar, although
they're worth recording
in c.l.p]
.
.
>Besides, I wonder what percentage of potential Python users actually
>have a C++ compiler available. I don't, for example; for AIX 4.3
>the only choice is IBM's compiler, which is too expensive for our budget.
>(gcc doesn't support AIX 4.3 yet.) A while ago, I was contacted
>by someone who wanted to use my DomainFinder program (written largely
>in Python) but didn't even have a C compiler for his SGI machine!
>So the assumption "every Unix machine comes with compilers" is no
>longer true for C, much less for C++.
these would mostly look like extension writers
with perhaps a few application developers) would
like a service that compiles C or C++ source on
various platforms?
I confess, I'm being a bit coy in asking it this
way. I'm likely to stay that way, 'cause I haven't
worked out all the security implications yet. The
answer to the question above is, I already know
there are enough people that *I*'ll move forward
(perhaps slowly) with this project. The project
will create a (virtual) machine that takes source
code and a target description (examples: "32-bit
SGI"; "Digital Unix 4.0"; ...), and returns compiled
objects. Would that help you, Konrad? There's no
provision for exercising the object, but at least
you could pass it on to your customers, right?
Anyone know of a problem with the assumption that
"every Unix machine comes with a linker"?
.
.
.
Marc Poinot
>
> > my concern is that C++ compilers are a nightmare.it's enough trouble
> > to get a portable program in ANSI C, let alone attempting C++
>
> carefully avoided C++ programs for about a year, so I may have missed
> a recent breakthrough in C++ portability.
>
The unix system also was a major portability issue, before the ANSI C
and the POSIX standardisation.
Think about that when you use now an "import posix" ;)
People often learnt how to use the lowest compliant subset to make their
program portable. Otherwise, they were using "firewall".
You have the same process with C++, use the lowest compliant subset and
prepare the come of a largest subset by defining "firewall"s.
So far, the EGCS compiler (which has STL) is compliant enough for
us and I think we can relay on it to have the required platforms
on time before the Python 2.0 release.
> Then there is the problem of extension modules. If Python were written
> in C++, every extension writer would have to have at least a basic
> knowledge of C++. I know people who just want to call Fortran code,
> and need help from others to get the C stuff done-I am sure they would
> give up if they had to find a C++ expert first.
>
[1] C is a subset of C++ (hmmm... not sure it is a plus!)
[2] When you map Python/C you have to manage something else than your
application, you have to manage some "system".
When you map Python/C++ you can avoid the gap between the two
object models. This makes the interface easier.
Of course there are problems, but the gap is thiner. See the P.Dubois
extension class, which maps ISO C++ to Python. It's a nice work
where there is a effort to reduce the gap between Python objects
and the ISO C++ one.
Our fortran developpers prefer to make a real object-oriented
jump using directly C++ [or Python ;) ]. Then you have an
object-oriented part with Python/C++, and their Fortran code.
Otherwise, you get Python, C and Fortran with three differents
ways to design and code.
Marcvs [alias Is it clear enough that I vote for C++ ?]
zes...@my-dejanews.com
> > ANSI C.
>
I agree.
... [cut]
and I fully support Konrad's comments about problems with C++ compiler
availability. I'd be _very_ disappointed if Python goes C++
> -----------------------------------------------------------------------------
> Konrad Hinsen | E-Mail: hin...@cnrs-orleans.fr
> Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
> Rue Charles Sadron | Fax: +33-2.38.63.15.17
> 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
> France | Nederlands/Francais
> -----------------------------------------------------------------------------
--
Uwe Zessin
Andrew M. Kuchling
>a. C++ name-mangling schemes aren't standardized,
> so objects from different compilers can't be
> used together (mostly; I'm coming to think
> that I can live with the work-arounds for this);
> and
That's a feature, not a bug. Different compilers may
implement things like exception handling in different ways. Divergent
mangling means that if you try to mix code from different compilers,
it will fail at the link stage, instead of linking and then blowing up
at runtime.
Incidentally, no one has mentioned the Mozilla C++ portability
guidelines yet:
http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
For a start, we never even noticed the Renaissance. The Renaissance was a load
of bloody Italians poncing around claiming to be the golden age of the Greeks
come around again. Nobody in England had even heard of the Renaissance until
it had been over for centuries.
-- Hob Gadling, in SANDMAN #73, epilogue to "The Wake"
Cameron Laird
Andrew M. Kuchling <akuc...@cnri.reston.va.us> wrote:
.
.
.
> That's a feature, not a bug. Different compilers may
>implement things like exception handling in different ways. Divergent
>mangling means that if you try to mix code from different compilers,
>it will fail at the link stage, instead of linking and then blowing up
>at runtime.
>
> Incidentally, no one has mentioned the Mozilla C++ portability
>guidelines yet:
> http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html
really, these are essential reading, and
I urge them on anyone within arms'-reach,
but there's little escaping that they
amount to, "Don't do anything that Bjarne
et al. have worked on in the last six
years," in extended form.
Gordon McMillan
> [Guido, points to a poll showing (among other things, such as the
> names and phone numbers of heretics who like curly braces) strong
> Don't forget that Guido is Guido, though -- he's not likely to have
> any interest in using C++'s worst features, or in abusing its best.
Also don't forget that those are "raw" numbers. There were 58
developers in the room. Guido explicitly stated that he hadn't voted
yet. So the final numbers will show a plurality as 59 votes, and
unanimous as 117.
As for the C++ question, while I voted for it, I rather assumed that
the entry points will still be exposed as extern "C". For the same
reasons that Bill Tutt cites, I always do it that way myself. Even
with a private dll / shared lib, it's easier to cast than to link
C++. While by no means a sure thing, vtables are much more portable
than name-mangling.
And if that's not workable, and the (internal) C++ gets exposed as
purse ANSI C (with no void* shortcuts), it will still be a whole lot
easier to rewrap it into C++ in an extension module than it is to
wrap the current interface.
it's-a-no-brainer-that-the-"abstract-layer"-will-change-ly y'rs
- Gordon
Paul Jackson
I don't think it's all or none on the question of "Python
going C++".
If I were coding it, I'd likely use "portable" C++ for the
innards, but at the boundaries where others doing extensions
and ports live, present a C surface. We're doing something
like that here (SGI) for a big chunk of code that is a blend
of two legacy systems, on C and the other C++.
I continue to code mostly in C++, but present a "C front" to
the other heavy coder, who is a died in the wool C coder.
For example, I wrap symbols that he might need with:
extern "C" {
...
}
and headers we share are plain old C code.
In short, the issue of how internals are written is separate
from the issue of interface presented. I'd recommend C++
(perhaps with the Mozilla portability constraints) for one, C
for the other.
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (p...@sgi.com; p...@usa.net) 3x1373 http://sam.engr.sgi.com/pj
Konrad Hinsen
> [1] C is a subset of C++ (hmmm... not sure it is a plus!)
And a much simpler subset - an important consideration for
people who are not professional programmers.
> [2] When you map Python/C you have to manage something else than your
> application, you have to manage some "system".
> When you map Python/C++ you can avoid the gap between the two
> object models. This makes the interface easier.
I have no objection to providing Python 2 with a C++ interface,
quite on the contrary. But I'd prefer to be able to use it
without a C++ compiler, and to be able to write extension modules
without knowing C++.
> Our fortran developpers prefer to make a real object-oriented
> jump using directly C++ [or Python ;) ]. Then you have an
Which is a good idea, but the scientists I know use the
"minimum effort" approach: they try to avoid learning anything new.
> Marcvs [alias Is it clear enough that I vote for C++ ?]
Yes ;-)
--
-------------------------------------------------------------------------------
Sion Arrowsmith
in C++, using NT, Linux and Solaris as development platforms,
with several other flavours of Unix as additional target
platforms. We use VC++ something-or-other on NT and EGCS on the
rest, all heavily reliant on the STL. EGCS produces distinctly
less lean code, and has presented a few problems on some of the
platforms:
In article <745upr$9l8$1...@Starbase.NeoSoft.COM>,
Cameron Laird <cla...@Starbase.NeoSoft.COM> wrote:
>a. C++ name-mangling schemes aren't standardized,
To get our code working on Digital Unix, we had to invoke the
magical "squangle" flag -- which "squeezes" the mangled names
so they don't excede the length limit in the linker.
>I write C++ (in preference to C) whenever I can
I'm half-way converted. I do like having a proper string
type, and maps and lists I don't have to roll myself.
> [ ... ] that has to do with the practical availability
>of C++ compared to C on the oddball platforms that interest
>many of us.
This would be my main concern about making Python 2.0 C++.
EGCS is maturing rapidly, but is it rapid enough, and will
it be portable enough, and will it deliver the same
performance?
--
\S -- si...@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
<*> |
Robin Becker
writes
... C rather than C++
>> Me too!
>
>I agree.
>
>... [cut]
>
>and I fully support Konrad's comments about problems with C++ compiler
>availability. I'd be _very_ disappointed if Python goes C++
>
>--
>Uwe Zessin
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
decision. C betters C++ on so many grounds. What is the problem that C++
would solve for the implementers of Python? MHammond already shows you
can use C++ if you want & he's done it in a demanding and fault
intolerant environment (Win32 COM etc etc). Nobody stops extension
writers from using C++; the C++ camp shouldn't force everyone to do so.
--
Robin Becker
Konrad Hinsen
> Tangential question: how many people (presumably
> these would mostly look like extension writers
> with perhaps a few application developers) would
> like a service that compiles C or C++ source on
> various platforms?
Sounds like a good idea - depending on the conditions. In the
open source world there should be no legal problems, of course.
But if it's a commercial service, I'd probably not be willing
to pay much...
> (perhaps slowly) with this project. The project
> will create a (virtual) machine that takes source
> code and a target description (examples: "32-bit
> SGI"; "Digital Unix 4.0"; ...), and returns compiled
Sounds good. But how many platforms do you plan to support?
> objects. Would that help you, Konrad? There's no
For distribution purposes, yes. But for the C++ issue, no.
If today's Python were written in C++, I couldn't even develop
extensions!
> Anyone know of a problem with the assumption that
> "every Unix machine comes with a linker"?
I am not sure that a machine without a compiler comes with a linker!
James Logajan
>
> In article <745rlh$kqi$1...@nnrp1.dejanews.com>,
> hin...@cnrs-orleans.fr wrote:
> > In article <1998120305...@piglet.dstc.edu.au>,
> > dav...@pobox.com wrote:
> >
> > > hmmm. i'd like to register an absentee vote for leaving Python 2.0 as
> > > ANSI C.
> >
> > Me too!
>
> I agree.
Me three! (or is it four?)
Jean-Claude Wippler
>
> I don't think it's all or none on the question of "Python going C++".
So true.
Sigh. As the dust is settling on comp.lang.tcl about this same issue
(C++ vs. C) for a different reason (a more modular Tcl core), the same
arguments show up again here.
It's time to get rid of some myths (uh, oh, I'm gonna be lynched!).
C++ is not portable: It is, maybe slightly less than C these days, but
the gap is likely to close as gcc/egcs move forward. The weak spot is
probably with embedded systems: ok, keep Python 1.6 for those who cannot
go to C++ (the version is not a typo, the time frame is years from now).
C++ code is big: Wrong. Unless one uses templates the wrong way, and
unless compilers implement exception handling using old techniques.
There is no reason why C++ code is bigger. Inlines, const, modularity,
they all help reduce the code. Someone just sent me some statistics
showing that egcs 1.1 produces smaller code than MSVC 5 on Win32, using
the same unmodified source code of Tcl 8.0.4 (this is pure C, but it
shows that the backends of both C and C++ are in good shape nowadays).
C++ code is slow: Wrong, for almost the same reasons. And I hate to
mention another analogy: it's why assembly programmers voted against C.
C++ name mangling means linker trouble: Not if the public interfaces
use vtables for everything, and one extern "C" for the base entry point.
As a matter of fact, this platform-independent COM-like approach will
solve a lot of linker problems (no more load path problems, for one).
Paul Duffin and Jan Nijtmans are working on doing exactly this for Tcl.
C++ precludes extensions in C: Not at all, one can add a set of wrapper
functions which show a C layer outside and call through vtables inside.
Since no static constructors or exception handling need be involved, the
resulting code "ought to be" linkable without C++ linker support at all.
This is a critical issue, the C wrapper layer will have to work well.
C++ precludes C: Wrong. C++ is C, except for a few minor details.
C++ locks you in: There is gcc, egcs, mingw32, MSVC, Metrowerks, and
also a whole pile of Unix-specific C++ compilers out there.
Here are some reasons why using C++ makes sense for a Python 2 core.
Constructors: Stack-based constructors/destructors make reference-
counted object management simple. C++ code quality improvement #1 is
based on just this automatic cleanup, IMO. You all know Python, you
want automatic cleanup, right?
Exceptions: If used (this needs careful evaluation), they simplify code
tremendously. Paul Dubois' recent C++ extension support classes show
just how simple - dare I say Python-like? - error-handling becomes.
Virtual tables: With judicious use, these make plug-in replacements
feasible, and enhance the way in which code can be highly modularized.
It's a too-natural-to-be-true way of connecting a core with extensions.
Plug in a different regular expression mechanism, create a core without
floating point support for small-footprint uses, let I/O be adaptable
with channels. It's nothing new at all, really: Python object "types"
are really a manual form of vtables.
Templates: And <ducking for cover> STL, the Standard Template Library.
There are very complex tradeoffs here, but to say that STL is just a
bloated/complex piece of code would be missing the point to an extreme.
I will simply state that templates is what makes it possible to create a
core interpreter which works optimally on 32 and 64-bit architectures,
which will allow extreme scalability, and which lets people experiment
with core data structure changes without affecting all the source. From
a perspective of evolution, templates are very important.
Operator overloading: This is arguably just syntactic sugar, but in the
context of Python (again, see Paul Dubois' code), it can make it easier
to reduce the impedance-mismatch between Python and C++. Things like
"tuple[index]", "dictionary[key]", but even "object->*attribute" are
possible, though it's a slippery path - it's easy to overdo things.
C: Yes, it has to be mentioned again. Things like pcre, stdio,
unicode, and all the other things one wants to use as is, including
substantial parts of Python 1.x, work in C++. No new wheels, please.
There are two major drawbacks to using C++, IMO.
1) Too much rope: C++ has lots and lots of rope to hang yourself.
The world is littered with examples on how badly it is used.
2) Acceptance: The level of opposition to C++ is simply amazing.
That is going to be a major factor in deciding for/against C++.
Ok. Now lynch me. While you do, please understand that I am not doing
this to promote C++ for C++'s sake. Anyone who knows me, knows that my
views extend quite a bit further than any specific language or OS.
If the outcome is that Python 2 is written in Eiffel, that's fine too.
-- Jean-Claude
Oleg Broytmann
On 3 Dec 1998, Konrad Hinsen wrote:
> I am not sure that a machine without a compiler comes with a linker!
Sure - modern SysV systems come without compiler (to force you to pay
for one) but with linker - to relink kernel from obj files. Solaris, e.g.
Usually this solved with gcc - you don't need to pay much, and it is
good C/C++ compiler.
Oleg.
----
Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/
Programmers don't die, they just GOSUB without RETURN.
Scott
Me four (or is it five?)
Guido van Rossum
> Sigh. As the dust is settling on comp.lang.tcl about this same issue
> (C++ vs. C) for a different reason (a more modular Tcl core), the same
> arguments show up again here.
So why do you bring this discussion here? I just skimmed some
fraction of that thread in the Tcl group and I don't think I need to
see the same thing to be repeated here. You were very vocal in that
thread and your post shows you haven't changed your mind, so your
contributions here will just be duplicates of posts there.
So please (everyone!) stop this discussion NOW. Whoever is interested
in this issue, please read the Tcl thread (*). It's not dead yet, so
feel free to continue there -- if you thing you have something *new*
to say. But leave c.l.python out of it!
(*) This is the URL of the Tcl thread at Deja News:
http://www.dejanews.com/thread/%3c3653FCC...@equi4.com%3e%231/2
--Guido van Rossum (home page: http://www.python.org/~guido/)
Jean-Claude Wippler
[...]
> So please (everyone!) stop this discussion NOW.
Done. I'm sorry. I'm a fool. And I apologize.
-- Jean-Claude
Tim Peters
[Cameron Laird]
> ...
> The worrisome other half is that:
> a. C++ name-mangling schemes aren't standardized,
> so objects from different compilers can't be
> used together (mostly; I'm coming to think
> that I can live with the work-arounds for this);
> and
I read the poll (Guido said it was open to interpretation <wink>) as
supporting implementation in C++, not as supporting changing the Python API
to require C++ gimmicks. So I had in mind a pure 'extern "C"' public
interface (like today's), with all the C++ under the covers, used only to
lighten Guido's internal implementation burden.
> b. as near as I can tell, no human understands dynam-
> ically-loaded C++ objects across a sufficiently
> broad range of platforms to reassure me (while I
> might be willing to sacrifice OpenVMS, the span
> of AIX, HP-UX, and W95 is a good warm-up). This
> isn't a particularly deep subject, not even as
> interesting as, say, arguing about which tem-
> plates and operator overloading are safe. It
> *is* a royal pain, though ...
>
> Aspects of the problem: getting dynamically-
> loaded static C++ objects to construct themselves
> correctly; all kinds of issues about correct
> resolution of references between shared-object
> libraries; ...
>
> The good news about this challenge is that I
> think the open-source community collectively
> now understands all the issues. If Python does
> move forward in this direction, it'll be pos-
> sible to get help (from bright, co-operative
> individuals, of course, not from vendors com-
> mitted to promoting wise use of their products;
> *that* would definitely be an alternate universe)
> slogging through all the details.
If public interfaces remain straight C, most of this stuff never comes up.
Static C++ objects are a bad idea in any case for portable code (just
because the std doesn't define enough useful rules for getting them
initialized).
All in all, when I talk about restricting C++ to a portable subset, I mean a
subset that's actually portable <wink>.
> I write C++ (in preference to C) whenever I can (constrained
> by compiler availability, mostly). I've written little C++
> the last six months, to my mild dismay.
>
> (There's another half--you know how project-management
> arithmetic is--that has to do with the practical availability
> of C++ compared to C on the oddball platforms that interest
> many of us. I'll not mention that in a follow-up addressed
> to tim_one, 'cause it's too much like attention to usefulness.)
It's a consideration, but also a tradeoff. If implementing in C++ means
Guido can get his work done in half the time with half the aggravation,
that's probably worth delaying the day when CPython can be embedded in an
intelligent light bulb under some sparkling new BulbOS. 10 years later,
who's still delighted that CPython stuck to K&R C, despite that the most
useful subset of the then-new ANSI C features was available on most major
platforms? The most useful subset of C++ features is already much better
established than that was, available for years now on all major platforms
and many minor ones too.
it's-not-like-we're-arguing-reimplementation-in-a-passing-
fad-like-say-perl<wink>-ly y'rs - tim
sk...@calendar.com
> Andrew M. Kuchling <akuc...@cnri.reston.va.us> wrote:
> > Incidentally, no one has mentioned the Mozilla C++ portability
> >guidelines yet:
> > http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html
> I giggle every time I think of 'em. No,
> really, these are essential reading, and
> I urge them on anyone within arms'-reach,
> but there's little escaping that they
> amount to, "Don't do anything that Bjarne
> et al. have worked on in the last six
> years," in extended form.
Which is, unfortunately, a pretty strong indictment of what Bjarne et al have
been doing for the past six years. They've added so much complexity to the
language that the poor compiler writers can't keep up and the application
writers keep getting burned when they try to use anything "new". C++ has been
around for about ten years now and to program portably in it you *still* have
to gut the language or avoid platforms. It's really very disappointing.
--
Skip Montanaro
Mojam: http://www.mojam.com/
Musi-Cal: http://concerts.calendar.com/
Barry A. Warsaw
>>>>> "CL" == Cameron Laird <cla...@Starbase.NeoSoft.COM> writes:
CL> I write C++ (in preference to C) whenever I can (constrained
CL> by compiler availability, mostly). I've written little C++
CL> the last six months, to my mild dismay.
Cameron, you forgot to add that the *reason* you write so little C++
code lately is that you've discovered you really can do it all in
Python! So I think you meant to say "happy surprise" instead of "mild
dismay". :-)
Hey, I was a full-time C++ hacker for 4 years before joining CNRI and
the only C++ I write now are test cases for CC Mode :-). The only C I
write these days is when I hack on Python's guts. I thought for sure
I'd be writing more Java too, but dang if JimH didn't quash that urge
quite effectively.
Living in a world full of nails, and Python's the hammer,
-Barry
Barry A. Warsaw
>>>>> "AMK" == Andrew M Kuchling <akuc...@cnri.reston.va.us> writes:
AMK> Incidentally, no one has mentioned the Mozilla C++
AMK> portability guidelines yet:
AMK> http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html
And David Williams would know.
BTW, my read from The Poll was that it might be just as likely Python
2.0 would be written in Java as C++. :-) Which is to say, who knows
what The Guido will do?
-Barry
Cameron Laird
that the Tim writes
better than I can
excerpt]
.
.
>It's a consideration, but also a tradeoff. If implementing in C++ means
>Guido can get his work done in half the time with half the aggravation,
>that's probably worth delaying the day when CPython can be embedded in an
>intelligent light bulb under some sparkling new BulbOS. 10 years later,
>who's still delighted that CPython stuck to K&R C, despite that the most
>useful subset of the then-new ANSI C features was available on most major
>platforms? The most useful subset of C++ features is already much better
>established than that was, available for years now on all major platforms
>and many minor ones too.
>
>it's-not-like-we're-arguing-reimplementation-in-a-passing-
> fad-like-say-perl<wink>-ly y'rs - tim
>
>
All true. The *first* principle, anyway, is that
the greatest leverage always comes from supporting
Guido; he turns out great riches, and is apparently
inexpensive to feed.
Mention of BulbOS brings to mind one very tangential
grumble. Back in the days when Java appeared to be
spreading *everywhere*, some mistaken people made
strategic decisions to code cryptographic stuff
destined for smartcards in Java. The JVMs never
appeared--preliminaries were too slow and bulky, and
JavaSoft et al. said, "Move to more powerful smart-
cards." Cryptographers working with embedded
devices favor assembler and C to this day, as near
as I can tell.
I don't think this story has a moral.
Philosophical deconstructionists of the '80s warned
against "totalizing" tendencies (something like the
hegemonies Maoists feared). I can imagine Python
everywhere, including BulbOS--and maybe implemented
in a totally slick, way cool, post-modern way. That's
not necessarily the best Python, though. The kernel
of engineering always is judgment about trade-offs.
The Python we have now is a great achievement. I'm
completely confident Python 2.0 will be even better.
If it doesn't do everything that I want, I'll get
over it.
Amit Patel
| In article <13926.40671....@amarok.cnri.reston.va.us>,
| .
| .
| > That's a feature, not a bug. Different compilers may
| >implement things like exception handling in different ways. Divergent
| >mangling means that if you try to mix code from different compilers,
| >it will fail at the link stage, instead of linking and then blowing up
| >at runtime.
| Righto. Fail early, bind late, say I.
| >
| >guidelines yet:
| > http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html
| I giggle every time I think of 'em. No,
| really, these are essential reading, and
| I urge them on anyone within arms'-reach,
| but there's little escaping that they
| amount to, "Don't do anything that Bjarne
| et al. have worked on in the last six
| years," in extended form.
Unfortunately, it's those features (well, templates in particular),
not the original features, that I find to be the coolest parts of C++.
:-)
- Amit
Fredrik Lundh
>Which is, unfortunately, a pretty strong indictment of what Bjarne et al have
>been doing for the past six years. They've added so much complexity to the
>language that the poor compiler writers can't keep up and the application
>writers keep getting burned when they try to use anything "new".
Most of the problem is that people still think it's cheaper to
use whatever C++ compiler they happen to get their hands
on, and spend huge amounts of time working around the quirks,
than to fork out a marginal amount of money for a working
compiler. Trust me, time isn't free...
>C++ has been around for about ten years now and to program
>portably in it you *still* have to gut the language or avoid plat-
>forms. It's really very disappointing.
Get any compiler using the EDG front-end (www.edg.com),
and you will have no more C++ problems. Hey, if DEC had
switched to EDG a year earlier, I might still be using that
language...
Cheers /F
fre...@pythonware.com
http://www.pythonware.com
Christopher G. Petrilli
> sk...@calendar.com wrote:
> >Which is, unfortunately, a pretty strong indictment of what Bjarne et al have
> >been doing for the past six years. They've added so much complexity to the
> >language that the poor compiler writers can't keep up and the application
> >writers keep getting burned when they try to use anything "new".
> Most of the problem is that people still think it's cheaper to
> use whatever C++ compiler they happen to get their hands
> on, and spend huge amounts of time working around the quirks,
> than to fork out a marginal amount of money for a working
> compiler. Trust me, time isn't free...
But Python is supposed to be, therefore it has to work with the freely
available C++ implementations as well as most common commercial ones
(MS, Sun, IBM, etc). This gets you into an ugly circle. Writing
portable ANSI C is hard enough, I can't even imagine with C++. Has
anyone looked at hte groff code to see how UGLY this becomes?
> Get any compiler using the EDG front-end (www.edg.com),
> and you will have no more C++ problems. Hey, if DEC had
> switched to EDG a year earlier, I might still be using that
> language...
In this situation, isn't that something akin to Linux people telling you
that you have to use Microsoft C++? :-) Seriously, if all C++
implementations are broken in one way or another (and I'm not convinced
yet they aren't), then you have to take some subset of the language that
allows for portability. When combined with the extern "C" requirement
for shared libraries, I'm beginning to wonder what you might gain other
than to change things? I'd much rather see Python throw out all the K&R
stuff it lives with, and go with ANSI-C. We don't want to get to the
point where you have to tell the user the EXACT compiler they can use
because everything else is broken... that to me is a poor decision on
the tools front.
Chris
--
| Christopher Petrilli
| petr...@amber.org
Michael T. Richter
> stick to ANSI C stdio;
I would disagree with this. ANSI C stdio is horribly difficult to overload
or modify for anything other than what it currently supports. Try using
printf to pop up a GUI message box, for example -- an issue in platforms
(like WinCE) which don't have shells.
--
Michael T. Richter <m...@ottawa.com> http://www.igs.net/~mtr/
PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8
Frank Stajano
Laird) wrote:
>(perhaps slowly) with this project. The project
>will create a (virtual) machine that takes source
>code and a target description (examples: "32-bit
>SGI"; "Digital Unix 4.0"; ...), and returns compiled
>you could pass it on to your customers, right?
So you compile the code on this remote service (but you have nowhere
to try it out) and then ship it to the customers? And of course this
untested port willl work 1st time? And in -- of all things -- C? ;-)))
Sorry Cameron, I can see from the tone of your post that it was meant
as a helpful community service, but it just looks too funny not no
make jokes about!
Christian Tismer
Perfect situation. Funny ideas are finally those which have a
chance to succeed. Or what would you have said about an SMS gateway
if you were asked 10 years ago?
And I think I heard you saying "ORL" some time in your exciting
speech at SPAM7. "VNC" (virtual network computing) is also an
example of funny stuff, but it works, and I use it all day :-]
Now, let's try to make fun:
What if there was not just a compiling service, but also some
test bed available. And a port of the VNC server. I don't know
SGI, but I can tell that running a linux app on a remote server
which doesn't have a screen, just a virtual VNC X interface
works great for me. I do compilations, and I play with user
interfaces over our inhouse network from a WinNT box.
Great stuff, this VNC.
Is there an SGI port available?
I have to admit that a remote service like this could be quite
slow. But networks tend to become faster.
I could imagine that one builds a test bed on his machine, with
compiler, some virtual screen (maybe just a shell) for testing,
and give this service away to customers for some payment
(and free for Konrad, of course:)
In the sense of "usenet", but interpreted as "how to make as
much use of the net as possible", I think this is a challenge,
and just a beginning.
wishing-to-smell-a-virtual-Italian-coffee - ly y'rs - chris
--
Christian Tismer :^) <mailto:tis...@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net
10553 Berlin : PGP key -> http://pgp.ai.mit.edu/
we're tired of banana software - shipped green, ripens at home
David Ascher
>> (perhaps slowly) with this project. The project
>> will create a (virtual) machine that takes source
>> code and a target description (examples: "32-bit
>> SGI"; "Digital Unix 4.0"; ...), and returns compiled
>> objects. Would that help you, Konrad? There's no
>> provision for exercising the object, but at least
>> you could pass it on to your customers, right?
> [Frank Stajano]
> So you compile the code on this remote service (but you have nowhere
> to try it out) and then ship it to the customers? And of course this
> untested port willl work 1st time? And in -- of all things -- C? ;-)))
>
> Sorry Cameron, I can see from the tone of your post that it was meant
> as a helpful community service, but it just looks too funny not no
> make jokes about!
Not really -- it's just a remote compilation service. It would produce
the same output that a compiler on a local machine would -- warnings,
error messages, etc. You're not able to test it out, but then again,
you're not able to test out much of the source you're shipping now in an
open source model which others compile on foreign machines, and it's still
useful! I've had the same idea that Cameron apparently is considering
implementing (slight difference =), and it certainly seems useful to me.
--david
Cameron Laird
Christian Tismer <tis...@appliedbiometrics.com> wrote:
.
.
.
>Perfect situation. Funny ideas are finally those which have a
>chance to succeed. Or what would you have said about an SMS gateway
>if you were asked 10 years ago?
>
>And I think I heard you saying "ORL" some time in your exciting
>speech at SPAM7. "VNC" (virtual network computing) is also an
>example of funny stuff, but it works, and I use it all day :-]
>
>Now, let's try to make fun:
>What if there was not just a compiling service, but also some
>test bed available. And a port of the VNC server. I don't know
>SGI, but I can tell that running a linux app on a remote server
>which doesn't have a screen, just a virtual VNC X interface
>works great for me. I do compilations, and I play with user
>interfaces over our inhouse network from a WinNT box.
>Great stuff, this VNC.
>Is there an SGI port available?
>
>I have to admit that a remote service like this could be quite
>slow. But networks tend to become faster.
>I could imagine that one builds a test bed on his machine, with
>compiler, some virtual screen (maybe just a shell) for testing,
>and give this service away to customers for some payment
>(and free for Konrad, of course:)
>
>In the sense of "usenet", but interpreted as "how to make as
>much use of the net as possible", I think this is a challenge,
>and just a beginning.
.
.
This compilation service--well, for now, I just
want to *do* it, and am unwilling to focus my
attention to explain it.
So I'll change the subject, and simply emit sen-
tence fragments. What services can we reach through
the network? These are the things I think about:
* code-data dualites
* Tim O'Reilly does much more in <URL:http://
www.edventure.com/release1/1198.html> than
community demographics; he also describes
the successional ecology which transitions
from hardware to software to "infoware"
* the 'Net was built to facilitate remote
computation. E-mail immediately and sur-
prisingly became its killer app
* open {source,scientific results,Usenet
postings,public records,out-of-copyright
documents,...}; volunteer fire-departments;
number-theoretic calculations through team-
work; ...
A few times a year I want an HP-UX (for example)
compilation. Rather than spend the few thousand
dollars it'd take to have my own box, I'll invest
even more hours to construct a system for remote
service or co-operative computation or ..., as I
want it.
Frank Stajano
for Quentin and Tristan of VNC fame...)
[Cameron]
>> >(perhaps slowly) with this project. The project
>> >will create a (virtual) machine that takes source
>> >code and a target description (examples: "32-bit
>> >SGI"; "Digital Unix 4.0"; ...), and returns compiled
>> >objects. Would that help you, Konrad? There's no
>> >provision for exercising the object, but at least
>> >you could pass it on to your customers, right?
[Frank]
>> So you compile the code on this remote service (but you have nowhere
>> to try it out) and then ship it to the customers? And of course this
>> untested port willl work 1st time? And in -- of all things -- C? ;-)))
>>
>> Sorry Cameron, I can see from the tone of your post that it was meant
>> as a helpful community service, but it just looks too funny not no
>> make jokes about!
[Christian]
>Perfect situation. Funny ideas are finally those which have a
>chance to succeed. Or what would you have said about an SMS gateway
>if you were asked 10 years ago?
You are right right right.
>And I think I heard you saying "ORL" some time in your exciting
>speech at SPAM7. "VNC" (virtual network computing) is also an
>example of funny stuff, but it works, and I use it all day :-]
>
>Now, let's try to make fun:
>What if there was not just a compiling service, but also some
>test bed available. And a port of the VNC server. I don't know
>SGI, but I can tell that running a linux app on a remote server
>which doesn't have a screen, just a virtual VNC X interface
>works great for me. I do compilations, and I play with user
>interfaces over our inhouse network from a WinNT box.
>Great stuff, this VNC.
>Is there an SGI port available?
Dunno, ask the boys ;-)
>I have to admit that a remote service like this could be quite
>slow. But networks tend to become faster.
>I could imagine that one builds a test bed on his machine, with
>compiler, some virtual screen (maybe just a shell) for testing,
>and give this service away to customers for some payment
>(and free for Konrad, of course:)
Renting a bit of a foreign machine over the net and accessing it via VNC to
test my port to an architecture I don't have... Gee, that's cool!
Imagine me doing my best ESR impersonation and, bowing theatrically in your
direction, proclaiming in a loud voice: YOU ARE GOD!
How dumb of me not to have realised this straight away.
>In the sense of "usenet", but interpreted as "how to make as
>much use of the net as possible"
"If you can think of new ways to soak up more bandwidth, do it". Trust us
at ORL on this one, my friend... ;-))))
I worked for years on a distributed multimedia system where every
workstation had at least 4 cameras and 4 microphones...
>wishing-to-smell-a-virtual-Italian-coffee - ly y'rs - chris
This reminds me: when we were heavily into multimedia stuff, at ORL we once
had a guy whose tagline was "if it doesn't smell, it isn't multimedia"
Frank (http://i.am/filologo.disneyano) http://www.orl.co.uk/~fms
Cees de Groot
>(MS, Sun, IBM, etc). This gets you into an ugly circle. Writing
>portable ANSI C is hard enough, I can't even imagine with C++. Has
>anyone looked at hte groff code to see how UGLY this becomes?
I share your sentiments. I've done some work to get Jade (the SGML/DSSSL
engine by JC) under autoconf, and it is constantly breaking on various
versions of gcc/egcs - and I haven't seen much elegance either (ok,
this is also due to the sheer complexity of the application domain,
but still). The only way to make C++ usable is to prune the language so
much you get... Java ;-)
Personally, I don't care too much: I'm quite sure JPython is here to
stay and for a lot of things, it is already just as usable as CPython -
in a year or so, I'll be able to do well without the latter, whether in
C++ or C. My personal recommendation, though, is to stick with C.
--
Cees de Groot http://pobox.com/~cg <c...@pobox.com>
--- We're hiring Java developers => www.acriter.com
Magnus L. Hetland
> In article <7468hq$vhv$1...@nnrp1.dejanews.com>, zes...@my-dejanews.com
> writes
> ... C rather than C++
> >> Me too!
> >
> >I agree.
Who wouldn't... ;)
.
.
.
> >and I fully support Konrad's comments about problems with C++ compiler
> >availability. I'd be _very_ disappointed if Python goes C++
Has anyone thought about Objective C? (Just a thought...)
--
Magnus
Lie
Hetland www.pvv.org/arcadia <arc...@pvv.org>
Magnus L. Hetland
> Paul Jackson wrote:
> >
> > I don't think it's all or none on the question of "Python going C++".
>
> So true.
>
> Sigh. As the dust is settling on comp.lang.tcl about this same issue
> (C++ vs. C) for a different reason (a more modular Tcl core), the same
> arguments show up again here.
>
> It's time to get rid of some myths (uh, oh, I'm gonna be lynched!).
How about the myth: "C++ is really ugly"?
(Sorry -- couldn't resist ;)
>
> If the outcome is that Python 2 is written in Eiffel, that's fine too.
>
I guess so... But I can't resist yet again suggesting Objective C... A
minimal object-oriented extension to ANSI C, based on Smalltalk,
translatable into pure ANSI C. Very portable. In my opinion much more
elegant than C++... I must admit -- it might not be _quite_ as fast at
everything... Oh, well... I guess I'll stay away from the
implementation anyway. <sigh>
> -- Jean-Claude
Greg Ewing
>
> What is the problem that C++
> would solve for the implementers of Python?
The one of making the implementation simple, clear,
easy to understand, easy to maintain, easy to extend.
If that's not a good enough reason, I don't know
what is.
--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
gr...@cosc.canterbury.ac.nz
Paul F. Dubois
on stale data. I understand the latest versions of ECGS compile Todd
Veldhuizen's expression template library. If you can do that you can do
anything a Pythoneer would even dream of doing.
Note extendible lists, dictionaries are already implemented in the standard
template library. There would be lots less code to implement in a C++ Python
kernel. Instead of simulating polymorphism you could actually do it.
I know a lot of people say the same applies to Java, but there remains the
question of how well Java can "play" with components in other languages. Jim
told me at Spam VII that he didn't think JPython ever would. Whereas I
certainly can imagine a C extension object to allow use of the older kind of
extensions in a C++ Python.
Jim Hugunin
I don't remember saying that. What I might have said is that I don't think
JPython will ever support Python's current style of C-based extensions.
JPython already works very well with libraries written in C and C++ (and
Fortran through C as well, just like CPython), but those libraries have to be
wrapped up using the Java extension model -- JNI. The inability to (probably
ever) support CPython's current extension modules is clearly an advantage of
C++ over Java, but I wanted to make it clear that it's not quite as strong as
Paul was saying.
I'm not disputing the basic point of the message. If Guido were to start
work on a new Python implementation tommorrow that was supposed to REPLACE
the current implementation, I'd personally recommend that he choose C++ as
the implementation language. It has all the advantages Paul mentions, and
currently it is so much more mature than Java that it has both higher
performance and greater portability. The two are somewhat coupled actually.
It's getting hard to find a platform without any JVM, but on many of the more
obscure platforms performance can be 10-40X slower than C++. I still
personally believe that Java's current shortcomings are based more on its
immaturity than on fundamental design flaws and expect to see them fade away
over time.
Personally, I think that this discussion is premature. Guido is unlikely to
begin serious work on Python-2.0 until late 1999, probably early 2000. Both
C++ (at least the advanced features) and Java are sufficiently moving targets
that I don't think it makes much sense to discuss issues like compiler
availability and cross-platform portability without looking at the state of
the world at the time the decision is made.
My two-cents - Jim
Jason Orendorff
> Instead of simulating polymorphism you could actually do it.
I've been wondering about this. If Python2 were written in C++, would
virtual functions replace CPython 1.x's function tables? It seems
that change might make the type/class split rather difficult to heal.
CPython-doesn't-"simulate"-polymorphism-
it-*implements*-polymorphism-ly y'rs,
jason
G. David Kuhlman
Here is another concern with implementing Python 2.0 in C++:
Python is open source. Does anyone have experience with any
successful open source projects written in C++. OK, Mozilla, but I
don't think Mozilla has been open source long enough for us to
judge its success.
A previous message in this thread mentioned the SGML parser Sp by
James Clark (http://www.jclark.com). I also tried reading that
source code and found it impenetrable. I was unable to figure out
how to change it to do what I wanted. It is very ingenious code,
however, and Sp does its job well.
So I worry about how well others could contribute if Python were
written in C++.
That being said, I want Guido to have the freedom to choose the
implementation langauge he wants to work with. Guido's work and
attention is too valuable; we don't want him to get bored.
I'm interested in any comments about C++ and open source?
Andrew Dalke
> There's a molecular modeling package called NAMD written in C++. I
> forget what school it's at, I think it's UIUC. But it's nice clean
> legible code, easy to understand and modify.
Wow. Never thought I'll see a reference to NAMD on c.l.py.
The URL is http://www.ks.uiuc.edu/Research/namd/ and yes, it
is from UIUC. It's also the reason I even now misspell "name." :)
> my best guess is that it turned out well because the programmers
> had a lot of familiarity with the problem domain, and could design
> a reasonable class hierarchy on that basis.
Yes. Between the developers we had direct experience with 4 or 5
other programs and a stack of papers on previous implementations.
Mark Nelson, who did most of the implementation, even got a MS out
of it so it was good for something.
However, I should point out that "class hierarchy" is quite shallow.
There isn't much in the way of inheritance and very few virtual
functions. Classes are mostly used as ways to bundle data with
associated methods, and the only operator overloading is in the
Vector code and the parallel communications code (eg, so you can
say "msgDebug << variable" and have it sent to the log file on the
master machine).
For performance reasons all the Vector class code was replaced with
3-op math functions (but only after we verified that
the code worked) so most of the code is very C-like. That was a
deliberate design decision because most of our development experience
was in C. It doesn't use templates (well, maybe version 2 does now,
but I haven't taken a look at it), which I wanted, but in 1994 it
was hard to get C++ with working templates on the various
supercomputers we were using.
And we didn't know about template expressions which could have
let us keep the Vector classes hanging around.
In other words, we knew mostly what we were doing, we kept from
using features we didn't have much experience with and we chose
a subset of C++ that was available on the machines we needed to
support. I'm sure if Guido decides to implement Python 2.0 in C++
(which I am for, BTW) he'll do the same, and by then things like
exceptions, STL with its fast, built-in lists, dictionaries and
reference counting, and namespaces will be well-known, understood
and supported by all normal compilers.
Andrew Dalke
da...@bioreason.com
P.S.
(Warning: tirade but hopefully not flame inducer)
I don't think Java's going to be the main development
language on supercomputers/workstation clusters any time soon.
While I've heard proposals for doing that, they've usually seemed
to want to make Java more like C++. (It seems interesting that Java
people talk about approaching C++ speed and C++ people talk
about approaching Fortran speed. If hype were transitive,
shouldn't Java be approaching Fortran speed?)
Even when not talking about high end performance there are
things I've needed that Java doesn't support (how do you allocate
objects in specific shared memory? Can you lock a process to a
processor? How do you generate stereo graphics displays? Can
you map VR device inputs to synthetic GUI events?). Some of these are
hardware/OS dependent and thus unlikely to be supported by a Java
API any time soon. Should I use Java with OS specific extensions
(when will they be developed?) or stay with C++?
I'm guessing the former won't happen soon and that if it does
there will be a C/C++ API to those functions for a long time to
come. Since I like C++'s abilities tied with Python's flexibility,
I am against Python 2.0 being written in Java. Sorry Jim.
Will Ware
: ... Does anyone have experience with any
: successful open source projects written in C++.
: I also tried reading that
: source code and found it impenetrable. I was unable to figure out
: how to change it to do what I wanted.
There's a molecular modeling package called NAMD written in C++. I
forget what school it's at, I think it's UIUC. But it's nice clean
legible code, easy to understand and modify. I haven't got any real
experience with C++ myself; my best guess is that it turned out well
because the programmers had a lot of familiarity with the problem
domain, and could design a reasonable class hierarchy on that basis.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Will Ware email: wware[at]world[dot]std[dot]com
PGP fp (new key 07/15/97) 67683AE2 173FE781 A0D99636 0EAE6117
Friedrich Dominicus
>
> Here is another concern with implementing Python 2.0 in C++:
>
> Python is open source. Does anyone have experience with any
> successful open source projects written in C++. OK, Mozilla, but I
> don't think Mozilla has been open source long enough for us to
> judge its success.
KDE with the friendly help form QT which might become Open Source in the
near future, but for that take a look at www.kde.org
Regards
Friedrich
Friedrich Dominicus
> implementation langauge he wants to work with. Guido's work and
> attention is too valuable; we don't want him to get bored.
>
I don't think Guido will switch to another language as C, and I hope he
never ever will switch to C++.
I would be happy to see using Eiffel or Sather for this, but I guess
this will never happen too.
Regards
Friedrich
Garry Hodgson
> A previous message in this thread mentioned the SGML parser Sp by
> James Clark (http://www.jclark.com). I also tried reading that
> source code and found it impenetrable. I was unable to figure out
> how to change it to do what I wanted. It is very ingenious code,
> however, and Sp does its job well.
in general, i've found that well written c++ code is more, not less,
readable than equivalent c code. poorly written code is, well, poorly
written, whatever the language. now, i define "well written" as
optimizing the communication channel to the developer, cleanly and
clearly mapping the (OO) model of the problem to the code.
one can certainly write such code in C, but C++ provides constructs
that allow a higher level of abstraction. alas, it also provides
constructs
that allow a higher level of obfuscation. the trick is knowing the
difference.
--
Garry Hodgson too much fun...that's news to me
ga...@sage.att.com too much fun...how could it be?
Software Innovation Services a whole lotta things that
AT&T Labs i ain't never done
i ain't never had too much fun
M.-A. Lemburg
>
> Here is another concern with implementing Python 2.0 in C++:
>
> Python is open source. Does anyone have experience with any
> successful open source projects written in C++. OK, Mozilla, but I
> don't think Mozilla has been open source long enough for us to
> judge its success.
>
> James Clark (http://www.jclark.com). I also tried reading that
> source code and found it impenetrable. I was unable to figure out
> how to change it to do what I wanted. It is very ingenious code,
> however, and Sp does its job well.
That's no argument for or against any language: personal
coding styles differ and so do software designs.
> So I worry about how well others could contribute if Python were
> written in C++.
Given the fact that Guido's code is highly readable, I wouldn't
worry too much about this.
> That being said, I want Guido to have the freedom to choose the
> implementation langauge he wants to work with. Guido's work and
> attention is too valuable; we don't want him to get bored.
>
> I'm interested in any comments about C++ and open source?
See http://www.tcx.se for a very cool project (MySQL) which
uses C++ extensively to do cross-platform development.
BTW, wasn't there a project to turn Python into a Scheme
flavor (or somesuch) by Sam Rushing...
--
Marc-Andre Lemburg Y2000: 385 days left
---------------------------------------------------------------------
: Python Pages >>> http://starship.skyport.net/~lemburg/ :
---------------------------------------------------------
Andrew M. Kuchling
>G. David Kuhlman wrote:
>> So I worry about how well others could contribute if Python were
>> written in C++.
>
>Given the fact that Guido's code is highly readable, I wouldn't
>worry too much about this.
In addition, C++ might even wind up being more readable. At
IPC7, Paul Dubois presented C++ code for writing a Python extension.
If you've ever written a Python extension in C, you'll have noticed
that in complex functions the logic can get pretty convoluted because
of error handling. For example:
tuple = PyTuple_New(5);
if (tuple == NULL) {
/* exit */
}
list = PyList_New(5);
if (list == NULL) {
/* free tuple to avoid a memory leak */
/* exit */
}
...
if (someothererror) {
/* free both tuple and list */
}
C++ exceptions can help with this. It can also turn code like:
v = PyList_GetItem(list, 0);
if (v == NULL) return NULL;
into simply:
v = list[0];
Using C++ doesn't always condemn you to death-by-complexity. Just
most of the time...
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
Technology is a gift of God. After the gift of life it is perhaps the greatest
of God's gifts. It is the mother of civilizations, of arts and of sciences.
-- Freeman Dyson, _Infinite in All Directions_
Curt Hagenlocher
>
>in general, i've found that well written c++ code is more, not less,
>readable than equivalent c code. poorly written code is, well, poorly
>written, whatever the language. now, i define "well written" as
>optimizing the communication channel to the developer, cleanly and
>clearly mapping the (OO) model of the problem to the code.
I imagine that it depends on your definition of "well-written".
Looking at nearly any implementation of STL (or other template-
heavy code) makes me... well, physically ill is not too strong an
expression. Readable, my ass.
"'As readable as equivalent C code' is a perjorative-ly-yours,"
--
Curt Hagenlocher
c...@earthlink.net
Amit Patel
| Garry Hodgson wrote in message <3671344B...@sage.att.com>...
| >
| >in general, i've found that well written c++ code is more, not less,
| >readable than equivalent c code. poorly written code is, well, poorly
| >written, whatever the language. now, i define "well written" as
| >optimizing the communication channel to the developer, cleanly and
| >clearly mapping the (OO) model of the problem to the code.
|
|
| I imagine that it depends on your definition of "well-written".
| Looking at nearly any implementation of STL (or other template-
| heavy code) makes me... well, physically ill is not too strong an
| expression. Readable, my ass.
It's a good thing that STL is part of the system libraries so you
don't have to write (or read) that kind of application-level code.
It's amazingly twisted.
- Amit
Florian Weimer
> It's a good thing that STL is part of the system libraries so you
> don't have to write (or read) that kind of application-level code.
What do you do if you get one of these very complicated error messages
if you misused an STL feature? ;)
Felix Beer
>
>Here is another concern with implementing Python 2.0 in C++:
>
>Python is open source. Does anyone have experience with any
>successful open source projects written in C++. OK, Mozilla, but I
>don't think Mozilla has been open source long enough for us to
>judge its success.
KDE, shore, HylaFax, wxWindows, ...
I don't think the success of open source projects is primarily a
language issue, as long as the language chosen is widely available,
which seems to be the case for gcc/g++ and friends.
regards,
Felix
jeff templon
Oh, the horrors?
Who is thinking about recoding Python 2.0 in C++? Not GUIDO?
That's what I get for going off and doing physics for awhile. Then,
I get involved with a big data analysis project with a bunch of
sweaty-palmed postdocs who want to REWRITE THE ANALYSIS CODE
in C++ ... a language for which compilers must be HAND VALIDATED
since the language is SO DURN CONTORTED that you can redefine
the SPACE CHARACTER to be an operator. And these people want
to REWRITE a WORKING CODE and expect it to get CORRECT
PHYSICS RESULTS in THEIR LIFETIME.
So, what do I do? I say, "hey if you really want to rewrite it, you
should code it up in python; once you understand the pieces,
code the time critical sections up in C as python modules.
Use Python to do the OO interfacing, since you'll NEVER get
it right in C++".
Then, I pop over to the Python newsgroup to see how my old Python
friends are getting on (I used to bicycle in the same gate, on my
way to NIKHEF, that Guido used on his way to CWI ... I was a pre
1.0 python freak).
And what is one of the first messages I read?? Some yahoo talking
about rewriting Python in C++????
aaaaaauuuuuuuuuuuuuuuuggggggggggggggghhhhhhhhhhhhhh!
I think I'll go bury my head again. Maybe someone can sell me a
used Perl.
Jeff
guido: dit kun je toch niet MAKEN??
Boris Borcic
> That's what I get for going off and doing physics for awhile.
Just thought I'd point out a better physicist's line
against C++. More irony, less violence, greater power.
Cheers,
Boris Borcic
Steven D. Majewski
On Fri, 18 Dec 1998, Boris Borcic wrote:
>Subject: C++ is a contradiction in terms (Re: C++? What?)
No Boris. You have to take it exactly literally. Post-increment:
Increment (enhance) the value of C and then use the un-enhanced version.
(sorry to recycle an ancient joke, but sounds like Boris missed it
the first four or five times around!)
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Department of Molecular Physiology and Biological Physics |---
---| University of Virginia Health Sciences Center |---
---| P.O. Box 10011 Charlottesville, VA 22906-0011 |---
Redmond, WA (AP) -- Microsoft announced today that the official release
date for the new operating system "Windows 2000" will be delayed until
the second quarter of 1901.
Jeff Templon
Whoops!
"jeff templon" <tem...@peachnet.campus.mci.net> writes:
> Then, I pop over to the Python newsgroup to see how my old Python
> friends are getting on (I used to bicycle in the same gate, on my
> way to NIKHEF, that Guido used on his way to CWI ... I was a pre
> 1.0 python freak).
I got to wondering exactly how far back I went, and WHOOPS (egged
face): I wasn't a pre-1.0 python freak. It looks like my first
version was 1.0.1, so I missed being pre-1.0 by about two months.
My first mailing list post was on March 4, 1994, concerning the
following code:
#
# rps.py - remote ps script
# prints owner, size, CPU time used, and command name
#
# give as first argument the remote machine name
#
import regsub, os, sys
string = 'rsh '+ sys.argv[1] + ' ps uax | grep -v root'
psfile = os.popen(string,"r")
lines = psfile.readlines()
for i in range(0,len(lines)):
lines[i][:10] + lines[i][24:30] + ' ' + regsub.sub('\012','',lines[i][50:])
psfile.close()
I then got raked over the coals by Guido, Tim, and Steve. Fun to go
back and read that stuff.
def main():
while 1:
newsgroup.apologize()
main()
J "not-pre-1.0-unless-using-ABC-counts" T
Boris Borcic
>
> On Fri, 18 Dec 1998, Boris Borcic wrote:
>
> >Subject: C++ is a contradiction in terms (Re: C++? What?)
>
> No Boris. You have to take it exactly literally. Post-increment: [...]
>
> (sorry to recycle an ancient joke, but sounds like Boris missed it
> the first four or five times around!)
In contrast to you, Steven, I'll start by assuming that you know what you are
talking about. Then there is a misunderstanding : I've learned C both in and
out of school as a programming language, and was as able as the next bloke to
catch the "insider's" joke in the name of C++.
While I did come across a product known under the name of "Lightspeed C",
it hasn't occured to me until recently that the name of that programming
language could be taken as en allusion to the physicist's standard name
for the universal speed limit. As a consequence, it escaped me completely
that this interpretation of the programming language's name could fare
as the standard *naive* interpretation that people-in-the-know, like you,
would take as a pathetic lack of wit and culture; all the more so 1) because
I was under the impression that C's name had a completely different standard
explanation, 2) because I learned assembly language before C, and 3) because
programming language speed has always appeared to me, as very secondary,
and almost irrelevant when compared to programming language elegance.
As for my coming up with "C++ is a contradiction in terms", it should
be taken less as a judgment on the language(s) itself, that I have religiously
avoided, than as a judgment on the fancy for that name, by non-programmers
that have authority on what programming languages programmers should use.
You might have noticed that I refrained from expressing opinion about
C++ relevance to python 2, and that I only threw in that line when special
context permitted it.
What I can't quite fathom, Steven, is by what reasoning you could came to the
conclusion that I had missed the interpretation of C++ as "postincrementation
of C", while still understanding that by "contradiction in terms", I was
alluding to a famous tenet of special relativity. To me, this looks like
a missing sanity check.
Sincerely,
Boris Borcic
--
"Hope achieves the square root of the impossible"
Tim Peters
>>> Subject: C++ is a contradiction in terms (Re: C++? What?)
[Steven D. Majewski]
>> No Boris. You have to take it exactly literally. Post-increment: [...]
>>
>> (sorry to recycle an ancient joke, but sounds like Boris missed it
>> the first four or five times around!)
[Boris Borcic]
> In contrast to you, Steven, I'll start by assuming that you know
> what you are talking about.
> ... [and similar frightfully earnest defense] ...
Now you've done it, Boris! You're in big trouble when Uncle Timmy butts
into a thread. Well, OK, no trouble at all, but play along and stop this
anyway. Steven was just sharing an old joke, on the chance that you *had*
missed it. It was a friendly and well-intentioned post. I know this,
because Steven's been accusing me of a pathetic lack of wit and culture for
the better part of a decade now, and there's no mistaking it when he's
*really* attacking <wink>.
battling-over-amusing-ways-to-interpret-a-three-character-string-
is-not-the-true-meaning-of-christmas-ly y'rs - tim
Boris Borcic
> Well, OK, no trouble at all, but play along and stop this
> anyway.
Thanks for your gentle intervention.
I was sorry I posted this not two hours later, but too
far from cancel power to do anything about it until now.
You know, christmas, flu, and being pissed off with anglo-
american command *still* prefering to kill uncounted
irakis over challenging the hate-figure in single combat,
as they should do if they believed in a minimal meaning
for "men are born equal in rights" and in any of their
implicit or explicit war goals.
Which, admittedly, has nothing to do with Steven nor C++
what's-wrong-with-reversing-the-mapping-of-chain-of-command
-to-battle-order-ly yours,
Boris
--
"After Einstein, c++ is a contradiction in terms"