[Python-Dev] Re: native code compiler? (or, OCaml vs. Python) (original) (raw)
Guido van Rossum guido@python.org
Mon, 03 Feb 2003 17:45:01 -0500
- Previous message: [Python-Dev] Re: native code compiler? (or, OCaml vs. Python)
- Next message: [Python-Dev] Re: native code compiler? (or, OCaml vs. Python)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
GvR> What I proposed was only closing off write access to the GvR> dict so that the setattr code for type module can implement GvR> certain restrictions (e.g. no assignment to attributes named GvR> "len").
I'd certainly like that feature, except for the times I'd want to circumvent it. On many occasions I have externally patched a module's namespace for debugging. It's been really convenient to replace some function with a wrapper that does some logging or updates a table tracking currently used resources. I've done the same with builtin open/file. As you noted, it seems less useful to override other builtins for this purpose. I'd suggest that frozen module namespaces by a feature of -O, except that I never use -O.
We really only need to disallow assignment to names that would shadow builtins that are in fact inlined by the compiler. open/file wouldn't be one of these (specifically open/file would be exempted from inlining, and so would import, because these are known special cases).
--Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] Re: native code compiler? (or, OCaml vs. Python)
- Next message: [Python-Dev] Re: native code compiler? (or, OCaml vs. Python)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]