On 9/17/14 1:19 AM, Tennessee Leeuwenburg wrote:
I would use this if I had a group of related functions which were not written in an object-oriented-style, possibly due to not needing any shared state. Rather than break these out into a new file, I would like to just be able to use internal structure to declare the relationship. Yeah, standalone function CAN be easier to test provided that you did everything possible to make the function testable. It could also provide a more seamless way to decide to break out into a new file. Once a named block got big enough, I could easily create a new file and import those functions into the same namespace. So this is how I read your idea:
1. Import the necessary names from other modules if needed 2. Organize them local to the module 3. Use them by attribute loop-up as indicated by your example The idea sounds pretty cool, but first time I ask myself as a Python user is whether I find signing.xxx more appealing than writing xxxx directly. As an import mechanism, the regular import seems good enough to me. Personally, based on your examples, I should have a module named sigin. Because in advance I know I will have a bunch of functions that are logically related. These functions will be used when the user is signed in. So I will tell myself don't wait just do it now, put them into a module. When I use the module, I just import signin and in my code I just signin.handle_new_user It is also my preference to import the module rather than importing individual functions into the namespace; I want to be able to know the origin of the function as I write my code. Now, can handle_new_user be used outside of the signin context? I really doubt it. If handle_new_user is meant to run after the user is signed in, then that function will only live in 1 block. No resuse. As a macro, I think that the equivalent is probably grouping within a function (although that is not what most people think of macros do, but er, "close enough"). Just my two cents. John