python 3（python 3.1、python 3k、python3000）中内置函数的两个相互冲突的含义

发布于 2024-08-19 23:24:02 字数 1513 浏览 4 评论 0原文

我刚刚在 comp.lang.python 上发布了下面的查询，但我觉得这种问题在 Stack Overflow 上也有某种优先权，所以重复一下吧。本质：为什么“内置函数”在 Python 3 中有两种不同的解释？

我很乐意接受任何关于这件事的评论句子，摘自 http://celabs.com/python-3.1/reference/executionmodel。 html, 意味着，或者为什么众神决定这是要走的路。我预计这个名叫 Kay Schluehr 的人会对此发表意见，或者也许连 BDFL 都会愿意将 __builtins__ 发音为正确的方式对待他的失败者、追随者和同胞::

  The built-in namespace associated with the execution of
  a code block is actually found by looking up the name
  __builtins__ in its global namespace; this should be a
  dictionary or a module (in the latter case the module’s
  dictionary is used). By default, when in the __main__
  module, __builtins__ is the built-in module builtins;
  when in any other module, __builtins__ is an alias for
  the dictionary of the builtins module itself.
  __builtins__ can be set to a user-created dictionary to
  create a weak form of restricted execution.

过去的情况是至少有两个不同的术语， “builtin”（单数）和“builtins”（复数），其中一些它以模块和字典形式存在（？只是猜测？）。现在只有内置，所以幸运的是，之间的矛盾心理单数和复数已经消失了——很好的摆脱。

但为什么 __builtins__ 会根据是否改变其含义这是“脚本”的范围（即名称为存在，当调用 python foobar.py 时）或者这是否是辅助模块的范围（导入或执行，直接或间接地，通过 foobar.py ）？我无法理解其中的道理这背后并发现它非常令人困惑。

理由：我为什么关心？——我希望能够“将名称导出到未标记为私有的全局命名空间（通过下划线前缀）在我通过 exec(compile(get ( locator ), locator, 'exec' ), R ) 其中 R 应该去保存所述模块的私有名称。它有点有点神秘，但是基本练习是绕过 python 的导入系统并获得 similr 结果...这就是将名称注入全全局和模块全局命名空间。

原文

I just posted below query to comp.lang.python, but i feel this kind of question has some kind of right-of-way here on Stack Overflow, too, so be it repeated. the essence: why does ‘builtins’ have two distinct interpretations in Python 3?

I would be very gladly accept any commentaries about what this
sentence, gleaned from http://celabs.com/python-3.1/reference/executionmodel.html,
is meant to mean, or why gods have decided this is the way to go. i
anticipate this guy named Kay Schluehr will have a say on that, or
maybe even the BDFL will care to pronounce __builtins__ the
correct way to his fallovers, followers, and fellownerds::

  The built-in namespace associated with the execution of
  a code block is actually found by looking up the name
  __builtins__ in its global namespace; this should be a
  dictionary or a module (in the latter case the module’s
  dictionary is used). By default, when in the __main__
  module, __builtins__ is the built-in module builtins;
  when in any other module, __builtins__ is an alias for
  the dictionary of the builtins module itself.
  __builtins__ can be set to a user-created dictionary to
  create a weak form of restricted execution.

it used to be the case that there were at least two distinct terms,
‘builtin’ (in the singular) and ‘builtins’ (in the plural), some of
which existed both in module and in dict form (?just guessing?). now
there is only builtins, so fortunately the ambivalence between
singular and plural has gone—good riddance.

but why does __builtins__ change its meaning depending on whether
this is the scope of the ‘script’ (i.e. the module whose name was
present, when calling python foobar.py) or whether this is the
scope of a secondary module (imported or executed, directly or
indirectly, by foobar.py)? i cannot understand the reasoning
behind this and find it highly confusing.

rationale: why do i care?—i want to be able to ‘export names to the
global namespace that were not marked private (by an underscore
prefix) in a python module that i execute via exec( compile( get ( locator ), locator, 'exec' ), R ) where R is supposed to going
to hold the private names of said module’. it is a little arcane but
the basic exercise is to by-pass python’s import system and get similr
results... it is all about injecting names into the all-global and the
module-global namespaces.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

予囚 2024-08-26 23:24:02

getattr(__builtins__, '__dict__', __builtins__) 应该为您提供要更新为“将名称导出到全局命名空间”的字典，无论 __builtins__ 是否是一个字典（那么它没有 __dict__ 属性，因此 getattr 返回第三个参数，即字典 __builtins__ 本身）或模块（然后它确实具有该属性并且getattr返回它）。这是解决方法。至于为什么 Python 的工作方式被记录为需要如此复杂的解决方法，我将其归类为实现问题浮现到用户可见（并且确实记录）级别的不幸案例（叹气）。遗憾的是，我们没有考虑在迁移到 Python 3 时修复它，但现在进行向后不兼容的更改为时已晚:-(。