Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: This is a huge thread and I don't have time to look at the entire patch.
However, it seems like the main purpose of the proxy class is to work around a basic deficiency in Python. Now, if this is a purposeful omissions (i.e. defined as part of the language), then a proxy class makes sense. If not, then you should probably work to fix the implementation. In general, the concept of a base proxy mixin makes sense if it's generic enough and flexible enough to be of wider use to Python programmers. One measure of that might be to re-implement the existing proxy-like classes to use this mixin class. If that can't be done, then this is too specialized (or too unproven) and should probably be a cheeseshop module first. I'm also uncomfortable with adding a new typestool module, mostly because we have a types module. I know they're there for different purposes, but still, it seems ugly to me. On top of that, adding a module for a single class seems like overkill. Do you have any ideas about where this might go in an existing module? Overall, I'm -0 on adding this to Python. Guido should have the final say though. I'm knocking this down to critical so it won't hold up the betas. Other than the refactoring, it seems like adding a proxy class, while being a new feature, is isolated enough that it could go in after beta. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue643841> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
