On Wed, Jan 25, 2006 at 10:24:51PM +, Alberto Sim?es wrote:
For me, both options are reasonable. Chip's proposal have the advantage
of caching the info. Using is_dir and is_file to stat everytime, have
the advantage of not having a specific Stat PMC object.
Other option, is having one
Hi
After some discussion on #parrot, and after Leo direct me to this link:
http://mail.python.org/pipermail/python-dev/2006-January/060026.html
Follows some discussion on File.pmc.
1) What it is now.
At the moment we have two OS dependent PMCs: OS and File.
OS includes stat, mkdir, remove,
On Wed, Jan 25, 2006 at 09:10:50PM +, Alberto Simões wrote:
2) What it might be.
My first idea is to join both PMCs, and create a FileSystem PMC. The
main problem is its name. After looking to Python discussion, and
thinking a little on the PIR syntax, I would call it Path.
3)
Nicholas Clark wrote:
Is your implementation going to cope with one OS having several different
types of file systems mounted, that might have different specific behaviours?
I know that HFS+, ufs and ext3 all have various forms of flags/extended
attributes, and in turn I'd assume that a
Without -yet- commenting on the File/OS/Filesystem issue, this bit of code
is either substantially wrong or just a convenience wrapper around what's
really going on:
On Wed, Jan 25, 2006 at 09:10:50PM +, Alberto Simões wrote:
$P0 = new .Path(/foo/bar)
[...]
$P0.is_dir()
It is necessary that Parrot's filesystem interface make user-visible the
_event_ of measuring the attributes of a path _or_ an already open
filesystem object (e.g. calling stat() or fstat()). It must also represent
the bundle of measurements returned as some kind of PMC. (handwave handwave)
I
