PEP在标准库的路径模块上 [英] PEP on path module for standard library

问题描述

你们中的许多人都熟悉Jason Orendorff的路径模块

< http://www.jorendorff.com/articles/python/path/> ;,这经常是

推荐在clp上我提交了一份RFE，将其添加到Python

标准库中，Reinhold Birkenfeld开始讨论它。

python-dev

< ; http：//mail.python.org/pipermail/python-dev/2005-June/054438.html> ;.


讨论的结果是许多python-dev' '想要路径

添加到stdlib，但Guido不相信，并说它必须有一个

PEP。因此，莱因霍尔德和我将继续努力。 Reinhold已经对模块进行了一些更改以适应python-dev的讨论，并在nondist / sandbox / path中将它放在CPython CVS中。


对于PEP，你们中的任何人都有或者反对包括路径吗？

使用这个类更容易或更难的代码示例

也是最有帮助的。


我在我的模块和脚本中使用的路径比任何其他第三方
模块都要多，我知道它会当我不再需要

担心部署它时非常有用。


提前致谢，

-

Michael Hoffman

Many of you are familiar with Jason Orendorff''s path module
<http://www.jorendorff.com/articles/python/path/>, which is frequently
recommended here on c.l.p. I submitted an RFE to add it to the Python
standard library, and Reinhold Birkenfeld started a discussion on it in
python-dev
<http://mail.python.org/pipermail/python-dev/2005-June/054438.html>.

The upshot of the discussion was that many python-dev''ers wanted path
added to the stdlib, but Guido was not convinced and said it must have a
PEP. So Reinhold and I are going to work on one. Reinhold has already
made some changes to the module to fit the python-dev discussion and put
it in CPython CVS at nondist/sandbox/path.

For the PEP, do any of you have arguments for or against including path?
Code samples that are much easier or more difficult with this class
would also be most helpful.

I use path in more of my modules and scripts than any other third-party
module, and I know it will be very helpful when I no longer have to
worry about deploying it.

Thanks in advance,
--
Michael Hoffman

推荐答案

Michael Hoffman写道：

Michael Hoffman wrote:

对于PEP，你们中的任何人都有支持或反对包含路径的参数？
使用此类更容易或更困难的代码示例
也是最有帮助的。

For the PEP, do any of you have arguments for or against including path?
Code samples that are much easier or more difficult with this class
would also be most helpful.

I相信最强路径的参数可以制作它如何实现

集成了功能，虽然概念上密切相关，但目前分布在半打或更多模块中的


在标准库中。特别是对于新手（我只能想象，在这个阶段这个阶段）它会使文件在很多方面变得更容易。


更容易或更难当然，这是一个主观的事情，但是一个人不能争论这样一个事实：路径有时可以通过单个

对象来实现，否则需要多次导入和一堆调用

进入open（），os.path，grep和shutil之类的东西。


示例显示简化这些情况的路径的有效使用

可能值得标签更容易即使在Guido的心中，不幸的是，不幸的是，这不确定。 "更容易"在某些人心目中可能只是简单地将b $ b转换为多行少代码，而路径有时可以做到b / b $ b除了分裂和加入东西之外没有

对os.path.this的多次调用 - 根据我的经验，它实际上并没有经常减少

代码大小_that_。 （尽管如此，发布给clp的人显示了代码大小减少了50％）。


相关的想法：因为路径是对象，所以它们具有属性或者

属性，以及类似.basename的内容。和.parent很容易

可用，而不必做一些模糊的事情，比如

os.path.split（somepath）[0]让事情更容易阅读（因此

更易于维护）。事实上，我认为这是另一个有利于路径的强烈论证：它使代码更具可读性，即使不是b $ b更容易写。


嗯...确实更容易或更难申请编写

代码或阅读它？我发现使用路径代码写成代码
是不言而喻的。更容易阅读，不一定要更容易写（对于非新手）。


我会通过说集成来总结这一点路径的在

stdlib中，新手可以更轻松地编写代码（对于非新手来说，这可能不是很明显......我们应该请一些人帮忙吗？） ，并且更容易

每个人都可以阅读代码（不言自明，不是吗？），如果这不是一个足够的条件，我不会知道是什么。


-Peter

I believe the strongest argument for "path" can be made for how it
integrates functionality which, although closely related conceptually,
is currently distributed across a half dozen or more different modules
in the standard library. Especially for newbies (I can only imagine, at
this stage) it would make working with files much easier in a many ways.

"Easier" or "more difficult" is a subjective thing, of course, but one
can''t argue with the fact that path can sometimes do through a single
object what would otherwise require several imports and a bunch of calls
into things like open(), os.path, grep, and shutil.

Examples showing effective uses of path that simplify those cases would
probably merit the label "easier" even in Guido''s mind, though
unfortunately that''s not certain. "Easier" in some minds might simply
translate to "many lines less code", and while path can sometimes do
that, aside from the ease of splitting and joining stuff without
multiple calls to os.path.this-and-that, it really doesn''t often reduce
code size _that_ much, in my experience. (Postings to c.l.p showing a
50% reduction in code size for contrived examples notwithstanding.)

