why no ++?

[Alex Martelli]

"Markus Schaber" <markus at schabi.de> wrote in message
news:1028525.ia2DhmKxfE at lunix.schabi.de...
    ...
> >> 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.
>
> Only when you consider that in a Python/C/Java-like
>   s = fp.read_line()
> the internal implementation of fp.read_line() is guaranteed to be
> atomary in execution.

Atomic.  Yes, exactly: any kind of iterator designed to be
used in a threaded environment can make its own operations
atomic -- and that's exactly how it should be, in the holy
names of Encapsulation, Information Hiding, and so on.  The
crazy idea of splitting a single operation into two because
'something that changes state MUST NOT return a value' rules
out such productive encapsulation & information hiding.


> This may be the case in stackles pyhton green threads, and in java
> using synchronized, but is not the general case.

The point is not 'the general case', is that keeping the
logical unit 'advance state and tell me the new state' as
ONE operation *ENABLES* atomicity to be encapsulatedly
implemented and offered if and when that's needed.

Python's built-in file objects currently do NOT ensure
atomicity (they do Py_BEGIN_ALLOW_THREADS &c within the
.readline implementation), but that's documented.  I
can wrap such an object into an object which does
assure atomicity, or provide my own C-coded object
that does so.  If client-code was forever calling
two methods when meaning really one, that would not
be feasible.

> The most often solution is that read_line() internally does some
> locking, or specifies in the documentation that only one thread at a
> time uses it.

There's a world of difference between an object that
is designed for multi-threaded use, and encapsulates
its own locking (or whatever) internally, and one
which isn't (and documents the fact, and requires
client-code to handle all the locking chores).  Only
atomic (and therefore, a fortiori, UNITARY) operations
to change-state-AND-return-value *enable* the former
(the latter is always a possibility, and quite
appropriate when use from multiple threads is not
an important design constraint).

Forbidding such operations, as Meyers would, forbids
precious classes such as Python's wonderful Queue.
Mind-blowing crazy, if you ask me.


Alex