On Wed, Apr 25, 2012 at 7:41 PM, M.-A. Lemburg
Nick Coghlan wrote:
On Wed, Apr 25, 2012 at 10:55 AM, Steven D'Aprano
wrote: In my opinion, this is an attractive nuisance.
-1 on the feature.
Agreed (and my preferred idiom for all the cited cases is also "always define the Python version, override at the end with the accelerated version").
IMO, defining things twice in the same module is not a very Pythonic way of designing Python software.
Left aside the resource leakage, it also makes if difficult to find the implementation that actually gets used, bypasses "explicit is better than implicit", and it doesn't address possible side-effects of the definitions that you eventually override at the end of the module.
Python is normally written with a top-to-bottom view in mind, where you don't expect things to suddenly change near the end.
This is why we introduced decorators before the function definition, rather than place them after the function definition. It's also why we tend to put imports, globals, helpers at the top of the file.
I agree overwriting at the end isn't ideal, but I don't think allowing returns at module level is a significant improvement. I'd rather see a higher level approach that specifically set out to tackle the problem of choosing between multiple implementations of a module at runtime that cleanly supported *testing* all the implementations in a single process, while still having one implementation that was used be default. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia