Ron Adam wrote:
> PS. Could someone repost the links to the current pre-pep and the most
> recent module version so I can look at it closer look?
Pre-pre-PEP: http://wiki.python.org/moin/PathClass
Reinhold's version of the module is in Python CVS in
nondist/sandbox/path. Jason Orendorff's vers
Ivan Van Laningham wrote:
>>People can subclass Path and add it if they really want it. They can use
>>Jason's original module. My position is that the PEP without this use of
>>__div__ is (a) better as a standard module, and (b) improves the chance of
>>the PEP being accepted.
>>
>
>
> I dis
Delaney, Timothy (Tim) wrote:
> Hey - paths are special enough to warrant additional syntax, aren't they?
I hope this is a joke :)
--
Michael Hoffman
--
http://mail.python.org/mailman/listinfo/python-list
phil hunt wrote:
> On Sun, 31 Jul 2005 09:48:45 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
> wrote:
>>>
>>> An improvement to what? To how the class is implemented, or to how
>>> it is used?
>>
>>No, the second function is cleaner and more readable than the first,
>>IMHO.
>
> True, but the
On Sun, 31 Jul 2005 09:48:45 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
wrote:
>>
>> An improvement to what? To how the class is implemented, or to how
>> it is used?
>
>No, the second function is cleaner and more readable than the first,
>IMHO.
True, but the first function, at all of seven
I have to say, the examples of using / don't really suggest path
concatenation to me.
However, I think the problem is the use of whitespace. Specifically::
path = Path()
subdir = "subdir"
f = "filname"
path = path / subdir / f
looks more like division (even with the obvious name
> Above all, nobody can tell me that there's any programmer who
> doesn't instantly recognize '/' as a directory separator.
There is a programmer who doesn't instantly recognise '/' as a directory
separator.
I teach programming. The above is true. I think that the statement "any
programmer wou
> While people are loathe to admit it, many stereotypes have
> some basis in fact. The problem is when people extend that to generalize
> about others (especially in a negative way).
The intent was to use the basis-in-fact stereotype without having to explain
in detail the factual basis, which
>> I agree. It's yuck.
>
> So don't use it.
If it were that simple, I wouldn't have bothered bringing it up. I really
do believe this is a case of "There should be one-- and preferably only one
--obvious way to do it" (as well as "Explicit is better than implicit" and
"Readability counts").
If
> Is classic Macintosh OS still supported on Python?
No. At least, AFAIK, there is no intent to produce packages of new Python
versions for Mac pre OS X. Old versions of Python still work, of course,
but whatever version of Path makes it into Python (if any) is extremely
unlikely to be supported
> Yes, I read and understood it. Saying "Don't read this if
> you don't want to be offended" doesn't make an offensive
> statement inoffensive.
No, but it makes complaining that it was offensive pointless.
> I grant that Python is much easier to learn than other
> programming languages; stude
phil hunt wrote:
> On Sat, 30 Jul 2005 19:01:49 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
> wrote:
>>phil hunt wrote:
>>
>>> def normalizePath(p, *pathParts):
>>>""" Normalize a file path, by expanding the user name and getting
>>>the absolute path..
>>>@param p [string] = a path
On Sat, 30 Jul 2005 19:01:49 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
wrote:
>phil hunt wrote:
>
>> def normalizePath(p, *pathParts):
>>""" Normalize a file path, by expanding the user name and getting
>>the absolute path..
>>@param p [string] = a path to a file or directory
>>
On Sat, 2005-07-30 at 08:01 -0600, Ivan Van Laningham wrote:
> Tony Meyer wrote:
> >
> > >> (Those who are offended by sweeping generalisations should
> > >> ignore this next bit)
> > [...generalisation bit snipped...]
> > > This is not only bullshit, it's elitist bullshit. "Windows users are
> >
Steven D'Aprano wrote:
> On Sat, 30 Jul 2005 14:10:52 +0200, Reinhold Birkenfeld wrote:
>
>> Above all, nobody can tell me that there's any programmer who doesn't
>> instantly recognize '/' as a directory separator.
>
> Is classic Macintosh OS still supported on Python? Because Mac programmers
>
phil hunt wrote:
> def normalizePath(p, *pathParts):
>""" Normalize a file path, by expanding the user name and getting
>the absolute path..
>@param p [string] = a path to a file or directory
>@param pathParts [list of string] = optional path parts
>@return [string] = the same
phil hunt wrote:
> On Fri, 29 Jul 2005 14:38:23 +1200, Tony Meyer <[EMAIL PROTECTED]> wrote:
>>> def functions_which_modifies_some_file_in_place(path):
>>> output = open(path+'.tmp', 'w')
>>> .
>>>
>>> I dont want a seperator inserted between path and the new extension.
>>
>>Fair enough. Fo
Ivan Van Laningham wrote:
> I like / as a shortcut to joinwith(). I like it a lot. I like it so
> much I'll give you a +2.
+1 here. Extremely practical.
--
Brian Beck
Adventurer of the First Order
--
http://mail.python.org/mailman/listinfo/python-list
On Sat, 30 Jul 2005 14:10:52 +0200, Reinhold Birkenfeld wrote:
> Above all, nobody can tell me that there's any programmer who doesn't
> instantly recognize '/' as a directory separator.
Is classic Macintosh OS still supported on Python? Because Mac programmers
who haven't made the jump to OS X
On Fri, 29 Jul 2005 14:48:55 +1200, Tony Meyer <[EMAIL PROTECTED]> wrote:
>
>Would you really choose this:
>
>p = Path() / "build" / "a" / "very" / "very" / "long" / "path"
>
>Over this:
>
>p = Path(os.path.join("build", "a", "very", "very", "long", "path"))
Or have the constructor accept
On Fri, 29 Jul 2005 14:38:23 +1200, Tony Meyer <[EMAIL PROTECTED]> wrote:
>> def functions_which_modifies_some_file_in_place(path):
>> output = open(path+'.tmp', 'w')
>> .
>>
>> I dont want a seperator inserted between path and the new extension.
>
>Fair enough. Forget using '+' for join, t
Hi All--
Tony Meyer wrote:
>
> >> (Those who are offended by sweeping generalisations should
> >> ignore this next bit)
> [...generalisation bit snipped...]
> > This is not only bullshit, it's elitist bullshit. "Windows users are
> > more clueless than users of posix systems." Pfui. Prove it
>
Ivan Van Laningham wrote:
> Hi All--
>
> Tony Meyer wrote:
>>
>> So far, there have been various statements that look like +0 for __div__,
>> but no-one with a +1. (And I've said this a couple of times now, which
>> really is just trolling for a +1 from someone).
>>
>> > It's not a question of
>> (Those who are offended by sweeping generalisations should
>> ignore this next bit)
[...generalisation bit snipped...]
> This is not only bullshit, it's elitist bullshit. "Windows users are
> more clueless than users of posix systems." Pfui. Prove it
> or withdraw it.
Sigh. I guess you di
Hi All--
Tony Meyer wrote:
>
> So far, there have been various statements that look like +0 for __div__,
> but no-one with a +1. (And I've said this a couple of times now, which
> really is just trolling for a +1 from someone).
>
> > It's not a question of saving characters, but readability whi
> We're talking at this point about how Path should work, not
> whether it's preferable to os.path.join, even though that was
> really the point of Reinhard's original post.
That's not what I'm talking about. I'm talking about whether __div__ should
be a shortcut to joinwith, or whether users sh
Tony Meyer wrote:
> Would you really choose this:
> p = Path() / "build" / "a" / "very" / "very" / "long" / "path"
>
> Over this:
> p = Path(os.path.join("build", "a", "very", "very", "long", "path"))
I'd choose neither, because both are contrived examples (who builds
paths out of six li
[Tony Meyer]
|
| [Tim Golden]
| > Well, I actually had some correspondence with Jason on this
| > very subject a year or so ago:
| [...]
| > Obviously, I don't know how much weight Jason's original
| > ideas have on the prepped-for-syslib module, but it does
| > support what other people have
[__div__ for .joinpath()]
on 29.07.2005 04:48 Tony Meyer said the following:
>>I, herewith, claim to have used it in the past.
>>But I am indifferent as to if its needed, it just looks natural to me.
>
> So far there seem to have been a few +0s, but no +1s...
>
>>What I use quite often is::
>>
>
> Well, I actually had some correspondence with Jason on this
> very subject a year or so ago:
[...]
> Obviously, I don't know how much weight Jason's original
> ideas have on the prepped-for-syslib module, but it does
> support what other people have been saying: that the Path
> should behave
[using __div__ to mean join]
> I'm not too happy with it, too, but do we have alternatives?
> As paths are strings, we can hardly override the '+' operator,
> so there's not much operators left.
>
> Of course, one can use joinwith() if he doesn't like '/'.
My argument is that the alternative is
> I, herewith, claim to have used it in the past.
>
> But I am indifferent as to if its needed, it just looks natural to me.
So far there seem to have been a few +0s, but no +1s...
> What I use quite often is::
>
>path(__file__).dirname() / "somesiblingfileiknowisthere"
>
> you do not have
> def functions_which_modifies_some_file_in_place(path):
> output = open(path+'.tmp', 'w')
> .
>
> I dont want a seperator inserted between path and the new extension.
Fair enough. Forget using '+' for join, then (which I was never that keen
on - TIOWTDI), but I'm still -1 on using '/' for
Peter Hansen wrote:
> Ron Adam wrote:
>
>> Michael Hoffman wrote:
>>
>>> Ron Adam wrote:
>>>
In all current cases, (that I know of), of differing types, '+'
raises an error.
>>>
>>>
>>> Not quite:
>>> >>> "hello " + u"world"
>>> u'hello world'
>>> >>> 4.5 + 5
>>> 9.5
>>>
>> In the cas
Ron Adam wrote:
> Michael Hoffman wrote:
>> Ron Adam wrote:
>>> In all current cases, (that I know of), of differing types, '+'
>>> raises an error.
>>
>> Not quite:
>> >>> "hello " + u"world"
>> u'hello world'
>> >>> 4.5 + 5
>> 9.5
>>
> In the case of numeric types, it's an addition and not a j
Michael Hoffman wrote:
> Ron Adam wrote:
>
>> In all current cases, (that I know of), of differing types, '+' raises
>> an error.
>
>
> Not quite:
>
> >>> "hello " + u"world"
> u'hello world'
> >>> 4.5 + 5
> 9.5
>
>> Question: Is a path object mutable?
>
>
> No.
>
> This should answer t
Ron Adam wrote:
> In all current cases, (that I know of), of differing types, '+' raises
> an error.
Not quite:
>>> "hello " + u"world"
u'hello world'
>>> 4.5 + 5
9.5
> Question: Is a path object mutable?
No.
This should answer the rest of your questions.
--
Michael Hoffman
--
http://ma
Toby Dickenson wrote:
> On Wednesday 27 July 2005 05:37, Meyer, Tony wrote:
>
>
>>I can see that this would make sense in some situations, but ISTM that it
>>would make a great deal more sense (and be much more intuitive) to have
>>concatenation include the separator character (i.e. be join).
>
On Wednesday 27 July 2005 05:37, Meyer, Tony wrote:
> I can see that this would make sense in some situations, but ISTM that it
> would make a great deal more sense (and be much more intuitive) to have
> concatenation include the separator character (i.e. be join).
def functions_which_modifies_
>>> Do people really like using __div__ to mean join?
>>
>> I think the '+' is used as a join for both strings and lists, so it
>> would probably be the better choice as far as consistency with the
>> language is concerned.
>
> The issue with that is that as long as we are subclassing
> strings
[using __div__ to mean join]
> I think the '+' is used as a join for both strings
> and lists, so it would probably be the better choice
> as far as consistency with the language is concerned.
+1.
=Tony.Meyer
--
http://mail.python.org/mailman/listinfo/python-list
[Peter Hansen]
|
| Ron Adam wrote:
| Tony Meyer wrote:
| > Do people really like using __div__ to mean join?
|
| > I think the '+' is used as a join for both strings and lists, so it
| > would probably be the better choice as far as consistency with the
| > language is concerned.
|
Ron Adam wrote:
Tony Meyer wrote:
> Do people really like using __div__ to mean join?
> I think the '+' is used as a join for both strings and lists, so it
> would probably be the better choice as far as consistency with the
> language is concerned.
The issue with that is that as lon
Peter Hansen wrote:
> Michael Hoffman wrote:
>
>> Reinhold Birkenfeld wrote:
>>
>>> Tony Meyer wrote:
>>>
Do people really like using __div__ to mean join?
>>>
>>>
>>> I'm not too happy with it, too, but do we have alternatives? ...
>>> Of course, one can use joinwith() if he doesn't like '
Bengt Richter wrote:
> BTW, more OT, wouldn't '|' be more platform-neutral as the joining operator?
I, on the other hand, would certainly prefer U+01C1.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, 25 Jul 2005 17:33:51 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
wrote:
>Peter Hansen wrote:
>> Reinhold Birkenfeld wrote:
>>> Current change:
>>>
>>> * Add base() method for converting to str/unicode.
>>
>> Would basestring() be a better name? Partly because that seems to be
>> ex
On Mon, 25 Jul 2005 11:19:25 -0400, Peter Hansen <[EMAIL PROTECTED]> wrote:
>Michael Hoffman wrote:
>> Reinhold Birkenfeld wrote:
>>> Tony Meyer wrote:
Do people really like using __div__ to mean join?
>>>
>>> I'm not too happy with it, too, but do we have alternatives? ...
>>> Of course, o
> Reinhold Birkenfeld wrote:
>> Current change:
>>
>> * Add base() method for converting to str/unicode.
Now that [:] slicing works, and returns a string,
another way to convert from path.Path to str/unicode
is path[:]
Andrew
[EMAIL
[EMAIL PROTECTED] wrote:
> Reinhold> Right, that was a concern of mine, too.
> Reinhold> "tobase"?
> Reinhold> "tostring"?
> Reinhold> "tobasestring"?
>
> If we're on a filesystem that understands unicode, would somepath.tostring()
> return a unicode object or a string object encod
Reinhold> Right, that was a concern of mine, too.
Reinhold> "tobase"?
Reinhold> "tostring"?
Reinhold> "tobasestring"?
If we're on a filesystem that understands unicode, would somepath.tostring()
return a unicode object or a string object encoded with some
to-be-determined encoding
Peter Hansen wrote:
> Reinhold Birkenfeld wrote:
> > Peter Hansen wrote:
> >> Would basestring() be a better name?
>
> > "tobase"?
> > "tostring"?
> > "tobasestring"?
>
> Of these choices, the latter would be preferable.
>
> > Alternative is to set a class attribute "Base" of the
> > Path
Reinhold Birkenfeld wrote:
> Peter Hansen wrote:
>> Would basestring() be a better name?
> "tobase"?
> "tostring"?
> "tobasestring"?
Of these choices, the latter would be preferable.
> Alternative is to set a class attribute "Base" of the
> Path class. Or export PathBase as a name from th
Peter Hansen wrote:
> Reinhold Birkenfeld wrote:
>> Current change:
>>
>> * Add base() method for converting to str/unicode.
>
> Would basestring() be a better name? Partly because that seems to be
> exactly what it's doing, but more because there are (or used to be?)
> other things in Path th
Reinhold Birkenfeld wrote:
> Current change:
>
> * Add base() method for converting to str/unicode.
Would basestring() be a better name? Partly because that seems to be
exactly what it's doing, but more because there are (or used to be?)
other things in Path that used the word "base", such as
Michael Hoffman wrote:
> Reinhold Birkenfeld wrote:
>> Tony Meyer wrote:
>>> Do people really like using __div__ to mean join?
>>
>> I'm not too happy with it, too, but do we have alternatives? ...
>> Of course, one can use joinwith() if he doesn't like '/'.
>
> I've used the path module pretty
Stefan Rank wrote:
> on 25.07.2005 10:44 Michael Hoffman said the following:
>> Reinhold Birkenfeld wrote:
>>>Tony Meyer wrote:
Do people really like using __div__ to mean join?
>>>Of course, one can use joinwith() if he doesn't like '/'.
>> Personally, I'm -0 on __div__, but I suppose if anyon
on 25.07.2005 10:44 Michael Hoffman said the following:
> Reinhold Birkenfeld wrote:
>>Tony Meyer wrote:
>>>Do people really like using __div__ to mean join?
>>Of course, one can use joinwith() if he doesn't like '/'.
> Personally, I'm -0 on __div__, but I suppose if anyone here claimed to
> have
Reinhold Birkenfeld wrote:
> Tony Meyer wrote:
>>Do people really like using __div__ to mean join? On the python-dev
>>discussion, Just van Rossum spoke out against it, but there weren't (IIRC)
>>any other comments, either pro or con.
>
> I'm not too happy with it, too, but do we have alternativ
Reinhold Birkenfeld wrote:
> * Add base() method for converting to str/unicode.
+1
--
Michael Hoffman
--
http://mail.python.org/mailman/listinfo/python-list
Reinhold Birkenfeld wrote:
> Hi,
>
> the arguments in the previous thread were convincing enough, so I made the
> Path class inherit from str/unicode again.
Current change:
* Add base() method for converting to str/unicode.
* Allow compare against normal strings.
Reinhold
--
http://mail.python
Andrew Dalke wrote:
> Reinhold Birkenfeld wrote:
>> Okay. While a path has its clear use cases and those don't need above
>> methods,
>> it may be that some brain-dead functions needs them.
>
> "brain-dead"?
>
> Consider this code, which I think is not atypical.
Okay, convinced.
Reinhold
--
h
Tony Meyer wrote:
> [...]
>> Open issues:
> [...]
>> What about path * 4?
>
> If you keep the current join meaning of __div__, then assigning any sort of
> multiplication meaning to __mul__ would not be a good idea, IMO. It's
> natural to expect that __div__ and __mul__ are opposites. I suppose
[...]
> Open issues:
[...]
> What about path * 4?
If you keep the current join meaning of __div__, then assigning any sort of
multiplication meaning to __mul__ would not be a good idea, IMO. It's
natural to expect that __div__ and __mul__ are opposites. I suppose this
means that you could make _
Reinhold Birkenfeld wrote:
> Okay. While a path has its clear use cases and those don't need above methods,
> it may be that some brain-dead functions needs them.
"brain-dead"?
Consider this code, which I think is not atypical.
import sys
def _read_file(filename):
if filename == "-":
# Ca
Reinhold Birkenfeld wrote:
> I'm in no way the last instance on this.
> For example, everyone with CVS access is free to change the files ;)
I don't have CVS write access :(, so I'll have to keep kibitzing for now.
> Honestly, I'm in constant fear that allowing too much and loading too much
> fe
Peter Hansen wrote:
> Reinhold Birkenfeld wrote:
>> Peter Hansen wrote:
>>> if mypath.splitpath()[0] == 'c:/temp':
>
> vs.
>
>>> if mypath.splitpath()[0] == Path('c:/temp'):
>>
>> But you must admit that that't the cleaner solution.
>
> "Cleaner"? Not at all. I'd say it's the more express
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> On Sat, 23 Jul 2005 17:51:31 -0600, John Roth wrote:
>
>> I also like to know the number of elements, which seems to make
>> sense as len(path). Again, the number of characters in the path seems
>> to be utterly useless information - at least, I can't
Reinhold Birkenfeld wrote:
> Peter Hansen wrote:
>> if mypath.splitpath()[0] == 'c:/temp':
vs.
>> if mypath.splitpath()[0] == Path('c:/temp'):
>
> But you must admit that that't the cleaner solution.
"Cleaner"? Not at all. I'd say it's the more expressive solution,
perhaps, but I definit
Michael Hoffman wrote:
> Reinhold Birkenfeld wrote:
>
>> * __iter__() iterates over the parts().
>> * the following methods raise NotImplemented:
>> capitalize, expandtabs, join, splitlines, title, zfill
>
> Why? They *are* implemented. I do not understand this desire to wantonly
> break bases
Hi All--
Reinhold Birkenfeld wrote:
>
> Reinhold Birkenfeld wrote:
> > Hi,
> >
> > the arguments in the previous thread were convincing enough, so I made the
> > Path class inherit from str/unicode again.
>
Thanks.
> * the following methods raise NotImplemented:
> capitalize, expandtabs, joi
Reinhold Birkenfeld wrote:
> * __iter__() iterates over the parts().
> * the following methods raise NotImplemented:
> capitalize, expandtabs, join, splitlines, title, zfill
Why? They *are* implemented. I do not understand this desire to wantonly
break basestring compatiblity for the sake of b
Reinhold Birkenfeld wrote:
> Hi,
>
> the arguments in the previous thread were convincing enough, so I made the
> Path class inherit from str/unicode again.
Further changes by now:
* subdirs() is now dirs().
* fixed compare behaviour for unicode base (unicode has no rich compare)
* __iter__() it
Peter Hansen wrote:
> Reinhold Birkenfeld wrote:
> [on comparing Paths and stings]
>> Do you have a use case for the comparison? Paths should be compared only
>> with other paths.
>
> I can think of lots, though I don't know that I've used any in my
> existing (somewhat limited) code that uses Pa
Peter Hansen wrote:
> Point taken. What about ditching the "file" part, since it is redundant
> and obvious that a file is in fact what is being accessed. Thus:
> .read_bytes(), .read_text(), .write_lines() etc.
+1. Although I've always been somewhat -0 on these methods to start with.
--
Mic
On Sat, 23 Jul 2005 17:51:31 -0600, John Roth wrote:
> I also like to know the number of elements, which seems to make
> sense as len(path). Again, the number of characters in the path seems
> to be utterly useless information - at least, I can't imagine a use for
> it.
There are (were?) operatin
Reinhold Birkenfeld wrote:
[on comparing Paths and stings]
> Do you have a use case for the comparison? Paths should be compared only
> with other paths.
I can think of lots, though I don't know that I've used any in my
existing (somewhat limited) code that uses Path, but they all involve
cases
"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> I'll look into it. What about iteration and indexing? Should it support
> "for element in path" or "for char in path" or nothing?
I frankly can't think of a use for iterating over the characters in
the path, b
Peter Hansen wrote:
> Reinhold Birkenfeld wrote:
>> Peter Hansen wrote (on Paths not allowing comparison with strings):
>>>Could you please expand on what this means? Are you referring to doing
>>>< and >= type operations on Paths and strings, or == and != or all those
>>>or something else entir
Peter Hansen <[EMAIL PROTECTED]> writes:
>> * staticmethod Path.getcwd() -> Path.cwd()
>> * bytes() / lines() / text() -> read_file_{bytes,lines,text} methods
>> * write_{bytes,lines,text} -> write_file_{bytes,lines,text} methods
> Under Linux isn't it possible to open and read from directories mu
Reinhold Birkenfeld wrote:
> Peter Hansen wrote (on Paths not allowing comparison with strings):
>>Could you please expand on what this means? Are you referring to doing
>>< and >= type operations on Paths and strings, or == and != or all those
>>or something else entirely?
>
> All of these. Do
Peter Hansen wrote:
> Reinhold Birkenfeld wrote:
>> One thing is still different, though: a Path instance won't compare to a
>> regular
>> string.
>
> Could you please expand on what this means? Are you referring to doing
> < and >= type operations on Paths and strings, or == and != or all thos
Peter Hansen wrote:
> Under Linux isn't it possible to open and read from directories much as
> with files?
Not really, no.
Python 2.3.4 (#2, Jan 5 2005, 08:24:51)
[GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> d = open('/us
Reinhold Birkenfeld wrote:
> One thing is still different, though: a Path instance won't compare to a
> regular
> string.
Could you please expand on what this means? Are you referring to doing
< and >= type operations on Paths and strings, or == and != or all those
or something else entirely?
83 matches
Mail list logo
