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
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 first function, at
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
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 disagree.
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
@param
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 to a file or
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; students
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
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 it's
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
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 would
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 names
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 lines, is
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 saving
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
or withdraw
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, then (which I
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 multiple arguments.
? A saving
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
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
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. Forget using '+' for
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 path,
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
who
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
more clueless
[__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::
[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 been
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 literals like that?) and the
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
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 which, as
(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 didn't
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
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 to think
[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 to
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 like
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
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).
def
Ron Adam wrote:
In all current cases, (that I know of), of differing types, '+' raises
an error.
Not quite:
hello + uworld
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
--
Michael Hoffman wrote:
Ron Adam wrote:
In all current cases, (that I know of), of differing types, '+' raises
an error.
Not quite:
hello + uworld
u'hello world'
4.5 + 5
9.5
Question: Is a path object mutable?
No.
This should answer the rest of your questions.
Yes
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 + uworld
u'hello world'
4.5 + 5
9.5
In the case of numeric types, it's an addition and not a join. I should
have specified
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 + uworld
u'hello world'
4.5 + 5
9.5
In the case of numeric types, it's an addition and not a join. I
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 '/'.
I've used the path
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 long as we are
[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.
|
| The issue
[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
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, the + is
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 this
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
--
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
--
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:
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 alternatives? As
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 used in
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 anyone here claimed
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 extensively
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
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 the module
(but
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 class. Or export PathBase
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?
Why
[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 encoded with some
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
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, one can use
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
exactly what it's
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
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.
--
Michael
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 Path, but
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__()
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
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, join,
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 basestring
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 definitely
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 imagine a
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 expressive solution,
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
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 == -:
# Can use
[...]
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
Hi,
the arguments in the previous thread were convincing enough, so I made the
Path class inherit from str/unicode again.
It still can be found in CVS:
/python/nondist/sandbox/path/{path.py,test_path.py}
One thing is still different, though: a Path instance won't compare to a regular
string.
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?
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('/usr/bin')
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 those
or
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 you need
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 much
as with
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 entirely?
All
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, but I have
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
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?) operating
83 matches
Mail list logo
