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é <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
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
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.comwrote:
"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
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.
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
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,
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 Ryanlie.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