[path-PEP]路径再次从basestring继承 [英] [path-PEP] Path inherits from basestring again

问题描述

前一个帖子中的参数足够令人信服，所以我再次从str / unicode继承了

Path类。 />

它仍然可以在CVS中找到：/ python/nondist/sandbox/path/ {path.py，test_path.py}


一件事但是仍然不同：Path实例不会与普通的

字符串进行比较。


其他细微差别，如p​​ython-dev所要求的，是：


*尺寸属性 - > getsize（）方法。

* atime / mtime / ctime属性 - > atime（）/ mtime（）/ ctime（）方法


* dirname（）方法 - >目录属性

*没有父属性

* basename（）方法 - > basename property

*没有名称属性


* listdir（）方法 - > children（）方法

*还有一个listdir（）方法，但是带有os.listdir的语义

* dirs（）方法 - > subdirs（）方法

* joinpath（）方法 - >添加别名joinwith（）

* splitall（）方法 - > parts（）方法


*默认构造函数：Path（）== Path（os.curdir）

* staticmethod Path.getcwd（） - > Path.cwd（）


* bytes（）/ lines（）/ text（） - > read_file_ {bytes，lines，text}方法

* write_ {bytes，lines，text} - > write_file_ {bytes，lines，text}方法


这些可能会被移除。


Reinhold

解决方案

Reinhold Birkenfeld写道：

但有一件事情仍然不同：路径实例不会与普通的
字符串相比。


您能否详细说明这意味着什么？你指的是做什么

<和> =在路径和字符串上键入操作，或者==和！=或者所有那些

其他细微差别，如p​​ython上所要求的那样dev，是：

* size property - > getsize（）方法。
* atime / mtime / ctime属性 - > atime（）/ mtime（）/ ctime（）方法


这是什么意思？

已经存在.size属性和一个getize（）方法（无论如何都在我的path.py副本中）并做同样的事情。

与其他的相同上文提到的。是否有人使用

过期的path.py副本？

* dirs（）方法 - > subdirs（）方法


鉴于.files（）存在，并返回

a路径中包含的文件列表，该路径代表一个文件夹，为什么会出现想使用subdirs（）

而不是dirs（）对包含的文件夹执行相同的操作？

如果首选subdirs（），那么我建议使用子文件（）同样。否则

这种变化似乎是武断的，而且构思错误。

* joinpath（）方法 - >添加别名joinwith（）
* splitall（）方法 - > parts（）方法


这让我想起了我能想到的一个*优点：

继承basetring，尽管它仍然没有

的区别我的想法：字符串已经有了split（），所以Jason必须使用

" splitpath（）"用于基本拆分操作以避免冲突。一个

小疣我猜。

*默认构造函数：Path（）== Path（os.curdir）


