A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-February/032881.html below:

native code compiler? (or, OCaml vs. Python)

[Python-Dev] Re: native code compiler? (or, OCaml vs. Python)Guido van Rossum guido@python.org
Mon, 03 Feb 2003 17:45:01 -0500
>   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/)



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4