On Jul 24, 2005, at 5:00 AM, Bengt Richter wrote: > Actually, it's not just the "magic" methods. [...]
Thanks for the clarification/explanation =) > This looks a little strange because the repr of the bound method > includes a repr of the thing bound to, > which returns the Edit/View presentation (after the 'of' above). > (A possible reason to consider using just __str__ and letting > __repr__ be). Yea, I must apologize, I pasted in a slightly different version of the class in my original email than I intended to...I fully understand the difference between __str__ and __repr__ and that bit of code where I attempted to bind to both was me attempting to discern exactly what was going on. The "real" version would only be binding to __str__ and leaving __repr__ alone so it could be used as intended =) > A function's __get__ method will deliver a bound method if the lookup > is via an inst, or an unbound method if the lookup is via the > class, in which > case None is passed to __get__ instead of the instance. > > The upshot is that you can create descriptors __str__ and > __repr__for your class that will > return bound methods using __str__ and __repr__ function attributes > of your instance (if they exist) > instead of the normal class attributes, and we can chose from > several normal class attributes according > to a general mode flag of the class. [big-arse snip of code/output] I half-understood this and what followed, but that's my fault and not that of your explanation. Honestly, I'm still trying to elevate my Python knowledge from a primarily quick-scripting level to one suitable for larger applications (or at least, more intelligent scripts =)). Specifically with things like descriptors and their ilk, I need to reread the various docs and PEPs out there. But, thanks for the detailed example, and you can be sure I'll return to it in the near future after some more reading. > You could use this kind of thing in a base class and specialize > in subclasses to override stuff, and you can do other stuff too. > Your choices are more varied that you probably thought ;-) Oh, I know there's a whole host of ways to accomplish this, I just tend to get narrowly focused on a single option or couple of options for stretches of time, heh. >> And ideally I wanted to be able to hold a collection of these objects >> and toggle them all to one state or the other, then bandy them about >> > ^^^^^^^^^^^^^^^ > does that mean all instances with a single toggling action, or each > individually? You could have both. I.e., a general mode flag and the > ability to assign an arbitrary __str__ and/or __repr__ override for > a particular instance. See example, where all are toggled by default. Well, either, depending on how flexible I want the overall design to be, but primarily all at once. E.g. I'd have a Page or PageBody container class holding a bunch of (implementing the same interface) objects as discussed, and would want all of those sub-objects to be in the same mode. In other words...a page is either displaying text fields for editing, or plain text for display (but with myriad form elements, not just text fields, of course). Thanks again, Jeff -- Jeffrey E. Forcier Junior Developer, Research and Development Stroz Friedberg, LLC 15 Maiden Lane, 12th Floor New York, NY 10038 [main]212-981-6540 [direct]212-981-6546 http://www.strozllc.com This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No right to confidential or privileged treatment of this message is waived or lost by any error in transmission. If you have received this message in error, please immediately notify the sender by e-mail or by telephone at 212.981.6540, delete the message and all copies from your system and destroy any hard copies. You must not, directly or indirectly, use, disclose, distribute, print or copy any part of this message if you are not the intended recipient. -- http://mail.python.org/mailman/listinfo/python-list