To构造一个空路径然后仍然可以做路径（''''）？

* staticmethod Path.getcwd（） - > Path.cwd（）

* bytes（）/ lines（）/ text（） - > read_file_ {bytes，lines，text}方法
* write_ {bytes，lines，text} - > write_file_ {bytes，lines，text}方法

在Linux下无法打开和读取目​​录，因为

with文件？如果这是真的，上面的内容似乎会以某种方式与

冲突。与上面的.subdirs（）建议一样，这些更改在我看来有点武断。 .bytes（）和朋友们在实际使用中感觉非常友好，而且我怀疑.read_file_bytes（）会感觉很尴尬。然而，并不是一个表演者。


-Peter

Peter Hansen写道：

在Linux下是不是可以像文件一样打开和读取目​​录？

不是真的，没有。


Python 2.3.4（＃2，2005年1月5日，08：24：51）

[GCC 3.3.5（Debian 1：3.3.5-5）]在linux2上

输入help，copyright，credit等等。或许可证或更多信息。

d = open（''/ usr / bin''）
Traceback（最近一次通话）最后）：

文件"< stdin>"，第1行，在？

IOError：[Errno 21]是一个目录

-

Robert Kern
rk***@ucsd.edu


在草地长高的地狱里

是否允许坟墓死亡。

- Richard Harter

Peter Hansen写道：

Reinhold Birkenfeld写道：

但有一件事情仍然不同：路径实例不会与普通的
字符串进行比较。

你能不能请扩展这意味着什么？你指的是做
<和> =在路径和字符串上键入操作，或者==和！=或者所有那些
或完全不同的东西？

所有这些。你需要它们吗？

根据python-dev的要求，其他细微差别是：

* size属性 - > getsize（）方法。
* atime / mtime / ctime属性 - > atime（）/ mtime（）/ ctime（）方法

这是什么意思？ .size属性和一个getsize（）方法都已存在（无论如何都在我的path.py副本中）并做同样的事情。
与上面提到的其他内容相同。是否有人使用
过时的path.py副本？

编号但是文件的大小有点不稳定，并且不喜欢

a" property"它的路径。请记住：路径不是文件。相同的

与xtime（）方法一致。


不同的是basename /目录/ etc：只要路径保持不变，

这些属性将保持不变。

* dirs（）方法 - > subdirs（）方法

鉴于.files（）存在，并返回
一个代表文件夹的路径中包含的文件列表，为什么要使用subdirs（）
而不只是dirs（）对包含的文件夹执行相同的操作？
如果首选subdirs（），那么我也建议使用子文件（）。否则，这种变化似乎是武断的，而且构思错误。

嗯，我认为这是正确的。将改回dirs（）。

* joinpath（）方法 - >添加别名joinwith（）
* splitall（）方法 - > parts（）方法

这让我想起了我可以想到的一个*优点，而不是
子类化basetring，尽管它仍然没有区别于
我的想法：字符串已经有了split（），所以Jason必须使用
splitpath（）用于基本拆分操作以避免冲突。我猜是一个
小疣。

目前，我认为重写某些字符串方法会使

完全没有意义在路径上并从中提出异常。

*默认构造函数：Path（）== Path（os.curdir）

要构建一个空路径，那么仍然可以做路径（''''）？

是。

* staticmethod Path.getcwd（） - > Path.cwd（）

* bytes（）/ lines（）/ text（） - > read_file_ {bytes，lines，text}方法
* write_ {bytes，lines，text} - > write_file_ {bytes，lines，text}方法

在Linux下打开和读取目​​录与文件一样多吗？如果这是真的，那么上述似乎与某种方式相冲突。与上面的.subdirs（）建议一样，这些变化在我看来有点武断。 .bytes（）和朋友们在实际使用中感觉非常友好，我怀疑.read_file_bytes（）会觉得很笨拙。然而，并不是一个表演停止者。

甚至有人建议将它们扔出去，因为它们没有那么多来支付
本身就是路径。当界面负担太重时，我们将有更少的机会被接受。重命名这些清楚表明它们不是路径上的操作

，而是路径指向的文件。


Phillip J. Eby建议这些是set_file_xxx和get_file_xxx演示

他们不读或写流;怎么样？


Reinhold

Hi,

the arguments in the previous thread were convincing enough, so I made the
Path class inherit from str/unicode again.

It still can be found in CVS: /python/nondist/sandbox/path/{path.py,test_path.py}

One thing is still different, though: a Path instance won''t compare to a regular
string.

Other minor differences, as requested on python-dev, are:

* size property -> getsize() method.
* atime/mtime/ctime properties -> atime()/mtime()/ctime() methods

* dirname() method -> directory property
* no parent property
* basename() method -> basename property
* no name property

* listdir() method -> children() method
* there is still a listdir() method, but with the semantics of os.listdir
* dirs() method -> subdirs() method
* joinpath() method -> added alias joinwith()
* splitall() method -> parts() method

* Default constructor: Path() == Path(os.curdir)
* staticmethod Path.getcwd() -> Path.cwd()

* bytes() / lines() / text() -> read_file_{bytes,lines,text} methods
* write_{bytes,lines,text} -> write_file_{bytes,lines,text} methods

These may be removed though.

Reinhold

解决方案

Reinhold Birkenfeld wrote:

One thing is still different, though: a Path instance won''t compare to a regular
string.
Could you please expand on what this means? Are you referring to doing
< and >= type operations on Paths and strings, or == and != or all those
or something else entirely?
Other minor differences, as requested on python-dev, are:

