Dictionary passed to eval as global name space is
filled up with global variables:

>>> m = {}
>>> m == {}
1
>>> eval("1", m)
1
>>> m == {}
0

Logged In: YES 
user_id=31435

Well, yes.  That's what "global name space" means.  Why 
would you assume it's limited to read-only?  Where would 
you *expect* global bindings to be made, if not in the global 
namespace?

Logged In: YES 
user_id=388573

I gues that a function don't have a side effect if the
effect not documented. Why is dictionary passed as local
name space  not filled up with local variables? I think docs
should say anything about this.

Logged In: YES 
user_id=31435

Changed category to Doc and assigned to Fred, since there's 
no chance the implementation will change.  I don't find the 
docs unclear, but this is deep stuff and it's certainly 
understanble that others may not.

Logged In: YES 
user_id=593130

Suggestion: in Library Manual 2.1 eval() entry,
after the second sentence, ending in 'local name space.', 
add

If one give a *globals* dictionary that lacks a  '__builtins__' 
entry, a copy from the current globals is added before 
*expession* is parsed.  This means that *expression* 
normally has full access to the standard __builtins__ 
module, while restricted environments get propagated.

This description is based on the tested behavior in 2.2.1.  I 
don't know what, if any, is subject to change.  (*Asterisks* 
indicate italics.)

The 'surprise' of this side-effect has come up at least once 
on c.l.p.  The issue of eval() and security is more frequent.  
The details are not obvious and occasionally important.  I 
thus think it reasonable to add two short lines to 
document what happens.

Logged In: YES 
user_id=6656

Make a patch & I'll check it in...

Logged In: YES 
user_id=593130

Without (cvs,) latex, and diff, I think cut-and-paste paste is 
about best I can do.

Logged In: YES 
user_id=33168

Checked in with minor adjustments as Doc/lib/libfuncs.tex 1.125.
I'm not sure if my slight rewording helped or hurt,
hopefully someone will fix that.