So, I was chatting about "helpers" with Ben Bangert on #webware, and thinking about adding stuff to __builtins__, like html_quote and the like. Hey, don't you judge me! Anyway, I think I like string.encode('html') more.

But anyway, I was thinking about how to make this stuff somewhat easier. And I was thinking about a discussion on Py-Dev about adding a dedent method to strings. The rationale was that inline strings that match up with surrounding whitespace need dedenting (ala textwrap.dedent). Why not just use textwrap.dedent? My opinion is that the value is too small for the overhead. And this kind of overhead happens often.

I also think the overhead shouldn't exist. Managing import statements is obnoxious. When they represent real dependencies or namespace operations that's fine -- I'd even say it is good. I like namespaces, really. But managing the imports is annoying.

In this case, I might be 100 lines into a module, and I'm writing a string. If I really want to use textwrap.dedent, I have to go up to the top of the file, add import textwrap and return to my previous location. And, since I know the standard library pretty well now and tend to use it, it is not uncommon for modules to start with 15 lines of imports. That just sucks!

Then I remember about the py-lib which has py.std. Using it I wouldn't have to import textwrap, I'd just use py.std.textwrap.dedent immediately. Does that string seem too long? I don't think so; it's not the length that is bothersome to me (it helps backtracking, and that's good), it's the disturbance of my workflow to add import statements, when I feel like I'm just feeding the compiler. There's good reasons to be explicit, but this is just as explicit as an import (maybe moreso). Unlike an import it is fully localized to the code fragment that uses the module.

Now putting std in __builtins__ is something I could stand behind.