This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | jkrukoff |
|---|---|
| Recipients | PiDelport, georg.brandl, jkrukoff, ncoghlan, terry.reedy |
| Date | 2008年04月22日.18:25:28 |
| SpamBayes Score | 0.002876754 |
| Marked as misclassified | No |
| Message-id | <1208888730.57.0.830098156043.issue643841@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I've been following the py3k maliing list disscussion for this issue, and wanted to add a note about the proposed solution described here: http://mail.python.org/pipermail/python-3000/2008-April/013004.html The reason I think this approach is valuable is that in all of the proxy classes I've written, I'm concerned about which behaviour of the proxied class I want to override, not which behaviour I want to keep. In other words, when I proxy something, my mental model has always been, okay, I want something that behaves just like X, except it does this (usually small bit) differently. This is also why I expect my proxies to keep working the same when I change the proxied class, without having to go and update the proxy to also use the new behaviour. So, yeah, very much in favor of a base proxy class in the standard library. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年04月22日 18:25:31 | jkrukoff | set | spambayes_score: 0.00287675 -> 0.002876754 recipients: + jkrukoff, georg.brandl, terry.reedy, ncoghlan, PiDelport |
| 2008年04月22日 18:25:30 | jkrukoff | set | spambayes_score: 0.00287675 -> 0.00287675 messageid: <1208888730.57.0.830098156043.issue643841@psf.upfronthosting.co.za> |
| 2008年04月22日 18:25:29 | jkrukoff | link | issue643841 messages |
| 2008年04月22日 18:25:29 | jkrukoff | create | |