I would like to be able to list a directory, but without showing hidden files. Currently, as discussed in a SO question [1], one has to either code this manually or resort to other libraries (glob). This functionality should be available in the os module.

[1]: http://stackoverflow.com/questions/7099290/how-to-ignore-hidden-files-using-os-listdir-python

So, I'm having a .gitignore file on Windows. Its hidden or not? In other words, only your code feel the difference in "hidden files policy".
BTW, Mas OSX using two ways - dotfiles and "invisible" flags in Finder:

$ chflags hidden i-am-hidden-now.txt

(but 'ls' showing it)

I created a first version of the patch (attached as a remote hg repo). It would enable users to exclude hidden files with:

    import os
    print(os.listdir(path='.', show_hidden=False))

while still keeping full backwards compatibility, since show_hidden is an optional argument set to True by default.

@Dmi Baranov - well, I think aiming at the ls functionality would be a good first step (so we would mimic the -a flag, as explained in the manpage). As far as Windows, that's not too clear, I agree. So far I only added the functionality to the posix_listdir. Do you think this should act the same on Windows - i.e. hiding  dotfiles?

The concept of hidden file depends on the platform, and is independent of the listdir() function. The first thing is to agree on an implementation of the "hidden" property, and expose it as os.path.ishidden.

Then we can consider an option to os.listdir.
But do we need it? today it does not have any option at all, like isfile or isdir which would be more useful.

I don't really understand, since this is an easy one-liner:

[n for n in os.listdir(...) if not n.startswith(".")]

Also, as mentioned, what you want to hide is not necessarily well-defined. For example, under Unix you might want to hide "*~" files.
So I don't think os.listdir() should grow such an option, it's up to user code to decide what should be displayed / reported to the user.

(or in other words: while Python provides filesystem-access functions, Python is not a shell)

> Also, as mentioned, what you want to hide is not necessarily
> well-defined. For example, under Unix you might want
> to hide "*~" files.

Yes, and instead of adding another parameters, something like that:

os.listdir(path, show_hidden=False, hidden_files_mask='*~', but_show_directories=True, something_etc=None)

I suggest leaving the "hidden files" logic outside of stdlib (in the end-user code). Welcome to `glob` / `fnmatch` modules :-)

@Amaury Forgeot d'Arc - well, the '.' and '..' special files are
detected directly in the listdir code, so I don't think there is any
need to interleave this logic any deeper (such as os.path.ishidden).

@Antoine Pitrou - a one-liner, but it unnecessarily complicates the
code - an optional argument is a much more elegant solution in my
opinion. Regarding the *~ files - they are backup files, not hidden
files (same as e.g. #somefile# files that Emacs generates). These are
shown by ls, just hidden in some desktop environments.

Another point is that dotfiles are really something of a special case
(especially to programmers http://dotfiles.github.io/ ), because many
programs store configurations and special data inside and it makes
sense to allow users to omit these.

I know I could use glob, I am currently doing that, but it seems like
bad practice to switch to a different module that is also in the
standard library, just it has the "dotfile detection magic" and os
doesn't. The fact is that dotfiles do have special a meaning in Unix
operating systems and the os module documentation states that some
functionality is only tailored to Unix-based platforms
(http://docs.python.org/2/library/os.html):

    An “Availability: Unix” note means that this function is commonly
found on Unix systems. It does not make any claims about its existence
on a specific operating system.

On Wed, May 29, 2013 at 1:05 PM, Serhiy Storchaka
<report@bugs.python.org> wrote:
>
> Changes by Serhiy Storchaka <storchaka@gmail.com>:
>
>
> ----------
> resolution:  -> rejected
> stage:  -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue18087>
> _______________________________________