> Guido.van.Rossum@cwi.nl writes:
> | I'd like to see if I can bring this discussion to a conclusion.
> | Rather than quoting the various elaborate messages, I'll try to
> | summarize the issues:
> |
> | (Control): It's important to know at cleanup time whether and how the
> | user's suite was completed, and if it raised an exception, which one.
> |
> | (Cleanliness): It's important to hide from the end user the machinery
> | that's used to implement the transaction or locking protocol.
> |
> | (Nestability): It must be possible to safely implement nested
> | transactions.
> This has been an interesting discussion. On one hand, I look forward to
> to trying out these interesting new features, but on the other hand, I
> wonder if they're really worth what they will cost.
> I have found python a fairly simple and pleasant language to learn.
> I think its complexity is still just barely within the grasp of ordinary
> programmers, unlike for example C++, which the ordinary person may use
> but almost surely cannot fully comprehend. Rather than creep closer to
> the edge of this problem, I'd prefer to see transaction programmers put
> up with untidy code.
The point of my proposal is to provide a mechanism that can be used to
abstract complex control strategies, such as transactions or critical
regions, so that ordinary programmers do not need to knowledgable
about them. With the proposed enhancements, it will be possible for
people who understand topics like transaction management to make it
possible for ordinary programmers to use transactions far more easily
than otherwise.
Python has a number of advanced features, such as operator
overloading, overloading of __getattr__ and __setattr__, and the
ability to define new kinds of callable objects that allows people who
understand their use to provide resuable tools that make other
programmer's jobs much easier. The proposed enhancement is very much
in the spirit of these features. I think there is room for advanced
features that can be used by some people to build tools for others
that make their programming task easier and more enjoyable.
Designing reusable tools, like transaction objects, will always
require more expertise than writing "ordinary" programs. That doesn't
mean we shouldn't provide the tools to facilitate this sort of thing.
> In this respect I found the original proposal (cf. Jim Fulton) at least
> more generally interesting and less burdened with special magic member
> functions.
Python is *full* of special member functions. In fact, that's what
object protocols are about. Objects agree to provide certain services
(e.g. special member functions) so that they may be applied in given
contexts. Perhaps it would be better if __enter__ and __leave__ were
simply named enter and leave, so that they would appear less magic? I
personally don't see a compelling reason for the surounding
underscores in this case.
> If that means setting the idea aside for a while, maybe
> that's not entirely a bad thing.
It would be bad for me. It would be bad for others who are trying to
do the sorts of things that I'm doing. I don't see that the new
feature has to be a burden to "ordinary programmers". If someone
doesn't need to implement this sort of control abstraction, then there
is no reason why they should fully comprehend the feature.
--
-- Jim Fulton jfulton@mailqvarsa.er.usgs.gov (703) 648-5622
U.S. Geological Survey, Reston VA 22092
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.