On 14 Jul 2014 22:50, "Ben Hoyt" <benh...@gmail.com> wrote:
>
> In light of that, I propose I update the PEP to basically follow
> Victor's model of is_X() and stat() following symlinks by default, and
> allowing you to specify follow_symlinks=False if you want something
> other than that.
>
> Victor had one other question:
>
> > What happens to name and full_name with followlinks=True?
> > Do they contain the name in the directory (name of the symlink)
> > or name of the linked file?
>
> I would say they should contain the name and full path of the entry --
> the symlink, NOT the linked file. They kind of have to, right,
> otherwise they'd have to be method calls that potentially call the
> system.

It would be worth explicitly pointing out "os.readlink(entry.full_name)" in
the docs as the way to get the target of a symlink entry.

Alternatively, it may be worth including a readlink() method directly on
the entry objects. (That can easily be added later though, so no need for
it in the initial proposal).

>
> In any case, here's the modified proposal:
>
> scandir(path='.') -> generator of DirEntry objects, which have:
>
> * name: name as per listdir()
> * full_name: full path name (not necessarily absolute), equivalent of
> os.path.join(path, entry.name)
> * is_dir(follow_symlinks=True): like os.path.isdir(entry.full_name),
> but free in most cases; cached per entry
> * is_file(follow_symlinks=True): like os.path.isfile(entry.full_name),
> but free in most cases; cached per entry
> * is_symlink(): like os.path.islink(), but free in most cases; cached per
entry
> * stat(follow_symlinks=True): like os.stat(entry.full_name,
> follow_symlinks=follow_symlinks); cached per entry
>
> The above may not be quite perfect, but it's good, and I think there's
> been enough bike-shedding on the API. :-)

+1, sounds good to me (and I like having the caching guarantees listed -
helps make it clear how DirEntry differs from pathlib.Path)

Cheers,
Nick.

>
> So please speak now or forever hold your peace. :-) I intend to update
> the PEP to reflect this and make a few other clarifications in the
> next few days.
>
> -Ben
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to