Mike Orr wrote:
> They're now called PathName and Path.
Not a sane choice of names, since in this context,
"path" and "pathname" are synonymous in ordinary
language.
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mail
On 11/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 11/26/06, Mike Orr <[EMAIL PROTECTED]> wrote:
> > On 11/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > C: without a slash is effectively a mount point into
> > > the current directory.
>
> > That's what I always thought "C:foo" is. But G
On 11/26/06, Mike Orr <[EMAIL PROTECTED]> wrote:
> On 11/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 11/26/06, Mike Orr <[EMAIL PROTECTED]> wrote:
> > > I tried to make a separate PathAlgebra class and
> > > FSPath class, but it got so unweildly to use I made
> > > the latter a subclass. T
On 11/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 11/26/06, Mike Orr <[EMAIL PROTECTED]> wrote:
> > I tried to make a separate PathAlgebra class and FSPath class, but it
> > got so unweildly to use I made the latter a subclass. They're now
> > called PathName and Path.
>
> This makes sense t
On 11/26/06, Mike Orr <[EMAIL PROTECTED]> wrote:
> I tried to make a separate PathAlgebra class and FSPath class, but it
> got so unweildly to use I made the latter a subclass. They're now
> called PathName and Path.
This makes sense to me. An FSPath without path algebra is basically a
"director
Status update and questions about root splitting.
I've got a path module written (called unipath) and am in the middle
of the unit tests. When they're done I'll release it for review.
It's been slow coz I was setting up two computers at the same time.
I tried to make a separate PathAlgebra clas
"Paul Moore" <[EMAIL PROTECTED]> writes:
>> I use 'posix' paths as my universal format. I convert them to native
>> paths just before writing them out or passing to a subsystem that
>> requires native paths.
>
> Not a valid option. C:\Data\a_file.txt is a perfectly valid posix
> format filename. I
Niki Spahiev wrote:
> Maybe use file: URLs for universal format. They become more and more
> used in internet era.
You still need some outside way of telling whether
you're dealing with a universal format, since
"file:" is a valid pathname component in Unix,
a valid volume name in classic MacOS,
On 11/10/06, Niki Spahiev <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > What if you need to know whether it's an absolute or
> > relative path, e.g. so you can join it to another path?
> > You can't do that without knowing something about the
> > semantics.
> Maybe use file: URLs for universa
Greg Ewing wrote:
> What if you need to know whether it's an absolute or
> relative path, e.g. so you can join it to another path?
> You can't do that without knowing something about the
> semantics.
Maybe use file: URLs for universal format. They become more and more
used in internet era.
Niki
On 11/10/06, Talin <[EMAIL PROTECTED]> wrote:
> What I am arguing against is an overly strict and pedantic
> interpretation of the differences in path representation across
> platforms. True, in theory, you can't compare a windows path with a
> posix path, but in practice it generally "just works".
Mike Orr wrote:
> I'm looking for "we need a method named foo with signature bar that
> does this..." Or "make sure method blah doesn't do this"
> Otherwise I don't know what to do with the information. Can you make
> a use case showing how you'd ideally like to interact with the module
>
On 11/9/06, Talin <[EMAIL PROTECTED]> wrote:
> Mike Orr wrote:
> > On 11/9/06, Talin <[EMAIL PROTECTED]> wrote:
> >> (This is a good reason to have paths represented as strings instead of
> >> as a tuple, since you can't defer interpretation this way with
> >> pre-parsed paths.)
> >
> > Er, is ther
Mike Orr wrote:
> On 11/9/06, Talin <[EMAIL PROTECTED]> wrote:
>> Bill Janssen wrote:
>>> 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.
>> That's not difficul
On 11/9/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > I use 'posix' paths as my universal format.
>
> That assumes you can always distinguish a posix path from
> some other kind of path. That's not always the case,
> e.g. consider
>
>/hello:wide/world
>
> Is that a posix path or
Talin wrote:
> Bill Janssen wrote:
>
> > All native formats both past and future.
>
> That's not difficult.
>
> I use 'posix' paths as my universal format.
That assumes you can always distinguish a posix path from
some other kind of path. That's not always the case,
e.g. consider
/hello:wid
On 11/9/06, Mike Orr <[EMAIL PROTECTED]> wrote:
> the destination format will at least recognize it as an even if it
> doesn't know what it means.
... recognize it as an absolute path ...
--
Mike Orr <[EMAIL PROTECTED]>
___
Python-3000 mailing list
Py
On 11/9/06, Talin <[EMAIL PROTECTED]> wrote:
> Bill Janssen wrote:
> > 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.
>
> That's not difficult.
>
> I use '
Le jeudi 09 novembre 2006 à 20:45 +, Paul Moore a écrit :
> Again, I don't believe this is possible for all corner cases: what is
> the drive for /my/file on a Windows system?
Why not the current drive?
> If you mandate that all filenames must be relative, you could manage,
> but enforcing t
On 11/9/06, Talin <[EMAIL PROTECTED]> wrote:
> Bill Janssen wrote:
> > 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.
>
> That's not difficult.
>
> I use '
Bill Janssen wrote:
> 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.
That's not difficult.
I use 'posix' paths as my universal format. I convert them to native
pa
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
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
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
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
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
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
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
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
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
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:
>> 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
On 11/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> .abspath()
> >>>
> >>>I've always thought this was a strange function. To be honest, I'd
> >>>rather explicitly pass in the cwd().
> >>
> >>I use it; it's convenient. The method name could be improved.
>
> It does violate the constraint o
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 create a platform-specific p
How do you convert an absolute path anyway?
PosixPath(NTPath("C:\winnt\system")) => ??
NTPath(PosixPath("/mnt/cdrom") => ??
You can convert them to "/winnt/system" and "\mnt\cdrom", but what's
the point? They won't exist anyway.
--
Mike Orr <[EMAIL PROTECTED]>
On 11/7/06, Talin <[EMAIL PROTECTED]> wrote:
> Mike Orr wrote:
> > My latest idea is something like this:
> >
> > BEGIN
> > class Path(unicode):
> > """Pathname-manipulation methods."""
> > pathlib = os.path # Subclass can specify
> > (posix|nt|mac)path.
> > safe_args
Mike Orr wrote:
> My latest idea is something like this:
>
> BEGIN
> class Path(unicode):
> """Pathname-manipulation methods."""
> pathlib = os.path # Subclass can specify (posix|nt|mac)path.
> safe_args_only = False# Glyph can set this to True in a subclass.
>
I
> [Mike Orr wrote:]
> In this vein, a common utility module with back-end functions would be
> good. Then we can solve the difficult problems *once* and have a test
> suite that proves it, and people would have confidence using any OO
> classes that are built over them. We can start by gathering
Le lundi 06 novembre 2006 à 14:37 -0800, Mike Orr a écrit :
> def __init__(klass, *args):
> if len(args) == 1 and isinstance(args[0], klass.path_class):
> self.path = args[0]
> else:
> self.path = self.path_class(*args)
s/klass/self/, I suppose ?
> Subc
My latest idea is something like this:
BEGIN
class Path(unicode):
"""Pathname-manipulation methods."""
pathlib = os.path # Subclass can specify (posix|nt|mac)path.
safe_args_only = False# Glyph can set this to True in a subclass.
class FSPath(object):
"""File
Josiah Carlson wrote:
> Talin <[EMAIL PROTECTED]> wrote:
>> I'd like to replace this with:
>>
>> .component( slice_object )
>>
>> where the semantics of 'component' are identical to __getitem__ on an
>> array or tuple. So for example:
>>
>> Path( "a", "b" ).component( 0 ) => "a"
>> Pat
Talin <[EMAIL PROTECTED]> wrote:
> I'd like to replace this with:
>
> .component( slice_object )
>
> where the semantics of 'component' are identical to __getitem__ on an
> array or tuple. So for example:
>
> Path( "a", "b" ).component( 0 ) => "a"
> Path( "a", "b" ).component( 1 )
Mike Orr wrote:
> Posted to python-dev and python-3000. Follow-ups to python-dev only please.
>
> So, let's say we strip this Path class to:
I'm finally taking the time to sit down and go over this in detail. Here
are some suggestions.
> class Path(unicode):
> Path("foo")
> Path( Path
Mike Orr wrote:
> The multi-argument constructor is a replacement for joining paths.
> (The PEP says .joinpath was "problematic" without saying why.)This
> could theoretically go either way, doing either the same thing as
> os.path.join, getting a little smarter, or doing "safe" joins by
> dis
Mike Orr wrote:
> .abspath()
> .normpath()
> .realpath()
> .splitpath()
> .relpath()
> .relpathto()
Seeing as the whole class is about paths, having
"path" in the method names seems redundant. I'd
prefer to see terser method names without any
noise characters in them.
--
On 11/2/06, Mike Orr <[EMAIL PROTECTED]> wrote:
> Given the widely-diverging views on what, if anything, should be done
> to os.path, how about we make a PEP and a standalone implementation of
> (1) for now, and leave (2) and everything else for a later PEP.
Why write a PEP at this stage? Just rel
Posted to python-dev and python-3000. Follow-ups to python-dev only please.
On 10/31/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> here's mine; it's fully backwards compatible, can go right into 2.6,
> and can be incrementally improved in future releases:
>
> 1) add a pathname wrapper to "
47 matches
Mail list logo
