Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #28910 > unrolled thread

Re: Double sided double underscored variable names

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Double sided double underscored variable names Chris Angelico <rosuav@gmail.com> - 2012-09-12 08:52 +1000
    Re: Double sided double underscored variable names Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-12 01:14 +0000
      Re: Double sided double underscored variable names Chris Angelico <rosuav@gmail.com> - 2012-09-12 14:12 +1000
      Re: Double sided double underscored variable names Joshua Landau <joshua.landau.ws@gmail.com> - 2012-09-12 10:55 +0100

#28910 — Re: Double sided double underscored variable names

On Wed, Sep 12, 2012 at 8:48 AM, Joshua Landau
<joshua.landau.ws@gmail.com> wrote:
> Well, the problem is that a lot of collisions aren't predictable.
> "locals()['foo'] = 2", for example. If it weren't for Python's annoying
> flexibility* I would definitely do something very close to what you suggest.
> Remember that "locals()" isn't Python's only introspection tool. How about
> "from foo import *"?

You're not supposed to mutate locals(), but I suppose globals() works
the same way.

Inline functions? I like this idea. I tend to want them in pretty much
any language I write in.

ChrisA

[toc] | [next] | [standalone]

#28917

And again, Joshua's original post is not available from my provider. 
Joshua, I suspect that something about your post is being seen as spam 
and dropped by at least some providers.


On Wed, 12 Sep 2012 08:52:10 +1000, Chris Angelico wrote:

> On Wed, Sep 12, 2012 at 8:48 AM, Joshua Landau
> <joshua.landau.ws@gmail.com> wrote:
>>
>> Well, the problem is that a lot of collisions aren't predictable.
>> "locals()['foo'] = 2", for example. If it weren't for Python's annoying
>> flexibility* 

I can't see your footnote there, so you may have already covered this, 
but for the record, what you call Python's "annoying flexibility" is 
fundamental to Python's programming model and done so for good reasons. 
The ability to shadow built-ins is, at times, incredibly useful rather 
than annoying.

The world is full of bondage and domination languages that strongly 
restrict what you can do. Python doesn't need to be another one of them. 
Python's optimizing compiler, PyPy, is able to optimize code very well 
without such restrictions.


>> I would definitely do something very close to what you
>> suggest. Remember that "locals()" isn't Python's only introspection
>> tool. How about "from foo import *"?

I wouldn't call "import *" an introspection tool. At least, no more so 
than print.


> You're not supposed to mutate locals(), 

It's not so much you're not allowed to do it, but that the result of 
making changes to locals() inside a function is implementation dependent:

CPython 2: writing to the dict returned by locals() will work, but the 
changes will not be reflected in the actual local variables, except under 
very restricted circumstances;

CPython 3: those restricted circumstances that allowed writes to locals() 
to modify local variables are now SyntaxErrors;

Stackless: presumably the exact same behaviour as CPython (since 
Stackless is a fork, not a re-implementation);

Jython: the same as CPython;

IronPython: writes to locals() will modify the corresponding local 
variable.


Outside of a function, locals() returns globals() and writes will always 
modify the global variable (this is a language guarantee).

> but I suppose globals() works the same way.
> 
> 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.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#28927

On Wed, Sep 12, 2012 at 11:38 AM, Joshua Landau
<joshua.landau.ws@gmail.com> wrote:
> On 12 September 2012 02:14, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>>
>> And again, Joshua's original post is not available from my provider.
>> Joshua, I suspect that something about your post is being seen as spam
>> and dropped by at least some providers.
>
> I am sorry to ask this, but in the meantime can someone who isn't
> spam-filtered repost my messages? I'll give them a cookie!
> To repeat my previous post, I'm using GMail and posting to
> python-list@python.org. If that is what I'm meant to be doing, I'll try
> another email address.

Mailing to python-list@python from Gmail is exactly what I do, and far
as I know, none of my posts are getting lost. But then, I'm seeing all
your posts, too, so maybe I just don't know when my posts don't go
through.

>> 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.

ChrisA

[toc] | [prev] | [next] | [standalone]

#28940

On 12/09/2012, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Sep 12, 2012 at 11:38 AM, Joshua Landau
> <joshua.landau.ws@gmail.com> wrote:
>> On 12 September 2012 02:14, Steven D'Aprano
>> <steve+comp.lang.python@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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web