how to count lines in a file ?

[Alex Martelli]

On Thursday 25 July 2002 11:46 pm, Richard Jones wrote:
	...
> I think the major problem that we're running into here is that before there
> was GC, the refcounting-based cleanup of objects was clear,
> straight-forward and reliable. Now it's not clear when objects are cleared
> up. That's a fairly major problem for some of us old-timers (and, quite

Yes, I've witnessed this panic reaction at other times, most widely in the
migration (still going on right now) from Microsoft's COM to their .NET.

COM is defined with reference count semantics (a bit stricter than Python's
in that counts are per-interface rather than per-object, but that's a minor
difference in this context).

.NET is defined with generic GC semantics, and if you consider the likely
possibility of _distributed_ systems, it's even more important in their case.
Distributed variants of COM never scaled up decently because of the
synchronization implications of RC -- and the distributed semantics was
often subtly different from the local case, too, at least in terms of timing.

In other words, RC was truly hellish (over and above the reference loops
and so on) and moving to generic GC a *huge* win in the COM to .NET
transition, rather than just a neat one for Python.

And for all that -- "some of them old-timers" (not me, as one of my very
first job tasks had been to consider how to design hardware help for GC,
and that was back when GC basically meant "mark and sweep" to most
guys [at least for sure most _hardware_ guys]) are STILL bitching and
moaning to this day.

> possibly, a lot of newbies) to come to terms with. I hadn't realised that

Don't worry about newbies -- they're likely to come from Java, these
days, thus with full exposure to general GC.  If they've had no previous
programming exposure, they don't particularly expect "the computer" to
clean up after them anyway -- they're used to, e.g., explicitly closing
applications and documents, the idea of explicitly calling .close() on
some object that needs to be closed is perfectly natural.  C (if there
are any more newbies coming from C) also requires explicit cleanup,
much more fussily so than Python too.

No, the problem is with reasonably experienced programmers -- not
experienced enough to have worked extensively in, say, Java, or Lisp,
or Smalltalk, but with experience in languages and systems that do
rely on reference counts (or in some cases stack allocation, like C++).

> GC threw such a big, ugly spanner in the works :(

It's not as bad as it looks.  I wish there was some slightly handier
way to express try/finally, yes -- say the equivalent of atexit but
applied to exiting the current function, to avoid the deep nesting
and open/close separation that try/finally may require:

a = open('a')
try:
    b = open('b')
    try:
        c = open('c')
        try:
            process(a,b,c)
        finally:
            c.close()
    finally: 
        b.close()
finally:
    a.close()

Since flat is better than nested, I *DO* dream of being able to
express this very common structure without all the indents.  Say
that 'onclose' was a new keyword, this would become:

a = open('a')
onclose: a.close()

b = open('b')
onclose: b.close()

c = open('c')
onclose: c.close()

process(a,b,c)


Now THAT is something I would find vastly superior, both to the
deep obscuring nesting that try/finally requires, and to CPython's
(and C++'s) idea of relying on destructors executing implicitly
"at the right time".  Admittedly "onclose" is a wretched choice for
a keyword.  "finally:" without an accompanying "try" would be
neat but perhaps might mask some syntax errors.  But, the
semantics' the thing.  Oh well.


Alex