Mike Orr wrote:
>> And again, it strays outside the domain of path algebra
>> operations.
>
> This is also the same issue. Where do we put the .expand*() methods
> if not on Path?
For the moment, I'd say that if an operation can raise any flavour of
EnvironmentError, don't make it a method of t
Greg Ewing wrote:
> Talin wrote:
>
>> I'm a little confused here about the model of how platform-specific
>> and application-specific formats are represented. Is it the case that
>> the creation function converts the platform-specific path into a
>> generic, universal path object, or does it cr
Mike Orr wrote:
> Remember that 99% of Python programmers are concerned only with native
> paths. I have never used a non-native path or multiple-platform paths
> in an application. So we need to make the native case easy and clear.
> For that reason I'd rather keep the non-native cases and conv
Nick Coghlan wrote:
> I realise this means normalisation and symbol expansion will be defined only
> on FSPath's.
Scratch the bit about normalisation not being defined on the path algebra
object - as the latter part of the previous email noted, normalisation *is*
path algebra based. It just has
On 11/8/06, Talin <[EMAIL PROTECTED]> wrote:
> What I want to avoid is a situation where I have to edit my config file
> to switch all the path separators from '/' to '\' when I move my
> application from OS X to Win32.
This requirement conflicts with that of a user who only uses one
platform, an
On 11/8/06, Talin <[EMAIL PROTECTED]> wrote:
> What I want is a way to have data files that contain embedded paths
> encoded in a way that allows those data files to be transported across
> platform. Generally those embedded paths will be relative to something,
> rather than fully-qualfied, such as
Mike Orr wrote:
> What do we do with Path.cwd() then? It also violates the
> path-algrebra-only logic. We can put it on FSPath, but then
> it's the only FSPath method that returns a Path
I don't see why it should be a problem for an FSPath
method to return a Path.
> Where do we put the .expand
Talin wrote:
> If this were not true, 'make' could never work across filesystems. You'd
> have to have a different makefile for every different filesystem type.
Ever tried to use a Unix makefile on classic MacOS
or VMS? It wouldn't work very well at all...
Even relative pathnames can have seman
Talin wrote:
> I think that there's a reasonable chance of acceptance for an object
> that does filesystem-like operations that *doesn't overlap* with what
> the Path object does. But what you are proposing is a *superset* of what
> Path does (because you're saying its a subclass), and I don't
Paul Moore wrote:
> This requirement conflicts with that of a user who only uses one
> platform, and wants (expects) to just enter paths in native format in
> the config file.
If the standard format were designed so as to be
unambiguously distinguishable from all native
formats, paths in either s
Greg Ewing writes:
> If the standard format were designed so as to be
> unambiguously distinguishable from all native
> formats, ...
All native formats both past and future.
Bill
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.or
11 matches
Mail list logo
