"Chris Mellon" <[EMAIL PROTECTED]> writes: > 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. >> But I don't typically wish for this sort of intent to be made >> explicit. TMI! I used "with" for *many* years in Lisp, since this >> is how non-memory resource deallocation has been dealt with in Lisp >> since the dawn of time. I can tell you from many years of >> experience that relying on Python's refcounter is superior. > 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. >> This just isn't true. For many years I have not had to explicitly >> close files in Python. Nor have I had to do so in C++. They have >> been closed for me implicitly. "With" is not implicit -- or at least >> not nearly as implicit as was previous practice in Python, or as is >> current practice in C++. > 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. >> Purify tells me that I know more about the behavior of my code than >> you do: I've *never* had any memory leaks in large C++ programs that >> used refcounted smart pointers that were caused by cycles in my data >> structures that I didn't know about. > 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. >> > There's no particular reason why Lisp is any better for AI research >> > than anything. >> Yes, there is. It's a very flexible language that can adapt to the >> needs of projects that need to push the boundaries of what computer >> programmers typically do. > 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. >> And where are you getting this from? I don't know anyone who claims >> that any commonly used dialect of Lisp isn't *really* Lisp. > 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 -- http://mail.python.org/mailman/listinfo/python-list