A related thoughts: since paths are objects, they have attributes or
properties, and having things like ".basename" and ".parent" readily
available without having to do obscure things like
os.path.split(somepath)[0] makes things much easier to read (therefore
more maintainable). In fact, I''d propose that as another strong
argument in path''s favour: it makes code much more readable, even if not
"easier" to write.

Hmm... does "easier" or "more difficult" apply to the writing of the
code or the reading of it? I find it self-evident that code written
using "path" is much easier to read, not necessarily much easier to
write (for non-newbies).

I''d summarize this by saying that the integration of "path" in the
stdlib would make it easier for newbies to write code (that might not be
obvious to a non-newbie... shall we ask some to help?), and easier for
everyone to read code (self-evident, no?), and if that''s not a
sufficient condition for inclusion I don''t know what is.

-Peter

Peter Hansen写道：

Peter Hansen wrote:

Michael Hoffman写道：

Michael Hoffman wrote:

对于PEP，你们中的任何人都有包含路径的论据吗？
这个类更容易或更难的代码示例
也是最有帮助的。

For the PEP, do any of you have arguments for or against including path?
Code samples that are much easier or more difficult with this class
would also be most helpful.

我相信路径的最强有力的论据。可以制作它如何集成功能，虽然在概念上密切相关，但目前分布在标准库中的六个或更多不同的模块中。特别是对于新手（我只能想象，在这个阶段）它会使文件在很多方面更容易处理。

I believe the strongest argument for "path" can be made for how it
integrates functionality which, although closely related conceptually,
is currently distributed across a half dozen or more different modules
in the standard library. Especially for newbies (I can only imagine, at
this stage) it would make working with files much easier in a many ways.

+10


让我厌烦stdlib的少数事情之一就是人们可以称之为执行''shell-scripting-like''任务的
，正是因为问题

你指出了。一些概念上相关且常见的任务分散在各地，每当我需要编写这种代码时，我发现

我自己在多个文档中进行分页模块，没有真正的直觉，我甚至可以猜到在哪里可以找到东西。对于

python来说这是非常不寻常的，在大多数情况下，事情是如此有条理，盲目的猜测

往往非常好。


就个人而言，我喜欢路径模块_a lot_，虽然我确信从clpy和python-dev通过PEP彻底的一次性b / b
只会让它变得更好顺利出局

隐藏粗糙边缘和角落的情况。但是如果它确实会在未来向stdlib发送
，我将非常高兴。


只是我的.02。


最好的，


f

+10

One of the few things that annoys me about the stdlib is what one could call
performing ''shell-scripting-like'' tasks, and precisely because of the problem
you point out. A number of conceptually related and common tasks are
scattered all over, and every time I need to write this kind of code, I find
myself paging over the docs for multiple modules, with no real intuition as to
where I could even guess where to find things. This is very unusual for
python, where in most cases things are so well organized, that blind guessing
tends to work remarkably well.

Personally I like the path module _a lot_, though I''m sure a thorough once-over
from c.l.py and python-dev, via a PEP, can only make it better and smooth out
hidden rough edges and corner cases. But I''ll be very happy if it does go
into the stdlib in the future.

Just my .02.

Best,

f

我真的很喜欢杰森的''路径' '模块。可悲的是，我在使用它时遇到了严重的问题。当你试图冻结一个应用程序模块时，

和Jason''''path''模块出现在

看起来的任何目录中通过冻结模块查找器（你的应用程序不必导入

），冻结进入无限循环的导入，最终得到一个

' '最大递归深度''异常。这似乎与

冻结在''os.path''和Jason''''''之间的混淆有关。


我遇到过这是使用Jason的最新路径模块和Python 2.3.2。

我能够通过将path.py重命名为newpath.py来解决它的问题。

并在我的模块中使用'from newpath import path'。


我刚刚通知杰森这件事。我假设将使用像我这样的解决方案

，并期待在stdlib中看到Jason的模块。

I really love Jason''s ''path'' module. Sadly, I''ve encountered a serious
problem with using it. When you try to ''freeze'' an application module,
and Jason''s ''path'' module is present in any of the directories that are
looked at by freeze''s module finder (your app doesn''t have to import
it), freeze goes into an infinite loop of imports, eventually getting a
''maximum recursion depth'' exception. This seems to be related to
freeze getting confused between ''os.path'' and Jason''s ''path''.

I encountered this using Jason''s latest ''path'' module and Python 2.3.2.
I was able to solve it for my use by renaming path.py to newpath.py
and using ''from newpath import path'' in my modules.

I''ve just notified Jason about this. I presume a solution like mine
will be used, and look forward to seeing Jason''s module in stdlib.

这篇关于PEP在标准库的路径模块上的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！