* size property -> getsize() method.
* atime/mtime/ctime properties -> atime()/mtime()/ctime() methods
What does this mean? The .size property and a getsize() method both
already exist (in my copy of path.py anyway) and do the same thing.
Same with the other ones mentioned above. Is someone working from an
out-of-date copy of path.py?
* dirs() method -> subdirs() method
Given that .files() exists, and returns a list of the files contained in
a path which represents a folder, why would one want to use subdirs()
instead of just dirs() to do the same operation for contained folders?
If subdirs() is preferred, then I suggest subfiles() as well. Otherwise
the change seems arbitrary and ill-conceived.
* joinpath() method -> added alias joinwith()
* splitall() method -> parts() method
This reminds me of the *one* advantage I can think of for not
subclassing basestring, though it still doesn''t make the difference in
my mind: strings already have "split()", so Jason had to go with
"splitpath()" for the basic split operation to avoid a conflict. A
minor wart I guess.
* Default constructor: Path() == Path(os.curdir)
To construct an empty path then one can still do Path('''') ?
* staticmethod Path.getcwd() -> Path.cwd()

* bytes() / lines() / text() -> read_file_{bytes,lines,text} methods
* write_{bytes,lines,text} -> write_file_{bytes,lines,text} methods

Under Linux isn''t it possible to open and read from directories much as
with files? If that''s true, the above would seem to conflict with that
in some way. As with the the .subdirs() suggestion above, these changes
seem to me somewhat arbitrary. .bytes() and friends have felt quite
friendly in actual use, and I suspect .read_file_bytes() will feel quite
unwieldy. Not a show-stopper however.

-Peter

Peter Hansen wrote:

Under Linux isn''t it possible to open and read from directories much as
with files?

Not really, no.

Python 2.3.4 (#2, Jan 5 2005, 08:24:51)
[GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

d = open(''/usr/bin'') Traceback (most recent call last):
File "<stdin>", line 1, in ?
IOError: [Errno 21] Is a directory

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Peter Hansen wrote:

Reinhold Birkenfeld wrote:

One thing is still different, though: a Path instance won''t compare to a regular
string.

Could you please expand on what this means? Are you referring to doing
< and >= type operations on Paths and strings, or == and != or all those
or something else entirely?

All of these. Do you need them?

Other minor differences, as requested on python-dev, are:

* size property -> getsize() method.
* atime/mtime/ctime properties -> atime()/mtime()/ctime() methods

What does this mean? The .size property and a getsize() method both
already exist (in my copy of path.py anyway) and do the same thing.
Same with the other ones mentioned above. Is someone working from an
out-of-date copy of path.py?

No. But the size of a file is somewhat volatile, and does not feel like
a "property" of the path to it. Remember: the path is not the file. Same
goes with the xtime() methods.

Different is the basename/directory/etc.: as long as the path stays the same,
these properties will stay the same.

* dirs() method -> subdirs() method

Given that .files() exists, and returns a list of the files contained in
a path which represents a folder, why would one want to use subdirs()
instead of just dirs() to do the same operation for contained folders?
If subdirs() is preferred, then I suggest subfiles() as well. Otherwise
the change seems arbitrary and ill-conceived.

Well, I think that''s right. Will change back to dirs().

* joinpath() method -> added alias joinwith()
* splitall() method -> parts() method

This reminds me of the *one* advantage I can think of for not
subclassing basestring, though it still doesn''t make the difference in
my mind: strings already have "split()", so Jason had to go with
"splitpath()" for the basic split operation to avoid a conflict. A
minor wart I guess.

At the moment, I think about overriding certain string methods that make
absolutely no sense on a path and raising an exception from them.

* Default constructor: Path() == Path(os.curdir)

To construct an empty path then one can still do Path('''') ?

Yes.

* staticmethod Path.getcwd() -> Path.cwd()

* bytes() / lines() / text() -> read_file_{bytes,lines,text} methods
* write_{bytes,lines,text} -> write_file_{bytes,lines,text} methods

Under Linux isn''t it possible to open and read from directories much as
with files? If that''s true, the above would seem to conflict with that
in some way. As with the the .subdirs() suggestion above, these changes
seem to me somewhat arbitrary. .bytes() and friends have felt quite
friendly in actual use, and I suspect .read_file_bytes() will feel quite
unwieldy. Not a show-stopper however.

It has even been suggested to throw them out, as they don''t have so much to
do with a path per se. When the interface is too burdened, we''ll have less
chance to be accepted. Renaming these makes clear that they are not operations
on the path, but on a file the path points to.

Phillip J. Eby suggested these to be set_file_xxx and get_file_xxx to demonstrate
that they do not read or write a stream; how about that?

Reinhold

这篇关于[path-PEP]路径再次从basestring继承的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！