os.listdir with current working directory as default
Hello, A very small change: what about making the path argument optional for os.listdir ? and use the current working directory if not provided. listdir(...) listdir(path=None) -> list_of_strings Return a list containing the names of the entries in the directory. path: path of directory to list. If path is None, os.getcwd() is used. The list is in arbitrary order. It does not include the special entries '.' and '..' even if they are present in the directory. Cheers Tarek -- Tarek Ziadé | http://ziade.org
Tarek Ziadé <ziade.tarek@...> writes:
A very small change: what about making the path argument optional for os.listdir ? and use the current working directory if not provided.
Disagreed. If you want the current directory, you just have to use ".". Regards Antoine.
Antoine Pitrou schrieb:
Tarek Ziadé <ziade.tarek@...> writes:
A very small change: what about making the path argument optional for os.listdir ? and use the current working directory if not provided.
Disagreed. If you want the current directory, you just have to use ".".
or os.curdir to be precise :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sat, May 23, 2009 at 1:16 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Antoine Pitrou schrieb:
Tarek Ziadé <ziade.tarek@...> writes:
A very small change: what about making the path argument optional for os.listdir ? and use the current working directory if not provided.
Disagreed. If you want the current directory, you just have to use ".".
or os.curdir to be precise :)
yes, same question then, make these equivalent: os.listdir(os.curdir) <-> os.listdir()
Tarek Ziadé schrieb:
On Sat, May 23, 2009 at 1:16 AM, Georg Brandl <g.brandl-hi6Y0CQ0nG0@public.gmane.org> wrote:
Antoine Pitrou schrieb:
Tarek Ziadé <ziade.tarek@...> writes:
A very small change: what about making the path argument optional for os.listdir ? and use the current working directory if not provided.
Disagreed. If you want the current directory, you just have to use ".".
or os.curdir to be precise :)
yes, same question then, make these equivalent:
os.listdir(os.curdir) <-> os.listdir()
This seems to be a nice case of EIBTI to me. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sat, May 23, 2009 at 1:46 AM, Georg Brandl <g.brandl@gmx.net> wrote:
os.listdir(os.curdir) <-> os.listdir()
This seems to be a nice case of EIBTI to me.
I would rather call that a default behavior, otherwise every function with arguments that have default values would be nice cases of EIBTI.
os.listdir(os.curdir) <-> os.listdir()
+1 Lots of functions have useful defaults and this one would be familiar to everyone who programs (what does "dir" do without arguments on Windows or an "ls" do without arguments for Linux). Raymond
"Raymond Hettinger" <python@rcn.com> wrote:
os.listdir(os.curdir) <-> os.listdir()
+1
Lots of functions have useful defaults and this one would be familiar to everyone who programs (what does "dir" do without arguments on Windows or an "ls" do without arguments for Linux).
+1. I remember being surprised that os.listdir() did not work (I was expecting the requested behavior). If this were not parallel to the default behavior of ls and dir I'd be -1, but as it is I think it is less surprising for it to work. --David
+1 On Sat, May 23, 2009 at 11:28 AM, R. David Murray <rdmurray@bitdance.com>wrote:
"Raymond Hettinger" <python@rcn.com> wrote:
os.listdir(os.curdir) <-> os.listdir()
+1
Lots of functions have useful defaults and this one would be familiar to everyone who programs (what does "dir" do without arguments on Windows or an "ls" do without arguments for Linux).
+1. I remember being surprised that os.listdir() did not work (I was expecting the requested behavior). If this were not parallel to the default behavior of ls and dir I'd be -1, but as it is I think it is less surprising for it to work.
--David
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"
2009/5/22 Raymond Hettinger <python@rcn.com>:
os.listdir(os.curdir) <-> os.listdir()
+1
Lots of functions have useful defaults and this one would be familiar to everyone who programs (what does "dir" do without arguments on Windows or an "ls" do without arguments for Linux).
+1 Can't see how it would really cause any confusion. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, May 22, 2009 at 8:01 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Sat, May 23, 2009 at 1:46 AM, Georg Brandl <g.brandl@gmx.net> wrote:
os.listdir(os.curdir) <-> os.listdir()
This seems to be a nice case of EIBTI to me.
I would rather call that a default behavior, otherwise every function with arguments that have default values would be nice cases of EIBTI.
Agreed, nobody writes "dir ." or "ls .", the implicit argument is obvious. George
George Sakkis schrieb:
On Fri, May 22, 2009 at 8:01 PM, Tarek Ziadé <ziade.tarek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Sat, May 23, 2009 at 1:46 AM, Georg Brandl <g.brandl-hi6Y0CQ0nG0@public.gmane.org> wrote:
os.listdir(os.curdir) <-> os.listdir()
This seems to be a nice case of EIBTI to me.
I would rather call that a default behavior, otherwise every function with arguments that have default values would be nice cases of EIBTI.
If a default value is there, it should be obvious. In this case, my feeling was that it wasn't, but thinking about it I don't really see another default, so +0.
Agreed, nobody writes "dir ." or "ls .", the implicit argument is obvious.
Well, the interactive shell shouldn't be considered a programming language, and even if you do, it's hardly Pythonic :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sat, May 23, 2009 at 6:54 PM, Georg Brandl <g.brandl@gmx.net> wrote:
If a default value is there, it should be obvious. In this case, my feeling was that it wasn't, but thinking about it I don't really see another default, so +0.
Since the feedbacks are positive, I have created an issue, and I'll work on a patch (#6095)
Agreed, nobody writes "dir ." or "ls .", the implicit argument is obvious.
Well, the interactive shell shouldn't be considered a programming language, and even if you do, it's hardly Pythonic :)
I don't think it's a matter of being in the interactive shell or not. As soon as your program is working with the filesystem, and is navigating into it by calling APIs like os.chdir, os.getcwd, etc, you have good chances to end up calling os.listdir on the current directory, and specifying os.curdir becomes superfluous imho because you know you are in os.curdir. Tarek
Tarek Ziadé <ziade.tarek@...> writes:
As soon as your program is working with the filesystem, and is navigating into it by calling APIs like os.chdir, os.getcwd, etc, you have good chances to end up calling os.listdir on the current directory, and specifying os.curdir becomes superfluous imho because you know you are in os.curdir.
You'd better be careful with it. The "current directory" is process-wide and so modifying it in a thread will affect all other threads in your program. I'm not saying all programs have this characteristic, but relying on the current directory rather than explicit paths isn't always a good idea... Regards Antoine.
On 24May2009 21:40, Antoine Pitrou <solipsis@pitrou.net> wrote: | Tarek Ziadé <ziade.tarek@...> writes: | > As soon as your program is working with the filesystem, and is | > navigating into it by calling APIs like os.chdir, os.getcwd, etc, | > you have good chances to end up calling os.listdir on the current | > directory, and specifying os.curdir becomes superfluous imho | > because you know you are in os.curdir. | | You'd better be careful with it. The "current directory" is process-wide | and so modifying it in a thread will affect all other threads in your | program. I'm not saying all programs have this characteristic, but relying | on the current directory rather than explicit paths isn't always a good idea... True, but if he's doing that the issue is already there. Changing listdir(curdir()) into listdir() isn't going the change any semantics. On the other hand, I've several times been bitten by shell scripts that change directory before doing something and in so doing quietly break some relative filenames... Same problem. Still, the problem's not with giving listdir a default, specificly. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Trust the computer industry to shorten Year 2000 to Y2K. It was this thinking that caused the problem in the first place. - Mark Ovens <marko@uk.radan.com>
You'd better be careful with it. The "current directory" is process-wide and so modifying it in a thread will affect all other threads in your program. I'm not saying all programs have this characteristic, but relying on the current directory rather than explicit paths isn't always a good idea...
Regards
Antoine.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
I agree with Antoine, but would go further to say that making it a default argument is an enablement - just making it easier for people to follow a bad pattern. This doesn't apply to all default arguments of course, just that the working directory is "considered harmful" and we probably shouldn't make changes that make it easier for people to use. -- Zachary Burns (407)590-4814 Aim - Zac256FL Production Engineer (Digital Overlord) Zindagi Games
Zac Burns wrote:
You'd better be careful with it. The "current directory" is process-wide and so modifying it in a thread will affect all other threads in your program. I'm not saying all programs have this characteristic, but relying on the current directory rather than explicit paths isn't always a good idea...
I agree with Antoine, but would go further to say that making it a default argument is an enablement - just making it easier for people to follow a bad pattern.
This doesn't apply to all default arguments of course, just that the working directory is "considered harmful" and we probably shouldn't make changes that make it easier for people to use.
When you open() files do you always use full path? Why don't we eliminate all modules and built-in function that uses relative path by default then? That way we will always be safe? Making open(), etc raise RelativePathError if using relative path.
Yes, I always do use the full path. -- Zachary Burns (407)590-4814 Aim - Zac256FL Production Engineer (Digital Overlord) Zindagi Games On Tue, Jun 9, 2009 at 11:25 PM, Lie Ryan<lie.1296@gmail.com> wrote:
Zac Burns wrote:
You'd better be careful with it. The "current directory" is process-wide and so modifying it in a thread will affect all other threads in your program. I'm not saying all programs have this characteristic, but relying on the current directory rather than explicit paths isn't always a good idea...
I agree with Antoine, but would go further to say that making it a default argument is an enablement - just making it easier for people to follow a bad pattern.
This doesn't apply to all default arguments of course, just that the working directory is "considered harmful" and we probably shouldn't make changes that make it easier for people to use.
When you open() files do you always use full path? Why don't we eliminate all modules and built-in function that uses relative path by default then? That way we will always be safe? Making open(), etc raise RelativePathError if using relative path.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Georg Brandl <g.brandl@gmx.net> wrote:
George Sakkis schrieb:
On Fri, May 22, 2009 at 8:01 PM, Tarek Ziadé <ziade.tarek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Sat, May 23, 2009 at 1:46 AM, Georg Brandl <g.brandl@gmx.net> wrote:
os.listdir(os.curdir) <-> os.listdir()
This seems to be a nice case of EIBTI to me.
I would rather call that a default behavior, otherwise every function with arguments that have default values would be nice cases of EIBTI.
If a default value is there, it should be obvious. In this case, my feeling was that it wasn't, but thinking about it I don't really see another default, so +0.
Agreed, nobody writes "dir ." or "ls .", the implicit argument is obvious.
Well, the interactive shell shouldn't be considered a programming language, and even if you do, it's hardly Pythonic :)
Ah, but in unix the interactive shell _is_ a programming language. :) But no, it isn't very pythonic, in many areas. --David
participants (11)
-
Antoine Pitrou -
Cameron Simpson -
Georg Brandl -
George Sakkis -
Guido van Rossum -
Lie Ryan -
R. David Murray -
Raymond Hettinger -
Tarek Ziadé -
Tennessee Leeuwenburg -
Zac Burns