why no ++?

Alex Martelli aleax at aleax.it
Wed Aug 8 14:22:05 CEST 2001


"Quinn Dunkan" <quinn at retch.ugcs.caltech.edu> wrote in message
news:slrn9n0lum.im5.quinn at retch.ugcs.caltech.edu...
    ...
> >> fp.read_line
> >> s := fp.last_string
> >>
> >> I haven't decided yet if this consistency is of the hobgoblin variety
or
> >not.
> >
> >To me, it seems cleverly designed to maximize threading
> >problems/race-conditions/horrid-bugs.
    ...
> One counter argument is that if state-changing operations are isolated and
> seperate from queries it's easier to lock your state changing operations,
and
> then let the rest of the code that uses the queries run in parallel.

But too often the 'query' I really NEED to do implies state-change
as well, such as "now get me the NEXT random number" (or NEXT line
from the fine, or NEXT item in whatever iterator).  Separating
a (locked) advance-iterator-and-don't-tell-me from a just-tell-me-
the-current-state is a crazy way to work with iterators of any
kind, because you'll _always_ need to lock the operation-pair to
'atomize' it, so it SHOULD be packaged up as a single operation
in the first place!

> Presumably Meyer has more rationale in OOSC so I don't have an opinion
until
> I've read that (though I've found some of Meyer's rationales unconvincing
in
> the past).

He's a *very good* rationalizer, but some of his language-design
ideas are so (expletive deleted) that not even a GREAT rationalizer
would manage to convince people with a criticial bent (it would
take an INSANELY GREAT rationalizer, and there's very few of
THOSE around -- Knuth, Raymond, maybe Kernighan, and who else...?).


Alex






More information about the Python-list mailing list