Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10529 > unrolled thread

PyWart: os.path needs immediate attention!

Back to article view | Back to comp.lang.python

Contents

  PyWart: os.path needs immediate attention! rantingrick <rantingrick@gmail.com> - 2011-07-29 10:22 -0700
    Re: PyWart: os.path needs immediate attention! Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-29 12:53 -0500
      Re: PyWart: os.path needs immediate attention! harrismh777 <harmar@member.fsf.org> - 2011-07-29 14:41 -0500
        Re: PyWart: os.path needs immediate attention! "Waldek M." <wm@localhost.localdomain> - 2011-07-29 21:55 +0200
      Re: PyWart: os.path needs immediate attention! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-30 10:50 +1000
        Function "modes" vs. separate functions (was: PyWart: os.path needs immediate attention!) Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-29 20:15 -0500
          Re: Function "modes" vs. separate functions Ben Finney <ben+python@benfinney.id.au> - 2011-07-30 11:57 +1000
            Re: Function "modes" vs. separate functions Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-29 21:28 -0500
        Re: PyWart: os.path needs immediate attention! Terry Reedy <tjreedy@udel.edu> - 2011-07-30 09:48 -0400
        Re: PyWart: os.path needs immediate attention! Robert Kern <robert.kern@gmail.com> - 2011-07-30 23:31 -0400
    Re: PyWart: os.path needs immediate attention! Teemu Likonen <tlikonen@iki.fi> - 2011-07-29 23:07 +0300
      Re: PyWart: os.path needs immediate attention! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-30 10:57 +1000
        Re: PyWart: os.path needs immediate attention! Teemu Likonen <tlikonen@iki.fi> - 2011-08-01 11:19 +0300
          Re: PyWart: os.path needs immediate attention! rantingrick <rantingrick@gmail.com> - 2011-08-02 09:03 -0700
            Re: PyWart: os.path needs immediate attention! Chris Angelico <rosuav@gmail.com> - 2011-08-02 17:36 +0100
    Re: PyWart: os.path needs immediate attention! Chris Angelico <rosuav@gmail.com> - 2011-07-30 06:25 +1000
    Re: PyWart: os.path needs immediate attention! Corey Richardson <kb1pkl@aim.com> - 2011-07-29 16:44 -0400
    Re: PyWart: os.path needs immediate attention! Alister Ware <alister.ware@ntlworld.com> - 2011-07-29 21:21 +0000
      Re: PyWart: os.path needs immediate attention! Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-29 16:36 -0500
    Re: PyWart: os.path needs immediate attention! Chris Angelico <rosuav@gmail.com> - 2011-07-30 07:43 +1000
    Re: PyWart: os.path needs immediate attention! Terry Reedy <tjreedy@udel.edu> - 2011-07-29 19:30 -0400
    Re: PyWart: os.path needs immediate attention! Michael Poeltl <michael.poeltl@univie.ac.at> - 2011-07-30 02:30 +0200
      Re: PyWart: os.path needs immediate attention! Grant Edwards <invalid@invalid.invalid> - 2011-07-30 15:33 +0000
        Re: PyWart: os.path needs immediate attention! Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-30 10:56 -0500
          Re: PyWart: os.path needs immediate attention! alex23 <wuwei23@gmail.com> - 2011-08-02 23:52 -0700
    Re: PyWart: os.path needs immediate attention! Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-07-29 22:17 -0700
    Re: PyWart: os.path needs immediate attention! Gelonida N <gelonida@gmail.com> - 2011-08-03 11:52 +0200

Page 1 of 2  [1] 2  Next page →

#10529 — PyWart: os.path needs immediate attention!

--------------------------------------------------
 Overview of Problems:
--------------------------------------------------

 * Too many methods exported.
 * Poor choice of method names.
 * Non public classes/methods exported!
 * Duplicated functionality.

--------------------------------------------------
 Proposed new functionality:
--------------------------------------------------

 * New path module will ONLY support one path sep! There is NO reason
