Chris Mellon said:
Obviously. But theres nothing about the with statement that's
different than using smart pointers in this regard.
Sure there is -- smart pointers handle many sorts of situations, while
"with" only handles the case where the lifetime of the object
corresponds to the scope.
I question the relevance of your experience, then.
Gee, thanks.
Refcounting is fine for memory, but as you mention below, memory is
only one kind of resource and refcounting is not necessarily the
best technique for all resources.
I never said that it is the best technique for *all* resources. Just
the most typical ones.
You still don't have to manually close files. But you cannot, and
never could, rely on them being closed at a given time unless you
did so.
You could for most intents and purposes.
If you need a file to be closed in a deterministic manner, then you
must close it explicitly.
You don't typically need them to be closed in a completely fool-proof
deterministic fashion. If some other code catches your exceptions and
holds onto the traceback then it must know that can be delaying a few
file-closings, or the like.
The with statement is not implicit and never has been. Implicit
resource management is *insufficient* for the general resource
management case. It works fine for memory, it's okay for files
(until it isn't), it's terrible for thread locks and network
connections and database transactions. Those things require
*explicit* resource management.
Yes, I agree there are certain situations in which you certainly want
"with", or something like it. I've never disagreed with that
assertion at all. I just don't agree that for most Python code this
is the *typical* case.
To the extent that your code ever worked when you relied on this
detail, it will continue to work.
I've written plenty of Python code that relied on destructors to
deallocate resources, and the code always worked.
There are no plans to replace pythons refcounting with fancier GC
schemes that I am aware of.
This is counter to what other people have been saying. They have been
worrying me by saying that the refcounter may go away and so you may
not be able to rely on predictable object lifetimes in the future.
Nothing about Pythons memory management has changed. I know I'm
repeating myself here, but you just don't seem to grasp this
concept. Python has *never* had deterministic destruction of
objects. It was never guaranteed, and code that seemed like it
benefited from it was fragile.
It was not fragile in my experience. If a resource *positively*,
*absolutely* needed to be deallocated at a certain point in the code
(and occasionally that was the case), then I would code that way. But
that has been far from the typical case for me.
I'm talking about Python refcounts. For example, a subtle resource
leak that has caught me before is that tracebacks hold references to
locals in the unwound stack.
Yes, I'm aware of that. Most programs don't hold onto tracebacks for
long. If you are working with software that does, then, I agree, that
sometimes one will have to code things more precisely.
If you relied on refcounting to clean up a resource, and you needed
exception handling, the resource wasn't released until *after* the
exception unwound, which could be a problem. Also holding onto
tracebacks for latter processing (not uncommon in event based
programs) would artificially extend the lifetime of the resource. If
the resource you were managing was a thread lock this could be a
real problem.
Right -- I've always explicitly managed thread locks.
I really have no desire to code in C, thank you. I'd rather be coding
in Python. (Hence my [idle] desire for macros in Python, so that I
could do even more of my work in Python.)
In this particular conversation, I really don't think that theres much
to say beyond put up or shut up.
I think your attitude here is unPythonic.
The experts in the field have said that it's not practical.
Guido has occasionally said that he might consider a macro facility
for a future version of Python. Do these so-called experts know
something that he doesn't?
If you think they're wrong, you're going to need to prove it with
code, not by waving your hand.
I have existence proofs for them working well in a number of other
languages.
That doesn't make Lisp any better at AI programming than it is for
writing databases or spreadsheets or anything else.
Well, Lisp is also good for those things too. Lisp is good for just
about everything.
Except that it wasn't for scripting when I first learned Python, as
the start-up times on the Lisp-based competition was painfully slow.
Guile seems to start up quickly enough these days, but it doesn't seem
to be very widely used.
The language of the future will not be Common Lisp,
Yes, that's for sure.
and it won't be a well known dialect of Lisp.
It won't be *any* dialect that exists today, though, it is likely to
be derived from an existing one, and may share its name.
It will have many Lisp like features,
Yes, definitely.
and "true" Lispers will still claim it doesn't count, just as they
do about Ruby and Python today.
I'm a true Lisper (I haven't programmed much in Lisp in some time, but
I still think in Lisp, it being the one true language of programming
thought after all), and I claim that Python and Ruby are tantamount to
dialects of Lisp. Dialects that are sadly missing macros.
|>oug
