Armin Ronacher wrote: > Hi, > > Nick Coghlan <ncoghlan <at> gmail.com> writes: > >> One of the tasks where classic classes are currently far superior to >> new-style classes is in writing proxy classes like weakref.proxy - cases >> where nearly all operations need to be delegated to some other object, >> with only a few being handled via the proxy type object itself. > Yes. I stumbled upon that multiple times when writing proxies for thread > locals. The solution I came up with is rather ugly but works at least: > > http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/local.py#L202 > > The main problem with such proxies is that especially builtin types perform > various type checks which break proxies sooner or later anyways (currently even > abstract base classes implementing a compatible interface). So as soon as you > start doing something like some_list + proxy_to_list you get a TypeError. What version are you using, and are your proxies correctly implementing all the __r*__ versions of the methods? While there are still some cases where types in the standard library raise TypeError directly instead of returning NotImplemented, they're generally pretty good about playing well with others (see the test_typetools.py file attached to the tracker item for #643841) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4