python24.zip [英] python24.zip
问题描述
调查有关python路径的查询我看到我的win32安装已经在sys.path上获得了
c：/windows/system32/python24.zip（这是不存在的）第二个
在实际的python24 / lib等之前等。
首先，python应该在路径上以不存在的条目启动吗？
其次是这个条目某些其他类型的python安装的默认值？
-
Robin Becker
Robin Becker写道：首先，python应该在路径上以不存在的条目启动吗？
是的，这是设计的。
其次这个条目是其他类型的python安装的默认设置吗？
是的。人们可以在python24.zip中打包他们想要的东西（包括
site.py）。这只能在python24.zip已经在路径上的情况下才能工作
（而且我相信它总会在
python24.dll所在的目录中寻找）。 />
问候，
马丁
" Martin v.L？wis" <毫安**** @ v.loewis.de>写于2005年5月20日星期五18:13:56 +0200：Robin Becker写道：首先，python应该在路径上以不存在的条目启动吗？ / blockquote>
是的，这是设计的。
其次这个条目是其他类型的python安装的默认设置吗？
是的。人们可以在python24.zip中包装他们想要的东西（包括
site.py）。这只能在python24.zip已经在路径上时才能工作
（我相信它总会在
python24.dll所在的目录中寻找）。
问题是：
如果python启动时路径上存在**不存在的**对象。
我认为没有理由为什么路径需要包含一个对象
哪个不存在（在翻译开始的时候）。
在您的用例中，python24.zip确实存在，因此可能会在路径上花费
。当python24.zip时不存在，它确实
不包含任何内容，特别是不包含site.py。
我最近分析了过多的导入时间和
看到成千上万的昂贵和不必要的文件系统操作，原因如下：
* longsys.path，特别是包含不存在的对象
虽然不存在，但对于任何尚未找到的模块，大约有5个文件系统操作是对它们进行了尝试。
* Python导入的严重弱点钩子处理
当有进口商i时对于路径p，并且
这个导入器找不到模块m，然后是p。将
视为目录和5个文件系统操作
试图找到p / m。当然，当p时，所有这些都失败了
。恰好是一个zip存档。
Dieter
Dieter Maurer写道：
...... < blockquote class =post_quotes>
问题是：
应该在路径上使用**不存在的**对象进行python启动。
我认为没有理由为什么路径需要包含一个不存在的对象（在解释器启动时）。
在你的用例中，python24.zip确实存在，因此可能会走上正轨。当python24.zip时不存在，它确实不包含任何东西，特别是不包含site.py。
我认为这是我的意图，但我认为我有一些顾虑超过
标准库有两个可能的位置。它似乎是非pythonic
并且如果某些软件包应该设法安装
python24.zip，而我相信正在使用python24 \ lib，则可能会引起混淆。
我最近分析了过多的导入时间，并且看到了成千上万的昂贵和不必要的文件系统操作，原因是：
* longsys.path，特别是包含不存在的对象
虽然不存在，但对于任何尚未找到的模块，都会对它们进行大约5个文件系统操作。
* Python导入的严重缺陷挂钩处理
当有进口商i时对于路径p，并且这个导入器找不到模块m，然后是p。被视为目录，并尝试5个文件系统操作来定位p / m。当然，当p时，所有这些都失败了。碰巧是一个zip存档。
Dieter
我想这是消除重复和不存在的条目的原因。 />
-
Robin Becker
Investigating a query about the python path I see that my win32 installation has
c:/windows/system32/python24.zip (which is non existent) second on sys.path
before the actual python24/lib etc etc.
Firstly should python start up with non-existent entries on the path?
Secondly is this entry be the default for some other kind of python installation?
--
Robin Becker
Robin Becker wrote:Firstly should python start up with non-existent entries on the path?
Yes, this is by design.
Secondly is this entry be the default for some other kind of python
installation?
Yes. People can package everything they want in python24.zip (including
site.py). This can only work if python24.zip is already on the path
(and I believe it will always be sought in the directory where
python24.dll lives).
Regards,
Martin
"Martin v. L?wis" <ma****@v.loewis.de> writes on Fri, 20 May 2005 18:13:56 +0200:Robin Becker wrote:Firstly should python start up with non-existent entries on the path?
Yes, this is by design.Secondly is this entry be the default for some other kind of python
installation?
Yes. People can package everything they want in python24.zip (including
site.py). This can only work if python24.zip is already on the path
(and I believe it will always be sought in the directory where
python24.dll lives).
The question was:
"should python start up with **non-existent** objects on the path".
I think there is no reason why path needs to contain an object
which does not exist (at the time the interpreter starts).
In your use case, "python24.zip" does exist and therefore may
be on the path. When "python24.zip" does not exist, it does
not contain anything and especially not "site.py".
I recently analysed excessive import times and
saw thousands of costly and unneccesary filesystem operations due to:
* long "sys.path", especially containing non-existing objects
Although non-existent, about 5 filesystem operations are
tried on them for any module not yet located.
* a severe weakness in Python''s import hook treatment
When there is an importer "i" for a path "p" and
this importer cannot find module "m", then "p" is
treated as a directory and 5 file system operations
are tried to locate "p/m". Of course, all of them fail
when "p" happens to be a zip archive.
Dieter
Dieter Maurer wrote:
......
The question was:
"should python start up with **non-existent** objects on the path".
I think there is no reason why path needs to contain an object
which does not exist (at the time the interpreter starts).
In your use case, "python24.zip" does exist and therefore may
be on the path. When "python24.zip" does not exist, it does
not contain anything and especially not "site.py".
I think this was my intention, but also I think I have some concern over
having two possible locations for the standard library. It seems non pythonic
and liable to cause confusion if some package should manage to install
python24.zip while I believe that python24\lib is being used.
I recently analysed excessive import times and
saw thousands of costly and unneccesary filesystem operations due to:
* long "sys.path", especially containing non-existing objects
Although non-existent, about 5 filesystem operations are
tried on them for any module not yet located.
* a severe weakness in Python''s import hook treatment
When there is an importer "i" for a path "p" and
this importer cannot find module "m", then "p" is
treated as a directory and 5 file system operations
are tried to locate "p/m". Of course, all of them fail
when "p" happens to be a zip archive.
Dieter
I suppose that''s a reason for eliminating duplicates and non-existent entries.
--
Robin Becker
这篇关于python24.zip的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
