> "Jason" == Jason Orendorff <[EMAIL PROTECTED]> writes:
Jason> You seem to think that because I said "operating systems",
Jason> I'm talking about kernel algorithms and such.
I can see how you'd get that impression, but it's not true. My reason
for mentioning OS-level filesystem was
On 1/28/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Please note that my point was entirely different from trying to decide
> whether to subclass strings.
Noted -- sorry I took you out of context there; that was careless.
> Jason> Filesystem paths are in fact strings on all operating
Steven Bethard wrote:
> My only fear with the / operator is that we'll end up with the same
> problems we have for using % in string formatting -- the order of
> operations might not be what users expect. Since join is conceptually
> an addition-like operator, I would expect:
>
> Path('home'
Stephen J. Turnbull:
> Jason> Filesystem paths are in fact strings on all operating
> Jason> systems I'm aware of.
>
> I have no idea what you could mean by that. The data structure used
> to represent a filesystem on all OS filesystems I've used is a graph
> of directories and files. A
Stephen J. Turnbull wrote:
> Jason> Filesystem paths are in fact strings on all operating
> Jason> systems I'm aware of.
>
> I have no idea what you could mean by that. The data structure used
> to represent a filesystem on all OS filesystems I've used is a graph
> of directories and file
> "Jason" == Jason Orendorff <[EMAIL PROTECTED]> writes:
Jason> I. Here's an example of the sort of thing you might say if
Jason> you did *not* think of paths as strings:
[...]
Jason> II. And here is the sort of thing you'd say if you thought
Jason> of paths *solely* as strin
On 1/27/06, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> On 1/25/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > I think it's logical to expect that
> > Path('home') / 'and/or'
> > points to a file named "and/or" in directory "home", not to a file
> > named "or" in directory "home/and".
[Jason Orendorff]
> Filesystem paths are in fact strings on all operating systems I'm
> aware of. And it's no accident or performance optimization. It's
> good design.
Isn't that simply because filesystems aren't object orientated? I
can't call methods of a path through the filesystem. There
On Fri, Jan 27, 2006 at 06:19:52PM -0500, Jason Orendorff wrote:
> To say "paths aren't strings" is all very well, and in a very abstract
> sense I almost agree--but you have to admit it sort of flies in the face
> of, you know, reality. Filesystem paths are in fact strings on all
> operating sys
It's controversial that Path subclasses str. Some people think it's
flat-out wrong. Even Bjorn argues that it's a practicality-vs-purity
tradeoff. But a strong argument can be made that Path *should* be a
string subclass, practicality be damned. Proof follows.
I. Here's an example of the sort
I think that everything that can be said aboud __div__() has already
been said. But this argument was really convincing:
[Tony Meyer]
> The vast majority of people (at least at the time) were either +0 or
> -0, not +1. +0's are not justification for including something.
There is no clear consens
On Wed, 2006-01-25 at 21:02 -0600, Ian Bicking wrote:
>ext = '.jpg'
>name = fields['name']
>image = Path('/images') / name + ext
Here's a good example of why I ultimately don't like __div__. The last
line seems quite non-obvious to me. It's actually jarring enough that I
have to sto
On Thu, 2006-01-26 at 11:40 +1000, Nick Coghlan wrote:
> The main appeal to me of the division operation is that it allows multiple
> path elements to be joined on a single line, but the joining method accepts
> an
> arbitrary number of arguments, which helps with that just as much, and
> does
> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes:
Steven> My only fear with the / operator is that we'll end up with
Steven> the same problems we have for using % in string formatting
Steven> -- the order of operations might not be what users expect.
Besides STeVe's example
On Thu, 2006-01-26 at 12:51 +1300, Tony Meyer wrote:
> [John J Lee]
> > But it's a very readable way to write a common operation. Perhaps one
> > reason the discrepancy you point out doesn't bother me is that
> > division is
> > the least-used of the +-*/ arithmetic operations.
>
> Do you have
Steven Bethard wrote:
> My only fear with the / operator is that we'll end up with the same
> problems we have for using % in string formatting -- the order of
> operations might not be what users expect. Since join is conceptually
> an addition-like operator, I would expect:
>
> Path('home')
[Nick Coghlan wrote]
> What if we used "subpath" as the name instead of joinpath?
"append"?
not-a-big-fan-of-joinpath-either-ly yours,
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
Steven Bethard wrote:
> John J Lee wrote:
>> On Thu, 26 Jan 2006, Tony Meyer wrote:
>> [...]
>>> Well, if you include the much larger discussion on python-list,
>>> people (including me) have said that removing __div__ is a good
>>> idea. If it's included in the PEP, please at least include a
>>>
John J Lee wrote:
> On Thu, 26 Jan 2006, Tony Meyer wrote:
> [...]
> > Well, if you include the much larger discussion on python-list,
> > people (including me) have said that removing __div__ is a good
> > idea. If it's included in the PEP, please at least include a
> > justification and cover th
[John J Lee]
> But it's a very readable way to write a common operation. Perhaps one
> reason the discrepancy you point out doesn't bother me is that
> division is the least-used of the +-*/ arithmetic operations.
[Tony Meyer]
>
> Do you have evidence to back that up?
No. :)
[Ian Bicking]
[John J Lee]
> But it's a very readable way to write a common operation. Perhaps one
> reason the discrepancy you point out doesn't bother me is that
> division is
> the least-used of the +-*/ arithmetic operations.
Do you have evidence to back that up? It seems a strange claim.
Outside of
On Thu, 26 Jan 2006, Tony Meyer wrote:
[...]
> Well, if you include the much larger discussion on python-list,
> people (including me) have said that removing __div__ is a good
> idea. If it's included in the PEP, please at least include a
> justification and cover the problems with it. The
22 matches
Mail list logo
