[boost] Re: Re: [Filesystem] i18n

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-04-06 20:22:32

"Rob Stewart" <stewart_at_[hidden]> wrote in message 
news:200504051942.j35JgJR05410_at_vanzandt.balstatdev.susq.com...
> From: "Beman Dawes" <bdawes_at_[hidden]>
>>
> ...  The key is to understand that
> is_directory() returns true iff the supplied pathname is a
> directory to the caller.  That means it must exist, be
> accessible, and be a directory.  Anything else isn't a directory,
> so far as the caller is concerned.

If it is a CD-ROM, and a little slow to become ready (as happened to me 
several times in experimenting with how Python handles these cases), it 
really strikes me as stretching it to ignore the "Not ready" error. 
Likewise, when working across a network, and the network goes down, to we 
really want something that was a directory a second ago to become not a 
directory?

> Also, don't forget that with other, more detailed means to get
> information on a pathname, like the stat() (or whatever you
> choose to call it) function, one can get more precise information
> if warranted by the code.

I'd rather require those who want to bypass error checks to use status().

> I recall that your original notion for the Filesystem library was
> to enable script-like coding in C++.  Such code is less rigorous
> than normal applications.

I don't buy that. I've seen really seriously flawed data get shipped to 
customers, doing untold harm to the business, because production scripts 
ignored errors.

>  That's not to say that it need be
> sloppy, but it is often more forgiving.  I'll again refer to my
> years of writing shell scripts on *nix.  The -d test never
> generates a signal (the moral equivalent of an exception in C++
> in this case); it just returns true or false.  That simplicity
> makes it easier to write scripts, though I'll grant that it does
> mean you have to be a little careful to not make too many
> assumptions about what ! -d means.

That's fine, but the default should be to not ignore errors, rather than the 
other way around, IMO.

>> But it looks from other's responses that I'm out voted. And it isn't just
>> people who have commented on this list. I tested the Python os.path 
>> library,
>> and its isdir() function doesn't even throw if the entire file system 
>> goes
>> offline.
>
> The number of votes is still pretty small, I think.  I would
> obviously not complain if you agreed with me, but I'd feel more
> comfortable if there was more feedback.

Following Dave's suggestion, I've posted a query on comp.lang.python to see 
if I can find the rationale for their treatment of errors on queries.

Also, my guess is that it is a little hard for most people to follow the 
several aspects of this discussion that we think should result in changes to 
the current library. Thus I may implement status(), recast exists() and the 
is_x() functions in terms of status(), and try to come up with a firmer (and 
testable) definition of what the status attributes mean (to answer Peter's 
very valid concerns about exact meaning.)

That will give people something firmer to comment on. But due to other 
commitments, it may be three or four weeks before I can do that.

Thanks,

--Beman