to support more than one. When we support more than one path sep we
help to propagate multiplicity.We should only support the slash and
NOT the backslash across ALL OS's since the slash is more widely
accepted. If an OS does not have the capability to support only the
slash then that OS is not worthy of a Python builtin module. The users
of such OS will be responsible for managing their OWN os_legacy.path
module. We are moving forward. Those who wish to wallow in the past
will be left behind.

 * Introduce a new method named "partition" which (along with string
splitting methods) will replace the six methods "basename", "dirname",
"split", "splitdrive", "splitunc", "splittext". The method will return
a tuple of the path split into four parts: (drive, path, filename,
extension). This is the ONLY splitting method this module needs. All
other splits can use string methods.

--------------------------------------------------
 Expose of the Warts of current module:
--------------------------------------------------


~~~~~~~~~~~~~~~~~~~~~~~~~
 1. Too many methods
~~~~~~~~~~~~~~~~~~~~~~~~~

Follows is a list of what to keep and what to cull:

 + abspath
 + altsep
 - basename --> path.partition[-2]
 + commonprefix
 + curdir
 + defpath
 + devnull
 - dirname --> os.path.join(drive,path)
 + exists
 + expanduser
 + expandvars
 + extsep
 - genericpath --> should be private!
 + getatime
 + getctime
 + getmtime
 + getsize
 + isabs
 + isdir
 + isfile
 + islink
 + ismount
 + join
 - lexists --> duplicate!
 - normcase --> path = path.lower()
 - normpath --> should not need this!
 - os --> should be private!
 + pardir
 + pathsep
 + realpath
 + relpath
 + sep
 - split --> path.rsplit('/', 1)
 - splitdrive --> path.split(':', 1)
 - splitext --> path.rsplit('.')
 - splitunc --> Unix specific!
 - stat --> should be private!
 + supports_unicode_filenames --> windows specific!
 - sys --> should be private!
 + walk
 - warnings --> should be private!


~~~~~~~~~~~~~~~~~~~~~~~~~
 2. Poor Name Choices:
~~~~~~~~~~~~~~~~~~~~~~~~~

 * basename --> should be: filename
 * split --> split what?
 * splitext --> Wow, informative!

~~~~~~~~~~~~~~~~~~~~~~~~~
 3. Non Public Names Exposed!
~~~~~~~~~~~~~~~~~~~~~~~~~

 * genericpath
 * os
 * stat
 * sys
 * warnings


Note: i did not check the Unix version of os.path for this.

~~~~~~~~~~~~~~~~~~~~~~~~~
 4. Duplicated functionality.
~~~~~~~~~~~~~~~~~~~~~~~~~

>>> os.path.lexists.__doc__
'Test whether a path exists.  Returns False for broken symbolic links'
>>> os.path.exists.__doc__
'Test whether a path exists.  Returns False for broken symbolic links'

Should have been one method:
>>> os.path.exists(path, ignoreSymLnks=False)

[toc] | [next] | [standalone]

#10531

On 2011.07.29 12:22 PM, rantingrick wrote:
>  * New path module will ONLY support one path sep! There is NO reason
> to support more than one. When we support more than one path sep we
> help to propagate multiplicity.We should only support the slash and
> NOT the backslash across ALL OS's since the slash is more widely
> accepted. If an OS does not have the capability to support only the
> slash then that OS is not worthy of a Python builtin module. The users
> of such OS will be responsible for managing their OWN os_legacy.path
> module. We are moving forward. Those who wish to wallow in the past
> will be left behind.
So now you propose that not only does Python need drastic changes, but a
major operating system family as well (I know Windows will accept a
forward slash in some contexts, but I'd be pretty surprised if one could
completely replace the backslash with it completely)? Interesting.

>  * Introduce a new method named "partition" which (along with string
> splitting methods) will replace the six methods "basename", "dirname",
> "split", "splitdrive", "splitunc", "splittext". The method will return
> a tuple of the path split into four parts: (drive, path, filename,
> extension). This is the ONLY splitting method this module needs. All
> other splits can use string methods.
So these pretty specifically named functions (except perhaps split)
should be replaced with one ambiguously named one? Interesting.

>  - dirname --> os.path.join(drive,path)
Now you've stopped making sense completely. Also interesting.

>  * split --> split what?
> ...
>>>> os.path.exists(path, ignoreSymLnks=False)
I actually agree with you on these, which I suppose is interesting.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB

[toc] | [prev] | [next] | [standalone]

