Double sided double underscored variable names

[Joshua Landau]

On 12/09/2012, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Sep 12, 2012 at 11:38 AM, Joshua Landau
> <joshua.landau.ws at gmail.com> wrote:
>> On 12 September 2012 02:14, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>>
>>> On Wed, 12 Sep 2012 08:52:10 +1000, Chris Angelico wrote:
>>>
>>> > Inline functions? I like this idea. I tend to want them in pretty much
>>> > any language I write in.
>>>
>>> What do you mean by in-line functions? If you mean what you literally
>>> say, I would answer that Python has that with lambda.
>>>
>>> But I guess you probably mean something more like macros.
>>
>> No, just multi-line lambda. Macros, if my knowledge of lower-level
>> languages
>> is valid, would be sorta' silly in Python.
>
> Ah, okay. I was thinking more along the lines of what you call macros,
> but in the C++ sense of inline functions. In C, macros are handled at
> precompilation stage, and are dangerous. Classic example:
>
> #define squared(x) x*x
>
> x_squared = squared(6+7)
>
> So your macros end up littered with parentheses, and it still doesn't
> solve anything, as the argument still gets evaluated twice. (A problem
> if it has side effects - eg if it's a function call.)
>
> What I'm thinking of, though, is like C++ functions. You can put the
> 'inline' keyword onto any function, and the compiler will do its best
> to inline it (in fact, a good optimizing compiler will inline things
> regardless, but that's a separate point). I can write:
>
> inline int squared(int x) {return x*x;}
>
> and C++ will add no function overhead, but will still do all the
> proper evaluation order etc.
>
> Of course, C++ doesn't allow monkeypatching, so you'll never have
> semantic differences from inlining. It's just a performance question.
> But I use inline functions like constants - for instance, I could
> create a function that converts a database ID into an internal
> reference number, and I can change the definition of that function in
> one place and have it apply everywhere, just like if I wanted to
> change the definition of math.PI to 3.142857 for fun one day. Of
> course I can use a normal (out-of-line) function for this, but that
> has overhead in most languages. Hence, wanting inline functions.

Interesting. I'd overestimated macros and underestimated inline functions.

I am not sure how to make a version of that with scope-compatibility. Inlining
inline_def f(y): x = y +1
would hopefully not change the outside scope*, but I'm not sure how to
make that.

I could make it work by banning "=", but then it's almost a macro but with
internal_a = input_a
internal_b = input_b
...
at the start...

* If I understand rightly