Reinhold Birkenfeld wrote:
> 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 Pa
Personally, I *like* the current distinction between + as a regular
string join, which gives the already much discussed benefit of allowing
paths to be dropped in seamlessly and painlessly anywhere strings are
currently used, and then having in addition the / operator for
"concatenate with a path s
[Re: alternatives to overloading '/']
Is there a reason the Path constructor is limited to a single argument?
If it allowed multiple arguments, the following would seem very
straightforward:
p = Path(somePath, user.getFolder(), 'archive', oldPath + ".bak")
I'm usually not much of a purist, but C
[Re: how to get at the base class]
Do you really want to have a "only works for Path" way to get at the
base class, rather than using the canonical Path.__bases__[0]?
How about a new property in the os.path module instead? Something like
os.path.path_type.
Then os.path.path_type is unicode if an
NickC wrote:
> I'm usually not much of a purist, but C++ has convinced me that
> overloading an operator to mean something entirely unrelated to its
> mathematical meaning can be very unwise.
Me too. In general. I've yet to overload a single operator that way in
years of writing Python code, th
NickC wrote:
> [Re: alternatives to overloading '/']
>
> Is there a reason the Path constructor is limited to a single argument?
> If it allowed multiple arguments, the following would seem very
> straightforward:
>
> p = Path(somePath, user.getFolder(), 'archive', oldPath + ".bak")
That's a qui
NickC wrote:
> [Re: how to get at the base class]
>
> Do you really want to have a "only works for Path" way to get at the
> base class, rather than using the canonical Path.__bases__[0]?
>
> How about a new property in the os.path module instead? Something like
> os.path.path_type.
>
> Then os.
Reinhold Birkenfeld wrote:
> It's much the same as with @ decorators. Those who have used them much
> don't object to the syntax any more.
I do and I still think they are ugly.
--
Michael Hoffman
--
http://mail.python.org/mailman/listinfo/python-list
Michael Hoffman wrote:
> Reinhold Birkenfeld wrote:
>
>> It's much the same as with @ decorators. Those who have used them much
>> don't object to the syntax any more.
>
> I do and I still think they are ugly.
Shouldn't have generalized that. Add "most of" where you like.
Reinhold
--
http://ma
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.
O
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('/us
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
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 <[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
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
"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
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?) operatin
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
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
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
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
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
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
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
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
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
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
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
[...]
> 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 _
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
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
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
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 alternativ
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
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
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
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
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:
> 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:
> > 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> 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
[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 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, o
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
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:
> 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 '
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]
|
| 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.
|
[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
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_
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).
>
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
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:
> 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
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
> 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
[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
> 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
[__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
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
> 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
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
>> (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
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
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
>
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
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 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. Fo
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
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
>
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
> >
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
>>
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
> 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
> 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
> 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 wou
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
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
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
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 dis
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
93 matches
Mail list logo