#10536

Andrew Berg wrote:
>   * New path module will ONLY support one path sep! There is NO reason
>>  to support more than one. When we support more than one path sep we
>>  help to propagate multiplicity.We should only support the slash and
>>  NOT the backslash across ALL OS's since the slash is more widely
>>  accepted. If an OS does not have the capability to support only the
>>  slash then that OS is not worthy of a Python builtin module. The users
>>  of such OS will be responsible for managing their OWN os_legacy.path
>>  module. We are moving forward. Those who wish to wallow in the past
>>  will be left behind.

I actually agree with this.  Like Timon once told Pumbaa, "Ya gotta put 
your behind in the past. . . "

The backslash sep is an asinine CPM/80 | DOS disk based carry-over which 
does not fit well with the modern forward direction. The disk based file 
system carry-over is bad enough; but, propagating multiple ways of doing 
simple things like specifying file-system paths is not helpful in any 
context.

The modern direction today (almost universally on the server-side) is to 
specify the path from the root "/" regardless of physical disk array 
geometries (or physical drives "C:\"). The forward slash actually makes 
some philosophical sense, and of course is more aesthetically pleasing.

So, let's put our behinds in the past and slash forward !





-- 
m harris

FSF  ...free as in freedom/
http://webpages.charter.net/harrismh777/gnulinux/gnulinux.htm

[toc] | [prev] | [next] | [standalone]

#10538

Dnia Fri, 29 Jul 2011 14:41:22 -0500, harrismh777 napisał(a):
> The backslash sep is an asinine CPM/80 | DOS disk based carry-over which 
> does not fit well with the modern forward direction. The disk based file 
> system carry-over is bad enough; but, propagating multiple ways of doing 
> simple things like specifying file-system paths is not helpful in any 
> context.

Please, do tell it to Microsoft. And once you've convinced them,
and they've implemented it, do report :-)

Waldek 

[toc] | [prev] | [next] | [standalone]

#10559

Andrew Berg wrote:

>>>>> os.path.exists(path, ignoreSymLnks=False)
> I actually agree with you on these, which I suppose is interesting.


Guido has a rule of thumb: "No constant arguments". Or another way to put
it: if a function takes an argument which is nearly always a constant
(usually, but not always, a flag) then it is usually better off as two
functions.

Especially if the implementation looks like this:

def get_thing(argument, flag):
    if flag:
        return one_thing(argument)
    else:
        return another_thing(argument)


Argument flags which do nothing but change the behaviour of the function
from Mode 1 to Mode 2 are an attractive nuisance: they seem like a good
idea, but aren't. Consider it a strong guideline rather than a law, but
it's one I would think very long and hard about before violating.

But having said that, I'm currently writing a library where nearly all the
functions violate the No Constant Argument rule. (The API isn't yet stable,
so I may still change my mind.) Make of that what you will.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#10562 — Function "modes" vs. separate functions (was: PyWart: os.path needs immediate attention!)

On 2011.07.29 07:50 PM, Steven D'Aprano wrote:
> Especially if the implementation looks like this:
> 
> def get_thing(argument, flag):
>     if flag:
>         return one_thing(argument)
>     else:
>         return another_thing(argument)
> 
Well, that would be annoying, but wouldn't it be even more annoying to
do this:
def get_one_thing(arg):
	return one_thing(arg)

def get_another_thing(arg):
	return another_thing(arg)

> Argument flags which do nothing but change the behaviour of the function
> from Mode 1 to Mode 2 are an attractive nuisance: they seem like a good
> idea, but aren't. Consider it a strong guideline rather than a law, but
> it's one I would think very long and hard about before violating.
Creating separate functions for two thing that do almost the same thing
seem more of a nuisance to me, especially if they share a lot of code
that isn't easily separated into other functions.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB

[toc] | [prev] | [next] | [standalone]

#10564 — Re: Function "modes" vs. separate functions

Andrew Berg <bahamutzero8825@gmail.com> writes:

> On 2011.07.29 07:50 PM, Steven D'Aprano wrote:
> > Especially if the implementation looks like this:
> > 
> > def get_thing(argument, flag):
> >     if flag:
> >         return one_thing(argument)
> >     else:
> >         return another_thing(argument)
> > 
> Well, that would be annoying, but wouldn't it be even more annoying to
> do this:
> def get_one_thing(arg):
> 	return one_thing(arg)
>
> def get_another_thing(arg):
> 	return another_thing(arg)

Yes, of course it would be; and even more pointless.

The right thing to do is to call ‘one_thing(argument)’ or
‘another_thing(argument)’ directly.

The greater point is that, since the flag simply switches between
different “things” to do, then that's better communicated in code by
calling differently-named functions that each do one thing.

> Creating separate functions for two thing that do almost the same
> thing seem more of a nuisance to me, especially if they share a lot of
> code that isn't easily separated into other functions.

If they share a lot of code, either it *is* separable to common
functions (in which case, implement it that way), or the “same thing”
code is sufficiently complex that it's better to show it explicitly.

But this is all getting rather generic and abstract. What specific
real-world examples do you have in mind?

-- 
 \          “It is clear that thought is not free if the profession of |
  `\           certain opinions makes it impossible to earn a living.” |
_o__)  —Bertrand Russell, _Free Thought and Official Propaganda_, 1928 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#10566 — Re: Function "modes" vs. separate functions

On 2011.07.29 08:57 PM, Ben Finney wrote:
> If they share a lot of code, either it *is* separable to common
> functions (in which case, implement it that way), or the “same thing”
> code is sufficiently complex that it's better to show it explicitly.
> 
> But this is all getting rather generic and abstract. What specific
> real-world examples do you have in mind?
I can't come up with any off the top of my head. I was thinking of a
general rule anyway; ultimately one decides (or at least should) how to
write code on a case-by-case basis.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB

[toc] | [prev] | [next] | [standalone]

#10581

On 7/29/2011 8:50 PM, Steven D'Aprano wrote:

> Guido has a rule of thumb: "No constant arguments". Or another way to put
> it: if a function takes an argument which is nearly always a constant
> (usually, but not always, a flag) then it is usually better off as two
> functions.

I do not really understand his 'rule'*. The stdlib has lots of functions 
with boolean flags and params which default to None and are seldom 
over-ridden.

* Which is to say, it feels more like his gut feeling applied on a 
case-by-case basis than an actual rule that anyone could apply in any 
objective manner.

> Especially if the implementation looks like this:
>
> def get_thing(argument, flag):
>      if flag:
>          return one_thing(argument)
>      else:
>          return another_thing(argument)

If the rule is limited to this situation, where no code is shared, it 
seems pretty sensible.

> Argument flags which do nothing but change the behaviour of the function
> from Mode 1 to Mode 2 are an attractive nuisance: they seem like a good
> idea, but aren't. Consider it a strong guideline rather than a law, but
> it's one I would think very long and hard about before violating.
>
> But having said that, I'm currently writing a library where nearly all the
> functions violate the No Constant Argument rule. (The API isn't yet stable,
> so I may still change my mind.) Make of that what you will.

See * above ;-).

Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#10612

On 7/29/11 8:50 PM, Steven D'Aprano wrote:
> Andrew Berg wrote:
>
>>>>>> os.path.exists(path, ignoreSymLnks=False)
>> I actually agree with you on these, which I suppose is interesting.
>
>
> Guido has a rule of thumb: "No constant arguments". Or another way to put
> it: if a function takes an argument which is nearly always a constant
> (usually, but not always, a flag) then it is usually better off as two
> functions.

That's not quite right (although I can never find a direct quote from Guido 
whenever I need to dissect the niceties of the rule). The rule of thumb is more 
like: "No literal arguments." That is, if you are typically going to use True 
and False literals for a flag, it's better to have two functions. However, if 
you have a suite of interoperating functions with the same flag argument, and 
one might reasonably want to pass the same flag value to several different calls 
using a variable, that's a reasonable use.

> But having said that, I'm currently writing a library where nearly all the
> functions violate the No Constant Argument rule. (The API isn't yet stable,
> so I may still change my mind.) Make of that what you will.

I suspect this may be an instance of the latter case.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [next] | [standalone]

#10539

* 2011-07-29T10:22:04-07:00 * <rantingrick@gmail.com> wrote:

>  * New path module will ONLY support one path sep! There is NO reason
> to support more than one.

Pathnames and the separator for pathname components should be abstracted
away, to a pathname object. This pathname object could have a "path" or
"directory" slot which is a list of directory components (strings). Then
there would be method like "to_namestring" which converts a pathname
object to native pathname string. It takes care of any platform-specific
stuff like pathname component separators. Of course "to_pathname" method
is needed too. It converts system's native pathname string to a pathname
object.

[toc] | [prev] | [next] | [standalone]

#10561

Teemu Likonen wrote:

> * 2011-07-29T10:22:04-07:00 * <rantingrick@gmail.com> wrote:
> 
>>  * New path module will ONLY support one path sep! There is NO reason
>> to support more than one.
> 
> Pathnames and the separator for pathname components should be abstracted
> away, to a pathname object.

Been there, done that, floundered on the inability of people to work out the
details.

http://www.python.org/dev/peps/pep-0355/



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#10652

* 2011-07-30T10:57:29+10:00 * Steven D'Aprano wrote:

> Teemu Likonen wrote:
>> Pathnames and the separator for pathname components should be
>> abstracted away, to a pathname object.
>
> Been there, done that, floundered on the inability of people to work
> out the details.
>
> http://www.python.org/dev/peps/pep-0355/

I'm very much a Lisp person and obviously got the idea of pathname
objects from Common Lisp. Lazily I'm also learning Python too but at the
moment I can't comment on the details of that PEP. Yet, generally I
think that's the way to improve pathnames, not the "rantinrick's".

[toc] | [prev] | [next] | [standalone]

#10743

On Aug 1, 3:19 am, Teemu Likonen <tliko...@iki.fi> wrote:
> * 2011-07-30T10:57:29+10:00 * Steven D'Aprano wrote:
>
> > Teemu Likonen wrote:
> >> Pathnames and the separator for pathname components should be
> >> abstracted away, to a pathname object.
>
> > Been there, done that, floundered on the inability of people to work
> > out the details.
>
> >http://www.python.org/dev/peps/pep-0355/
>
> I'm very much a Lisp person and obviously got the idea of pathname
> objects from Common Lisp. Lazily I'm also learning Python too but at the
> moment I can't comment on the details of that PEP. Yet, generally I
> think that's the way to improve pathnames, not the "rantinrick's".

This thread was intended to expose another PyWart and get the
community juices flowing. os.path is broken and cannot be repaired
because os.path was an improper API to begin with. The only way to
solve this problem is to introduce a new Path object.

A new Path object is the answer.

Some have said "been there, done that" with a sarcastic and defeatist
point of view. I say we need to re-visit the proposal of PEP-0355 and
hash out something quickly. We also need to realize that one day or
another this Path object is going to become reality and the longer we
drag our feet getting it implemented the more painful the transition
is going to be.

I feel Python community is in an awkward teenage stage at this point
not really sure of it's self or direction. Living only for today with
no ability to project the future and wasting too much time arguing
over minutiae. We need a collective wake-up-call in the form of a slap
on the face. We need to start making the hard choices necessary to
clean up this library.

Python3000 was only the beginning! ONLY THE BEGINNING!

[toc] | [prev] | [next] | [standalone]

#10746

On Tue, Aug 2, 2011 at 5:03 PM, rantingrick <rantingrick@gmail.com> wrote:
> This thread was intended to expose another PyWart and get the
> community juices flowing. os.path is broken and cannot be repaired
> because os.path was an improper API to begin with. The only way to
> solve this problem is to introduce a new Path object.
>
> A new Path object is the answer.

http://xkcd.com/927/

> I feel Python community is in an awkward teenage stage at this point
> not really sure of it's self or direction. Living only for today with
> no ability to project the future and wasting too much time arguing
> over minutiae. We need a collective wake-up-call in the form of a slap
> on the face. We need to start making the hard choices necessary to
> clean up this library.
>
> Python3000 was only the beginning! ONLY THE BEGINNING!

Some of us have reached the level of maturity necessary to understand
that stability is valuable. Also to notice when requirements
internally conflict - how are we going to develop the One Perfect API
without spending a lot of time arguing minutiae?

One thing I have learned in life is that mature products have their
warts for a reason, and that reason is usually compatibility. That's
not necessarily a good thing, but nor is it necessarily bad. For
instance, the Python source code is managed by automake. We could save
ourselves a LOT of trouble by simply moving to the future - a future
in which Linux is the only operating system we bother with, that
64-bit hardware and 64-bit OSes are everything, and so on. Why bother
supporting the past? But that "past" is actually a huge part of the
world today, too.

Large-scale adoption is an incredibly valuable thing, and you are
narrowing your adoption potential considerably if you do not support
these things. As an example, have you ever noticed how horribly
useless and skeletal the Python documentation is? Neither have I. It's
used by so many people that it gets eyeballs, and therefore time, to
fix up its failings. Compare with Pike, a much more obscure language
(syntactically similar to C, but under the covers quite similar to
Python); scroll down this list of constants from its Stdio module:

http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/Stdio.html

A good number of them simply say FIXME, and even those that _are_
documented have only brief explanations. For quite a few things, you
need to go direct to the language's source code. (Do a docs search for
FIXME and you'll find that this is not an isolated case.) That doesn't
happen with Python, largely a consequence (if somewhat indirectly) of
its being so widely used.

Sure you can make your life easier. But is it really better?

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#10542

On Sat, Jul 30, 2011 at 3:22 AM, rantingrick <rantingrick@gmail.com> wrote:
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>  3. Non Public Names Exposed!
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
>  * genericpath
>  * os
>  * stat
>  * sys
>  * warnings
>

And you intend to do what, exactly, with these?

>  - splitunc --> Unix specific!

1) So?
2) http://docs.python.org/library/os.path.html#os.path.splitunc says
"Availability: Windows."

If you actually meant "Windows specific" then the first one still holds.

Under Unix, the only place UNC names are supported is CIFS mounting
(and equivalents, smbmount etc).

ChrisA

[toc] | [prev] | [next] | [standalone]

#10546

[Multipart message — attachments visible in raw view] — view raw

Excerpts from rantingrick's message of Fri Jul 29 13:22:04 -0400 2011:
> --------------------------------------------------
>  Proposed new functionality:
> --------------------------------------------------
>
>  * New path module will ONLY support one path sep! There is NO
> reason to support more than one. When we support more than one path
> sep we help to propagate multiplicity.We should only support the
> slash and NOT the backslash across ALL OS's since the slash is more
> widely accepted. If an OS does not have the capability to support
> only the slash then that OS is not worthy of a Python builtin
> module. The users of such OS will be responsible for managing their
> OWN os_legacy.path module. We are moving forward. Those who wish to
> wallow in the past will be left behind.

People who use windows are used to \ being their pathsep. If you show
them a path that looks like C:/whatever/the/path in an app, they are
going to think you are nuts. It isn't up to us to decide what anyone
uses as a path separator. They use \ natively, so should we. If at
any point Windows as an OS starts using /'s, and not support, actually
uses (in Windows Explorer as default (or whatever the filebrowser's
name is)), it would be great to switch over.

> * Introduce a new method named "partition" which (along with string
> splitting methods) will replace the six methods "basename",
> "dirname", "split", "splitdrive", "splitunc", "splittext". The
> method will return a tuple of the path split into four parts:
> (drive, path, filename, extension). This is the ONLY splitting
> method this module needs. All other splits can use string methods.

I agree, although what if one wants to further split the returned
path, in an OS-independent way? Just because we want all pathseps
to be /, doesn't mean they are (and I personally don't care either
way).

> ~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Too many methods ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Follows is a list of what to keep and what to cull:
> 
>  + abspath
>  + altsep
>  - basename --> path.partition[-2]
>  + commonprefix
>  + curdir
>  + defpath
>  + devnull
>  - dirname --> os.path.join(drive,path)
>  + exists
>  + expanduser
>  + expandvars
>  + extsep
>  - genericpath --> should be private!
>  + getatime
>  + getctime
>  + getmtime
>  + getsize
>  + isabs
>  + isdir
>  + isfile
>  + islink
>  + ismount
>  + join
>  - lexists --> duplicate!
>  - normcase --> path = path.lower()

Not quite, here are a few implementations of normcase (pulled from 2.7)

# NT
def normcase(s):
    """Normalize case of pathname.                                                                                          
                                                                                                                            
    Makes all characters lowercase and all slashes into backslashes."""
    return s.replace("/", "\\").lower()

# Mac (Correct in this case)

def normcase(path):
    return path.lower()

# POSIX

def normcase(s):
    """Normalize case of pathname.  Has no effect under Posix"""
    return s


But I can't think of where I would ever use that. Isn't case important on
Windows? 

>  - normpath --> should not need this!

Why not? It provides an OS-independent way to make the pathname look pretty,
maybe for output? I don't really see a use for it, to be honest. But I'd 
rather there be a working solution in the stdlib than have everyone need to
throw in their own that might not handle some things properly. Talk about
multiplicity!

>  - os --> should be private!
>  + pardir
>  + pathsep
>  + realpath
>  + relpath
>  + sep
>  - split --> path.rsplit('/', 1)

And on those operating systems where "\\" is the pathsep?

>  - splitdrive --> path.split(':', 1)
>  - splitunc --> Unix specific!

Err...no. It's for UNC paths, as in  \\server\mount\foo\bar. It's not even
in posixpath.py, so in no way could it ever be Unix specific.

>  - stat --> should be private!
>  + supports_unicode_filenames --> windows specific!
>  - sys --> should be private!
>  + walk
>  - warnings --> should be private!
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>  2. Poor Name Choices:
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>  * basename --> should be: filename

I agree. The name is a carryover from basename(1) and I guess it's good for
those people, but it certainly isn't the least surprising name. If anything,
I would think the base is everything before!

>  * split --> split what?

The path, of course. On its own, it's uninformative, but considering
the whole name is "os.path.split", it's fairly intuitive.

>  * splitext --> Wow, informative!

split extension...seems straightforward to me.

> ~~~~~~~~~~~~~~~~~~~~~~~~~
>  4. Duplicated functionality.
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> >>> os.path.lexists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
> >>> os.path.exists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
> 
> Should have been one method:
> >>> os.path.exists(path, ignoreSymLnks=False)

It is.

/usr/lib64/python2.7/ntpath.py says..

> # alias exists to lexists                                                                                                   
> lexists	= exists

But over here in Not-NT where we actually *have* symlinks to be broken, it's

>>> os.path.lexists.__doc__
'Test whether a path exists.  Returns True for broken symbolic links'
>>> os.path.exists.__doc__
'Test whether a path exists.  Returns False for broken symbolic links

I agree that it should be an argument to os.path.exists, though.
-- 
Corey Richardson
  "Those who deny freedom to others, deserve it not for themselves"
     -- Abraham Lincoln

[toc] | [prev] | [next] | [standalone]

#10549

On Fri, 29 Jul 2011 10:22:04 -0700, rantingrick wrote:

> --------------------------------------------------
>  Overview of Problems:
> --------------------------------------------------
> 
>  * Too many methods exported.
>  * Poor choice of method names.
>  * Non public classes/methods exported!
>  * Duplicated functionality.
> 
> --------------------------------------------------
>  Proposed new functionality:
> --------------------------------------------------
> 
>  * New path module will ONLY support one path sep! There is NO reason
> to support more than one. When we support more than one path sep we help
> to propagate multiplicity.We should only support the slash and NOT the
> backslash across ALL OS's since the slash is more widely accepted. If an
> OS does not have the capability to support only the slash then that OS
> is not worthy of a Python builtin module. The users of such OS will be
> responsible for managing their OWN os_legacy.path module. We are moving
> forward. Those who wish to wallow in the past will be left behind.
> 
>  * Introduce a new method named "partition" which (along with string
> splitting methods) will replace the six methods "basename", "dirname",
> "split", "splitdrive", "splitunc", "splittext". The method will return a
> tuple of the path split into four parts: (drive, path, filename,
> extension). This is the ONLY splitting method this module needs. All
> other splits can use string methods.
> 
> --------------------------------------------------
>  Expose of the Warts of current module:
> --------------------------------------------------
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>  1. Too many methods
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Follows is a list of what to keep and what to cull:
> 
>  + abspath + altsep - basename --> path.partition[-2]
>  + commonprefix + curdir + defpath + devnull - dirname -->
>  os.path.join(drive,path)
>  + exists + expanduser + expandvars + extsep - genericpath --> should be
>  private!
>  + getatime + getctime + getmtime + getsize + isabs + isdir + isfile +
>  islink + ismount + join - lexists --> duplicate!
>  - normcase --> path = path.lower()
>  - normpath --> should not need this!
>  - os --> should be private!
>  + pardir + pathsep + realpath + relpath + sep - split -->
>  path.rsplit('/', 1)
>  - splitdrive --> path.split(':', 1)
>  - splitext --> path.rsplit('.')
>  - splitunc --> Unix specific!
>  - stat --> should be private!
>  + supports_unicode_filenames --> windows specific!
>  - sys --> should be private!
>  + walk - warnings --> should be private!
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>  2. Poor Name Choices:
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>  * basename --> should be: filename * split --> split what?
>  * splitext --> Wow, informative!
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>  3. Non Public Names Exposed!
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>  * genericpath * os * stat * sys * warnings
> 
> 
> Note: i did not check the Unix version of os.path for this.
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>  4. Duplicated functionality.
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>>>> os.path.lexists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
>>>> os.path.exists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
> 
> Should have been one method:
>>>> os.path.exists(path, ignoreSymLnks=False)

so far all I have is posts stating that everything is wrong.

instead of all this negativity why don't you try being productive for a 
change either make a suggestion for an addition (ie something that does 
not yest exits) or better yet give us all the benefit of your supreme 
coding talent & provide some code?



-- 
One expresses well the love he does not feel.
		-- J.A. Karr

[toc] | [prev] | [next] | [standalone]

#10550

On 2011.07.29 04:21 PM, Alister Ware wrote:
> instead of all this negativity why don't you try being productive for a 
> change either make a suggestion for an addition (ie something that does 
> not yest exits) or better yet give us all the benefit of your supreme 
> coding talent & provide some code?
Because trolling the group is apparently more fun, even though most of
the regulars here know he's trolling.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB

[toc] | [prev] | [next] | [standalone]

#10551

On Sat, Jul 30, 2011 at 6:44 AM, Corey Richardson <kb1pkl@aim.com> wrote:
> Excerpts from rantingrick's message of Fri Jul 29 13:22:04 -0400 2011:
>>  * New path module will ONLY support one path sep!
>
> People who use windows are used to \ being their pathsep. If you show
> them a path that looks like C:/whatever/the/path in an app, they are
> going to think you are nuts. It isn't up to us to decide what anyone
> uses as a path separator. They use \ natively, so should we. If at
> any point Windows as an OS starts using /'s, and not support, actually
> uses (in Windows Explorer as default (or whatever the filebrowser's
> name is)), it would be great to switch over.

Just tested this: You can type c:/foldername into the box at the top
of a folder in Explorer, and it works. It will translate it to
c:\foldername though.

We are not here to talk solely to OSes. We are here primarily to talk
to users. If you want to display a path to the user, it's best to do
so in the way they're accustomed to - so on Windows, display
backslashes.

>>  - normcase --> path = path.lower()
>
> Not quite, here are a few implementations of normcase (pulled from 2.7)
>
> # NT
>    return s.replace("/", "\\").lower()
>
> # Mac (Correct in this case)
>    return path.lower()
>
> # POSIX
>    return s
>
> But I can't think of where I would ever use that. Isn't case important on
> Windows?

No, as is demonstrated by the three above; case isn't important on
Windows, but it is on Unix.

>>  - normpath --> should not need this!
>
> Why not? It provides an OS-independent way to make the pathname look pretty,
> maybe for output? I don't really see a use for it, to be honest.

See above, we talk to users.

> But I'd
> rather there be a working solution in the stdlib than have everyone need to
> throw in their own that might not handle some things properly.

Absolutely!
>>  * basename --> should be: filename
>
> I agree. The name is a carryover from basename(1) and I guess it's good for
> those people, but it certainly isn't the least surprising name. If anything,
> I would think the base is everything before!

Agreed that it's an odd name; to me, "basename" means no path and no
extension - the base name from r"c:\foo\bar\quux.txt" is "quux".
Unfortunately that's not what this function returns, which would be
"quux.txt".

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web