[Q] python vs checker.py maxlocals

Neal Norwitz neal at metaslash.com
Wed Mar 26 21:00:43 EST 2003


On Wed, 26 Mar 2003 18:55:12 -0500, achrist wrote:

> sismex01 at hebmex.com wrote:
>> 
>> argh... 60 locals in a single function???
>> 
>> Most probably, it isn't that Python won't allow more, it's that it's
>> very bad form to do such a thing. Can't you break it up into smaller
>> functions which so a very concise, small task?
>> 
>> 
> No, I think that I've got the code structured ok. Run-on code is ok by
> me if you are doing the same thing predictably and repeatedly with
> columns that line up. I've got a pre-defined datastructure that I'm
> building.  Something like this hypothetical example:
> 
>     universe   	= tree.AddRoot("The Universe")
> 
>     milkyWay    = AddTreeItem( tree,  universe,    "Our Galaxy" )
> 
>     solarSystem = AddTreeItem( tree,  milkyWay,    "Solar System" )
> 
>     earth       = AddTreeItem( tree,  solarSystem, "Earth" )
> 
>     kansasCity  = AddTreeItem( tree,  earth,       "Kansas City" )
> 
>   ... and so on ad nauseum
> 
> My tree has ~60 nodes now, how many ultimately, IDK. Since I'm just
> noodling around with the tree, and will be adding and deleting nodes,
> re-arranging the hierarchy, etc, it looks to me to be simpler and less
> unmaintainable with named nodes and connections as above instead of:
> 
>     d           = {}
>     d["universe"]   	= tree.AddRoot("The Universe") d["milkyWay"]    =
>     AddTreeItem(tree,  "universe",    "Our Galaxy") d["solarSystem"] =
>     AddTreeItem(tree,  "milkyWay",    "Solar
> System"
>     d["earth"]       = AddTreeItem(tree,  "solarSystem", "Earth")
>     d["kansasCity"]  = AddTreeItem(tree,  "earth", "Kansas City") ...
> 
> This has the slight disadvantage that the string literals have to be
> typed in twice, introducing a slightly different failure mode in the
> event of a typo.
> 
> Or writing it out in some lisp-like notation:
> 
>     tree = initializeTree(
> 		[ "The Universe",
> 		   [ "Our Gslaxy",
> 		   	["Solar System",
> 			    [ "Earth",
> 				[ "Kansas City"]
> 			    ]
> 			]
> 		   ]
> 		]
> 	   )
> 
> This is nice in that there is no repetition, and if I typo, I'll get a
> syntax error, but if I like reading lisp, I've got some real problems
> doing this in Python.
> 
> Or XML (shudder)?  This is not data transport, it's just a program.
> 
> Is there any more pythonic idiom for this?  There is one additional
> complexity to this that I omit above for simplicity:  The tree is a
> wxPython wxTreeCtrl, and there is an additional parameter used in the
> construction  of each node ... a user data item that contains a function
> to call when the coresponding tree item is selected by the user. I
> really don't want this to be defined outside the program in some file
> where things can get fouled up after I've got it ok.
> 
> TIA for any idioms for the idiosyncratics.

The answer to your original question is 2**32 I believe.  I ran
a program with over 64k local variables.

	>>> f = open('tt.py', 'w')
	>>> f.write('def f():\n')
	>>> for x in xrange(65555):
	...   f.write('  a%d = 0\n' % x)
	... 
	>>> f.write('\n\nf()\n')

    $ python tt.py

The way I would solve this problem would be through data-driven
programming.

So given your list like this:

	locations = ['The Universe', 'Our Galaxy', 'Milky Way', ... ]

I would have code like this:

	d = {}
	d[keyname(locations[0])] = tree.AddRoot(locations[0])
	for i in range(len(locations)-1):
	    prev, item = locations[i:i+2]
	    d[keyname(item)] = AddTreeItem(tree, keyname(prev), item)

You just need to define a keyname() function to convert from the long
string to the key name format.  Probably strip spaces and lowercase.
Perhaps, you don't even need the keyname.

Now the code never gets longer, no matter how many locations exist.
You can use similar techniques for introspection when operating on
objects.  Instead of using a dictionary, you can use 
setattr(o, keyname, value) and getattr(o, keyname).  This can really
shorten GUI code in particular.

Neal




More information about the Python-list mailing list