make os.listdir() path argument be os.curdir.

I am working on a patch, I'll submit here

If this is to go into Py3.1, it needs to happen quickly.

After a deeper look; this change looks rather complex for a posixpath.c
newbie like me.

I probably won't be able to provide it for 3.1. If you want to do it for
3.1, please go ahead Raymond !

I saw this ticket as a good way to get my feet wet (I almost never touched 
C) with Python's C API, so I went ahead and did the part for OS X. I also 
did the Windows part, but I'm not setup to compile Python on Windows, so I 
don't even know if it remotely works.

It would be nice if someone could review this patch and tell me about 
mistakes (such as memory management ones, probably). Thanks!

Some comments about the patch:

- It seems wasteful to allocate a new PyUnicode object for the "."; the 
posix implements does it right: a simple wcscopy should be enough (and 
reduces the chances of refcount mistakes)

- the last block is not correctly indented; this code uses tabs.

- no need to test for hasattr(posix, 'listdir'): all supported platforms 
have directories and the posix module always exposes this function.

1. Yeah, I know. At first, that's what I wanted to do, but it resulted 
in a lot of code duplication (alloc, memerror, copy), which I didn't 
much like. But then again, what I ended up writing (because I realized I 
had to decref the  new "po") uses up more lines anyway...

2. oops

3. I did it because all other tests do it. I thought there had to be a 
reason (but then again, that old broken "lsdir" test had been there for 
a while...). Even if there's no reason. the new test would really stand 
out compared to the rest...

Since I last submitted this patch, my leet C skills have improved.

I'm submitting another patch, without the needless PyUnicode creation this time. (Moreover, I think the previous patch was wrong to insert code before variable declaration of the block)

Here's another one. I hadn't realized that it was useless to target the 2.x codebase. So I re-worked this on py3k. The change is non-trivial, since the non-windows/non-os2 part of the code has significantly changed in 3k. This time, since "oname" is released later and used in error conditions, I thought it was worth it to allocate a new PyBytes for the default value.

I also modified the documentation so that it tells about path's default value.

At Europython, we agreed that this functionality is too trivial to add to the standard library; for all practical purposes, os.listdir(".") will do the right thing.

So rejecting this as won't fix.

what do you mean by 'too trivial' ?

I don't understand why this is now suddenly rejected. Raymond, Guido, and other people have +1 this on python-ideas.

http://mail.python.org/pipermail/python-ideas/2009-May/004871.html

People have worked on a patch, so I think this is unfair to close it now without more explanations, and just say that 'we agreed at EP'...

ok, so reopening. Linking to the mailing list would have helped.

Yes, sorry. I should have added the link when I opened the bug. Thanks for reopening it

reopening again sorry (roundup bug)

Thanks for the patch. Committed (with modifications) as r83078.

Thanks for looking into this !