Sybren Stuvel wrote: > > -Get rid of extra variables by shifting them inline (e.g.: > > a=1;b=2;c=a+b --> c=1+2) > > This is already excess functionality IMO.
I don't think that Rex talked about his programming style but about three and only three refactoring methods survived in BRM from ~30 Fowler described in his book. By the way I can't remember the one you picked up but I remember the reverse i.e. introducing intermediate variable names for readability and debugging purposes. Instead of writing f(g(h(...))) it is sometimes adaequate to write x = h(...) f(g(x)) I use this a lot in particular in C++. Optimzing compilers eliminate runtime penalties. This is of course different in CPython. In case of BRM I'm not sure why it is particular hard to implement "Move Method" for instance? BRM is shipped with a lot of testcases which is good but neither defines requirements nor leads a discussion about refactoring methods in Python. Needless to say that the code is not well documented. Kay -- http://mail.python.org/mailman/listinfo/python-list