Ethan Furman stoneleaf.us> writes:
>
> That's a decent point.
>
> So the plausible choices are, I think:
>
> - __fspath__ # File System Path -- possible confusion with Path
This would have my preference.
Regards
Antoine.
___
Python-Dev mailing l
On Sat, Apr 9, 2016 at 10:48 AM, Nick Coghlan wrote:
> On 9 April 2016 at 04:25, Brett Cannon wrote:
>> On Fri, 8 Apr 2016 at 11:13 Ethan Furman wrote:
>>> On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
>>> > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
>>> >> On Fri, Apr 8, 2016 at 9:
On 11 April 2016 at 01:50, Donald Stufft wrote:
>
>> On Apr 10, 2016, at 2:43 AM, Nick Coghlan wrote:
>>
>> This does raise a concrete API design question: how should
>> PurePath.__fspath__ behave when called on a mismatched OS?
>
> I think that PurePath.__fspath__ should return a string. There’s
> On Apr 10, 2016, at 2:43 AM, Nick Coghlan wrote:
>
> This does raise a concrete API design question: how should
> PurePath.__fspath__ behave when called on a mismatched OS?
I think that PurePath.__fspath__ should return a string. There’s no
reason why we can’t in my opinion and doing so just
On 04/10/2016 12:36 AM, Nick Coghlan wrote:
On 10 April 2016 at 17:12, Greg Ewing wrote:
But there needs to be some way to ask a path object for
its native string representation, otherwise there would
be no point in using foreign path objects at all.
In addition to the existing "str(pathobj)
On Sun, 10 Apr 2016 18:51:23 +1200, Greg Ewing
wrote:
> > On 9 April 2016 at 23:02, R. David Murray wrote:
> >
> >>That is, a 'filename' is the identifier we've assigned to this thing
> >>pointed to by an inode in linux, but an os path is a text representation
> >>of the path from the root file
On 10 April 2016 at 08:36, Nick Coghlan wrote:
> In addition to the existing "str(pathobj)", a "path" property was
> recently added for that purpose:
>
>>>> import pathlib
>>>> pathlib.PureWindowsPath(".")
>PureWindowsPath('.')
>>>> pathlib.PureWindowsPath(".").path
>'.'
>
> (T
On 10 April 2016 at 17:12, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> Similar to my proposal for dealing with DirEntry.path being a
>> bytes-like object, I'd like to suggest raising TypeError in __fspath__
>> if the request is nonsensical for the currently running system - *nix
>> systems can *
Nick Coghlan wrote:
Similar to my proposal for dealing with DirEntry.path being a
bytes-like object, I'd like to suggest raising TypeError in __fspath__
if the request is nonsensical for the currently running system - *nix
systems can *manipulate* Windows paths (and vice-versa), but actually
tryi
On 9 April 2016 at 23:02, R. David Murray wrote:
That is, a 'filename' is the identifier we've assigned to this thing
pointed to by an inode in linux, but an os path is a text representation
of the path from the root filename to a specified filename. That is,
the path *is* the name, so to say
On 10 April 2016 at 15:58, Greg Ewing wrote:
> Brett Cannon wrote:
>
>> Depends if you use `/` or `\` as your path separator
>
>
> Or whether your pathnames look entirely different, e.g VMS:
>
> device:[topdir.subdir.subsubdir]filename.ext;version
>
> Pathnames are very much OS-dependent in both
Eric Snow wrote:
All this matters because it impacts the value returned from
__ospath__(). Should it return the string representation of the path
for the current OS or some standardized representation?
What standardized representation? I'm not aware of such
a thing.
I'd expect
the former. H
Brett Cannon wrote:
Depends if you use `/` or `\` as your path separator
Or whether your pathnames look entirely different, e.g VMS:
device:[topdir.subdir.subsubdir]filename.ext;version
Pathnames are very much OS-dependent in both syntax *and* semantics.
Even the main two in use today (un
On 9 April 2016 at 23:02, R. David Murray wrote:
> That is, a 'filename' is the identifier we've assigned to this thing
> pointed to by an inode in linux, but an os path is a text representation
> of the path from the root filename to a specified filename. That is,
> the path *is* the name, so to
On Sat, 09 Apr 2016 17:48:38 +1000, Nick Coghlan wrote:
> On 9 April 2016 at 04:25, Brett Cannon wrote:
> > On Fri, 8 Apr 2016 at 11:13 Ethan Furman wrote:
> >> On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
> >> > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
> >> >> On Fri, Apr 8, 201
On Fri, Apr 8, 2016 at 9:09 PM, Chris Angelico wrote:
> On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker
> wrote:
> > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven
> wrote:
> >>
> >> >
> >> > __pathstr__ # pathstring
> >> >
> >>
> >> Or perhaps __pathstring__ in case it may be or return byte str
On 9 April 2016 at 04:25, Brett Cannon wrote:
> On Fri, 8 Apr 2016 at 11:13 Ethan Furman wrote:
>> On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
>> > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
>> >> On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
>>
>> >>> I'm still thinking
On Fri, Apr 8, 2016 at 7:41 PM, Brett Cannon wrote:
>
>
> On Fri, Apr 8, 2016, 16:13 Glenn Linderman wrote:
>>
>> On 4/8/2016 3:28 PM, Eric Snow wrote:
>>
>> All this matters because it impacts the value returned from
>> __ospath__(). Should it return the string representation of the path
>> for
On Fri, Apr 8, 2016, 16:13 Glenn Linderman wrote:
> On 4/8/2016 3:28 PM, Eric Snow wrote:
>
> All this matters because it impacts the value returned from
> __ospath__(). Should it return the string representation of the path
> for the current OS or some standardized representation? I'd expect
>
On 4/8/2016 3:28 PM, Eric Snow wrote:
All this matters because it impacts the value returned from
__ospath__(). Should it return the string representation of the path
for the current OS or some standardized representation? I'd expect
the former. However, if that is the expectation then somethi
On 4/8/2016 11:25 AM, Brett Cannon wrote:
I personally still like __ospath__ as well.
+1. Because they aren't always files... but what else they might be is
os dependent.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
On Fri, Apr 8, 2016 at 3:57 PM, Eric Snow wrote:
> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
>> I personally still like __ospath__ as well.
>
> Same here. The strings are essentially an OS-dependent serialization,
> rather than related to a particular file system.
Hmm. It's importan
On Fri, 8 Apr 2016 at 15:21 Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> > On Apr 8, 2016, at 3:00 PM, Eric Snow
> wrote:
> >
> >> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
> >> I personally still like __ospath__ as well.
> >
> > Same here. The strings are essentiall
> On Apr 8, 2016, at 3:00 PM, Eric Snow wrote:
>
>> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
>> I personally still like __ospath__ as well.
>
> Same here. The strings are essentially an OS-dependent serialization,
> rather than related to a particular file system.
Huh? I though the
On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
> I personally still like __ospath__ as well.
Same here. The strings are essentially an OS-dependent serialization,
rather than related to a particular file system.
-eric
___
Python-Dev mailing list
On Fri, Apr 8, 2016 at 11:39 PM, R. David Murray wrote:
> On Fri, 08 Apr 2016 19:24:44 -, Brett Cannon wrote:
>> On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote:
>>
>> > On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker
>> > wrote:
>> > > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven
>> > w
On Fri, 08 Apr 2016 19:24:44 -, Brett Cannon wrote:
> On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote:
>
> > On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker
> > wrote:
> > > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven
> > wrote:
> > >>
> > >> >
> > >> > __pathstr__ # pathstring
> > >> >
On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote:
> On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker
> wrote:
> > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven
> wrote:
> >>
> >> >
> >> > __pathstr__ # pathstring
> >> >
> >>
> >> Or perhaps __pathstring__ in case it may be or return byte strings
On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker wrote:
> On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven wrote:
>>
>> >
>> > __pathstr__ # pathstring
>> >
>>
>> Or perhaps __pathstring__ in case it may be or return byte strings.
>
>
> I'm fine with __pathstring__ , but I thought it was already deci
On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven wrote:
> >
> > __pathstr__ # pathstring
> >
>
> Or perhaps __pathstring__ in case it may be or return byte strings.
>
I'm fine with __pathstring__ , but I thought it was already decided that it
would NOT return a bytestring!
-CHB
--
Christoph
On Fri, Apr 8, 2016 at 9:20 PM, Chris Barker wrote:
>
> we rejected plain old __path__ because this is already ued in another
> context, but if we add "str" on the end, that's not longer an issue, so do
> we need the "fs"?
>
> __pathstr__ # pathstring
>
Or perhaps __pathstring__ in case it may be
On Fri, 8 Apr 2016 at 11:13 Ethan Furman wrote:
> On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
> > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
> >> On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
>
> >>> I'm still thinking a little bit about 'pathname', which to me sounds
>
On Fri, Apr 8, 2016 at 11:13 AM, Ethan Furman wrote:
> So the plausible choices are, I think:
>
> - __fspath__ # File System Path -- possible confusion with Path
>
> - __fsstr__ # File System String
I think we really need "path" in there somewhere
>
> - __fspathstr__ # File System Path
On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
> On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
>> On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
>>> I'm still thinking a little bit about 'pathname', which to me sounds
>>> more like a string than fspath does.
>>
>>
>> I like that a
34 matches
Mail list logo
