PRE-PEP：新的Path类 [英] PRE-PEP: new Path class
问题描述
我正在为Gerrit Holl的预先添加评论帖，其中
可以在这里找到：
http://tinyurl.com/2578q
坦率地说，我喜欢理念。现在是时候os模块中的所有文件
和目录内容都被正确地对象化了（或者至少有一些OO适当的表现！）
在问题部分：
1）路径应该是str的子类吗？
没有。在决定它是否是单字节或unicode字符串的子类的难度之外，它是纯粹的
和简单的Feature Envy案例。当然，开发人员想要使用字符串方法的时间会是
，但
应该直接支持最常见的操作。
2）虚拟文件系统可扩展性。
目前没有意见。我希望看到一对
的尝试首先实现在
解决单一设计之前。
3）/运营商应该映射加入路径。
我同意。没门。首先，那是'unixism
（Windows使用\，Mac使用:)在第二个
的地方它不适合常用of /，这是分开（分开）事物的
。如果我们想要一个运营商
加入（不是个坏主意）我建议使用''+''。字符串
已经超过它进行连接，正如我上面所说的那样，我会很快*不会*这是一个子类
$ b字符串$ b。
4）路径是否应该公开listdir的迭代器（？）
我不明白为什么不，只要路径是一个
目录。
5）应该==运算符与os.path.samefile（）相同吗？
为什么不...
6）Path.open（）？
当然。
7）各种gettime方法应该返回Datetime
对象。
当然。
8）触摸方法？
当然。
9）当前的OS常量？
它们是什么？我们是在谈论access（）函数中的四个
常量，还是关于某些内容
else？
10）Commonprefix ，walk和sameopenfile？
Commonprefix应该是一个字符串或列表方法，
它不适合这里。
walk是一个不错的功能，但它应该重做
直接使用访问者模式，使用不同的方法
文件，目录和其他任何名称的名称
特定的文件系统在其中有点歪曲。
sameopenfile不属于os.path模块
首先。它属于os模块下的
6.1.3 - 文件描述符操作。
11）重命名加入和拆分。
我不会打扰。因为我反对把它变成str（）的子类，所以问题不会出现。
12）应该==比较文件尺寸。
编号可能有办法做到这一点。
13）chdir，chmod等？
否。这与路径名无关。
14. Unicode文件名
必须在Windows上拥有它们并且可能是Mac上的
。
15.文件和目录是否应该相同
类。
可能不是。虽然他们分享了许多常见的
功能（应该将其描述为
界面），但他们也有很多不同的
功能。分离它们也可以轻松地为符号链接之类的东西创建对象。
除此之外，我们应该有能力
直接更新其他时间（utime（））
使用另一个文件或目录对象
作为Datetime对象。
John Roth
I''m adding a thread for comments on Gerrit Holl''s pre-pep, which
can be found here:
http://tinyurl.com/2578q
Frankly, I like the idea. It''s about time that all of the file
and directory stuff in the os module got objectified
properly (or at least with some semblance of OO propriety!)
In the issues section:
1) Should path be a subclass of str?
No. Outside of the difficulty of deciding whether it''s a
subclass of single byte or unicode strings, it''s a pure
and simple case of Feature Envy. Granted, there will
be times a developer wants to use string methods, but
the most common operations should be supported directly.
2) virtual file system extensibility.
No opinion at this time. I''d like to see a couple
of attempts at an implementation first before
settling on a single design.
3) Should the / operator map joinpath.
I agree. No way. In the first place, that''s a unixism
(Windows uses \, the Mac uses :) In the second
place it doesn''t fit the common use of /, which is
to divide (separate) things. If we want an operator
for join (not a bad idea) I''d suggest using ''+''. String
already overloads it for concatenation, and as I said
above, I''d just as soon *not* have this be a subclass
of string.
4) Should path expose an iterator for listdir(?)
I don''t see why not, as long as the path is to a
directory.
5) Should == operator be the same as os.path.samefile()?
Why not...
6) Path.open()?
Of course.
7) Should the various gettime methods return Datetime
objects.
Of course.
8) Touch method?
Of course.
9) Current OS constants?
What are they? Are we talking about the four
constants in the access() function, or about something
else?
10) Commonprefix, walk and sameopenfile?
Commonprefix should be a string or list method,
it doesn''t fit here.
walk is a nice function, but it should be redone to
use the visitor pattern directly, with different method
names for files, directories and whatever else a
particular file system has in it''s warped little mind.
sameopenfile doesn''t belong in the os.path module
in the first place. It belongs in the os module under
6.1.3 - File Descriptor Operations.
11) rename join and split.
I wouldn''t bother. Since I''m against making it a
subclass of str(), the issue doesn''t arise.
12) Should == compare file sizes.
No. Might have a method to do that.
13) chdir, chmod, etc?
No. This has nothing to do with pathname.
14. Unicode filenames
Have to have them on Windows and probably
on the Mac.
15. Should files and directories be the same
class.
Probably not. While they share a lot of common
functionality (which should be spelled out as an
interface) they also have a lot of dissimilar
functionality. Separating them also makes it easy
to create objects for things like symbolic links.
In addition to this, we should have the ability
to update the other times (utime()) directly
using another file or directory object as well
as a Datetime object.
John Roth
推荐答案
在文章< vv ************ @ news.supernews。 com>，
" John Roth" <是ne ******** @ jhrothjr.com>写道：
In article <vv************@news.supernews.com>,
"John Roth" <ne********@jhrothjr.com> wrote:
我正在添加一个评论Gerrit Holl的预先评论的帖子，可以在这里找到：
http://tinyurl.com/2578q
坦率地说，我喜欢这个主意。现在是时候os模块中的所有文件和目录内容都得到了正确的客观化（或者至少有一些OO适当的表现！）
问题部分：
[剪掉我同意John的那些点]
4）路径是否应该公开listdir的迭代器（？）
我不明白为什么不，只要路径是
目录。
_An_ iterator，当然，但不是__iter__。 path.listdir（）怎么样？ :)
__iter__也可以遍历路径元素，所以它的含义最少
。
15.应该是文件和目录是一样的。
可能不是。虽然它们共享许多常见的功能（应该作为
界面拼写），但它们也有很多不同的功能。分离它们也可以轻松地为符号链接之类的东西创建对象。
I''m adding a thread for comments on Gerrit Holl''s pre-pep, which
can be found here:
http://tinyurl.com/2578q
Frankly, I like the idea. It''s about time that all of the file
and directory stuff in the os module got objectified
properly (or at least with some semblance of OO propriety!)
In the issues section:
[ snipping those points where I agree with John ]
4) Should path expose an iterator for listdir(?)
I don''t see why not, as long as the path is to a
directory.
_An_ iterator, sure, but not __iter__. How about path.listdir()? :)
__iter__ could also iterate over the path elements, so it''s ambiguous at
least.
15. Should files and directories be the same
class.
Probably not. While they share a lot of common
functionality (which should be spelled out as an
interface) they also have a lot of dissimilar
functionality. Separating them also makes it easy
to create objects for things like symbolic links.
但是对于尚未存在的文件夹文件的路径呢？我不认为b $ b你认为你应该_hit_文件系统，如果你所做的一切都是
path.join（）。
只需
But what about paths for not-yet-existing files of folders? I don''t
think you should actually _hit_ the file system, if all your doing is
path.join().
Just
" Just" <菊** @ xs4all.nl>在留言中写道
news：ju ************************ @ news1.news.xs4all。 nl ...
"Just" <ju**@xs4all.nl> wrote in message
news:ju************************@news1.news.xs4all. nl...
在文章< vv ************ @ news.supernews.com>，
John Roth中<是ne ******** @ jhrothjr.com>写道：
In article <vv************@news.supernews.com>,
"John Roth" <ne********@jhrothjr.com> wrote:
我正在添加一个评论Gerrit Holl的预先评论的帖子，可以在这里找到：
http://tinyurl.com/2578q
坦率地说，我喜欢这个主意。现在是时候os模块中的所有文件和目录内容都得到了正确的客观化（或者至少有一些OO适当的表现！）
问题部分：
[剪掉我同意约翰的那些点]
I''m adding a thread for comments on Gerrit Holl''s pre-pep, which
can be found here:
http://tinyurl.com/2578q
Frankly, I like the idea. It''s about time that all of the file
and directory stuff in the os module got objectified
properly (or at least with some semblance of OO propriety!)
In the issues section:
[ snipping those points where I agree with John ]
4）路径是否应该公开listdir的迭代器（？）
我不知道为什么不，只要路径是一个
目录。
4) Should path expose an iterator for listdir(?)
I don''t see why not, as long as the path is to a
directory.
_An_ iterator，当然，但不是__iter__。 path.listdir（）怎么样？ :)
__iter__也可以遍历路径元素，所以它至少是模棱两可的。
_An_ iterator, sure, but not __iter__. How about path.listdir()? :)
__iter__ could also iterate over the path elements, so it''s ambiguous at
least.
我看到你的''说。我会（轻声地）讨论迭代
目录条目是自然的解释。
I see what you''re saying. I''d argue (softly) that iterating over
the directory entries is the natural interpretation, though.
15文件和目录应该是相同的
类。
可能不是。虽然它们共享许多常见的功能（应该作为
界面拼写），但它们也有很多不同的功能。分离它们也可以很容易地为符号链接之类的东西创建对象。
15. Should files and directories be the same
class.
Probably not. While they share a lot of common
functionality (which should be spelled out as an
interface) they also have a lot of dissimilar
functionality. Separating them also makes it easy
to create objects for things like symbolic links.
但是对于尚未存在的文件夹文件的路径呢？我不认为你实际应该_hit_文件系统，如果你所做的只是
path.join（）。
But what about paths for not-yet-existing files of folders? I don''t
think you should actually _hit_ the file system, if all you''re doing is
path.join().
我同意这里。我还没有看过任何候选实现
，所以我不知道他们在做什么。我在考虑一个
三类结构：父类只是路径操作;
它有两个子类，一个用于实际文件，一个用于实际目录。
那样他们不仅可以继承所有常见的路径操作
的东西，而且开发人员可以实例化纯路径操作
类同样。
可能还有一个mixin将那些常见的东西封装到真实的文件和目录中，比如访问和更改日期和
权限。
我确定有一些用例会在该结构上产生曲线
。
只是
I agree here. I haven''t looked at any of the candidate implementations
yet, so I don''t know what they''re doing. I''m thinking of a
three class structure: the parent class is just the path manipulations;
it has two subclasses, one for real files and one for real directories.
That way they can not only inherit all of the common path manipulation
stuff, but the developer can instantiate a pure path manipulation
class as well.
There might also be a mixin that encapsulates the stuff that''s common
to real files and directories like accessing and changing dates and
permissions.
I''m sure there are use cases that will throw a curve at that structure
as well.
Just
在文章< vv ************ @ news .supernews.com>，
" John Roth" <是ne ******** @ jhrothjr.com>写道：
In article <vv************@news.supernews.com>,
"John Roth" <ne********@jhrothjr.com> wrote:
4）路径是否应公开listdir的迭代器（？）
我不知道为什么不，只要路径是一个
目录。
4) Should path expose an iterator for listdir(?)
I don''t see why not, as long as the path is to a
directory.
_An_ iterator，当然，但不是__iter__。 path.listdir（）怎么样？ :)
__iter__也可以迭代路径元素，所以它至少是模棱两可的。
_An_ iterator, sure, but not __iter__. How about path.listdir()? :)
__iter__ could also iterate over the path elements, so it''s ambiguous at
least.
我看到你在说什么。我会（轻柔地）争论说，目录条目的迭代是自然的解释。
I see what you''re saying. I''d argue (softly) that iterating over
the directory entries is the natural interpretation, though.
这对我来说太隐含了味道;因为它只是一个文件夹
操作（并且我没有看到为
文件夹和文件路径分别设置单独的类）。你是否也赞成交换
文件路径意味着迭代文件中的行？
只是
It''s far too implicit to my taste; for one since it''s a folder-only
operation (and I don''t see much merit in having separate classes for
folder and file paths). Would you also be in favor of interating over
file-paths meaning iterating over the lines in the file?
Just
这篇关于PRE-PEP：新的Path类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
