while true: !!!

[Alex Martelli]

"Carsten Geckeler" <nospam at no.spam> wrote in message
news:mailman.977180344.10242.python-list at python.org...
> On Mon, 18 Dec 2000, Steve Lamb wrote:
>
> > On Mon, 18 Dec 2000 17:05:51 +0100, Alex Martelli <aleaxit at yahoo.com>
wrote:
> > >I think it would be inconsistent, un-Pythonic, to add a fundamental
type for
> > >'conceptual' reasons, without any practical, measurable benefit.  For
> > >example, Python does away with the distinction between 'a character'
and 'a
> > >string of length 1' -- a distinction that is religiously maintained in
C,
>
> Not fair!  C is a lowlevel language (relatively to interpreter languages
> as Python etc.).  In C you can say

C is a low-level language, Java a bit less so, Icon even less, and
Haskell could hardly be accused of being very low-level -- they all
distinguish a character from a stringth of length 1 as fundamentally
different datatypes, as do many, indeed most, other languages.

My claim is that Python is simpler, clearer, and MORE effective,
for NOT trying to draw this level of distinction.


> s[3] = char
> Do you know anything faster than this?  It just writes the byte char into
> the memory space pointer str + 3.  In most cases strings do consist of
> chains of bytes in memory.

Not sure what you mean by 'chain' here -- Haskell is the only one
of the languages I've listed that models strings as _lists_ (aka
linked lists, aka chains) of characters, most others (excluding
some Lisp dialects & variants) normally preferring to model them
as _arrays_ (aka blocks, &c) of characters (what _Python_ calls
'lists' are actually flexible arrays, which further confuses the
terminology).

Modeling character as a fundamental datatype, distinct from a
1-character string, is clearly NOT something that languages
do just for performance reasons -- in Java, strings are not
mutable, so the idiom you quote does not translate, yet it still
models character as a separate datatype; Haskell's strings-as-
chains is anything BUT well-performing... yet, it STILL models
character as a separate datatype.

So it's clearly not a sacrifice that language designers endure
just because it will enhance their performance... some must
believe it's a GOOD distinction to draw.  Python (and Perl
and Tcl, just to name a couple others) disagree -- and I
think they're right.


> Please, don't be so mean to C.  It's such a nice programming language!
> Remember, Python itself is programmed in C.  ;)

I program in C when I must (though I'd much rather take a
step up to C++, which I can in most situations but *NOT* when
I want my Python extensions to be taken seriously by the
Python community, alas...).  That doesn't mean I have to
_like_ it:-).


> But to your point:  If you are sure that your string is always shorter
> than 79 characters, it'n no faster way than doing it as C.  No overhead
> due to range checking and reallocating.  But of course, from the everyday
> user's point, interpreter languages as Python or Perl do a nicer job.  But
> every language has it's field of appliance.  Just imagine programming a OS
> kernel in Python... ;)

I can at least imagine programming it in C++ (BeOS) or even, if need
be, in Objective C (Next) -- in both cases, with a C-like subset
available for the very lowest portions of the job, but a semi-decent
higher-level approach for most of it.


Alex