Question about math.pi is mutable

[BartC]

On 08/11/2015 23:13, Dennis Lee Bieber wrote:
> On Sun, 8 Nov 2015 18:58:36 +0000, BartC <bc at freeuk.com> declaimed the
> following:
>
>> But then, you say that additional attributes, potentially millions of
>> different ones, can be invented at runtime. Although I don't see how it
>> can remove names that are part of the source code: if "A.B" is in the
>> file, then surely "A" and "B" always have to be present in some table or
>> other.
>
> -=-=-=-=- module.py
>
> class Something(object):
> 	def __init__(self):
> 		pass
>
> -=-=-=-=- main.py
>
> import module
>
> module.remote = module.Something()
> nonremote = module.remote
> nonremote.x = "Looky here"
> print module.remote.x
> module.remote.x = 3.14
> print nonremote.x
> module.remote = None
> print nonremote.x
> print module.remote.x

Is this typical Python code? Creating global objects in other modules 
(or writing all over essential data structures in a library module).

If most code is going to be more sensible, then I mentioned an approach 
in my other post just over an hour ago. The idea there was to optimise 
attribute lookups when code is written with more restraint. (So defining 
functions, classes and attributes within classes in a boring manner.)

> 	Where do you propose to "tableize" remote, nonremote, and x. "remote"
> doesn't exist inside module.py until one executes main.py -- so it can't be

In your example, only attributes "remote" and "x" exist. But the tables 
for those will be empty as it is not practical to add in runtime-created 
attributes. Then, a conventional lookup would be needed.

> optimized to when the compiler parses module.py (creating, in most cases a
> bytecode module.pyc). You can't optimize it to main.py since (not shown in
> my example) there may be another imported package that also imports module
> and references module.remote -- and could even replace it with a new object
> (in which case nonremote is still associated with the old object, not the
> new one)

The tables would reflect the static layout of the attributes as defined 
in the source code. Since the source code is finite, the tables will be 
also (unlike runtime when a billion attributes could be created).

If your module.py code is tweaked like this:

  class Something(object):
         x=0
  	def __init__(self):
  		pass

  remote=0

Then 'x' and 'remote' become static attributes that can now added to 
tables for fast lookup. Although this does require that these two are 
effectively 'declared'.

-- 
Bartc