On 3 April 2015 at 18:21, Nick Coghlan <ncoghlan at gmail.com> wrote: > That means I'm now OK with monkeypatching __build_class__ being the > only way to get dynamic hooking of the class currently being defined > from the class body - folks that really want that behaviour can > monkeypatch it in, while folks that think it's a bad idea don't need > to worry about. [snip] > PEP 422 has never been approved - it's only ever been Draft or > Deferred (and now Withdrawn). If you would like to take it over and > champion it as a competitor to PEP 487, I'd be fine with that, I just > no longer think it's a good idea myself. [snip] > Given my change of heart, I believe that at this point, if you were > willing to champion a revived PEP 422 that implemented the behaviour > you're after, that would be ideal, with monkeypatching the desired > behaviour in as a fallback plan if the PEP is still ultimately > rejected. Alternatively, you could go the monkeypatching path first, > and then potentially seek standardisation later after you've had some > practical experience with it - I now consider it an orthogonal > capability to the feature in PEP 487, so the acceptance of the latter > wouldn't necessarily preclude acceptance of a hook for class > postprocessing injection. Heh, editing fail. Writing out this post in full made me realise the last of these options was a potentially reasonable path forward, but I didn't go back and correct the earlier sections where I was viewing the situation differently. So if the post reads a self-contradictory, that's because it is, but the last one is the one that best reflects my current thinking :) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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