[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Roundup Robot added the comment: New changeset e26113f17309 by Larry Hastings in branch 'default': Issue #15202: Additional documentation fixes inadvertently omitted http://hg.python.org/cpython/rev/e26113f17309 -- ___ Python tracker

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: Sorry; the patch didn't apply cleanly, and it looks like I bungled doing it manually. Fixing now. -- ___ Python tracker ___ _

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Éric Araujo added the comment: There are versionadded notes in the doc that still use the old names (e.g. symlinks for shutil.copyfile). -- nosy: +eric.araujo ___ Python tracker __

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Roundup Robot added the comment: New changeset 758a9023d836 by Larry Hastings in branch 'default': Issue #15202: Consistently use the name "follow_symlinks" for http://hg.python.org/cpython/rev/758a9023d836 -- nosy: +python-dev ___ Python tracker

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Antoine Pitrou added the comment: > The .4 patches both LGTM, please commit! You're the one with commit rights here ;) -- ___ Python tracker ___ ___

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: The .4 patches both LGTM, please commit! -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: > What's the urge to make parameters keyword-only? I suggest that boolean parameters are best made keyword-only. Otherwise you have mystery meat like shutil.copyfile("src", "dst", True) Also, all the extant uses of "follow_symlinks" in os are keyword-only,

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Antoine Pitrou added the comment: > > Also, copyfile() shouldn't change signature. > Why not? Seems like I have misread the docs. Apparently the symlinks parameter was added in 3.3. -- ___ Python tracker __

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Serhiy Storchaka added the comment: > What's the urge to make parameters keyword-only? If anyone uses these functions with a new "symlinks" parameter in 3.3b1, he will get loud error (follow_symlinks == not symlinks). > Also, copyfile() shouldn't change signature. Why not? -- __

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26233/symlinks-to-follow_symlinks-4.patch ___ Python tracker ___ ___ Pyth

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26232/symlinks-to-follow_symlinks-4.patch ___ Python tracker ___ ___ P

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Antoine Pitrou added the comment: What's the urge to make parameters keyword-only? Also, copyfile() shouldn't change signature. -- nosy: +pitrou ___ Python tracker ___ _

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Serhiy Storchaka added the comment: > So, please make the relevant code changes I proposed on Rietveld (adding "*," > everywhere was it iirc) and resubmit and we can get that in. I'll give you a > code-only review of the other patch too--I'll start on that now. Here is a changed patches. Pe

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: Storchaka: change of plan. Since doc changes are much lower risk than code changes, how about we go with your existing patch and I'll fix up the docs separately. So, please make the relevant code changes I proposed on Rietveld (adding "*," everywhere was it

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: Serihy: for the "followlinks" patch, how about we plan ahead: I give you feedback for just the code (if there is any), and then I take over the patch and do the doc rewrite that I will find irresistable. -- ___ Pyt

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26195/symlinks-to-follow_symlinks-2.patch ___ Python tracker ___ ___ P

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26194/followlinks-to-follow_symlinks-2.patch ___ Python tracker ___ __

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Serhiy Storchaka added the comment: Here is an updated patches (with index 3). No aliased parameters, only new parameters renamed. Some minor errors have fixed. -- Added file: http://bugs.python.org/file26225/followlinks-to-follow_symlinks-3.patch Added file: http://bugs.python.org/fil

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: Georg just clarified: we can just change the parameter names for new APIs. It's the deprecation / new parameter stuff we can't do for 3.3. So cut a (much) simpler patch and let's get it in right quick. -- versions: +Python 3.3 -Python 3.4 _

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: Bad news: Fearless Leader (Georg) just told me on #python-dev that he's had a change of heart and doesn't want this in 3.3. I've marked the bug 3.4, and there's no rush on doing this work--we can't check it in until the 3.4 branch exists. Sorry, Serhiy :(

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: storchaka: I can (finally!) spend some time reviewing patches today. Which ones do I look at? I'm guessing just the last two, "followlinks-to-follow_symlinks-2.patch" and "symlinks-to-follow_symlinks-2.patch". But I wanted to confirm before I got knee-dee

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Serhiy Storchaka added the comment: Here is updated patches. The type of exception thrown when specifying mutually exclusive arguments changed from ValueError to TypeError (in accordance with the raised in similar conflicts exceptions). Slightly modified documentation. Taken into account some of

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Serhiy Storchaka added the comment: And here is a patch, that replaces "symlinks" arguments in shutil by "follow_symlinks" (with keeping old name if it exists before 3.3). I very hope native speakers corrected me in docs. -- Added file: http://bugs.python.org/file26187/symlinks-to-follo

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: > > after all, they *are* instance variables. > Technically, they are local variables. Yeah, tbh I was thinking "instance of an invocation" here. But PEP 8 probably means "instance of a class" here. Still, there are three classes of naming things in Python:

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26184/followlinks-to-follow_symlinks.patch ___ Python tracker ___ ___ Py

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26182/followlinks-to-follow_symlinks.patch ___ Python tracker ___ ___

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Serhiy Storchaka added the comment: > IMO adding follow_symlinks to the functions currently supporting > symlinks/followlinks is a bugfix. Such a patch would be ok to go into 3.3. Here is an other patch, that implements Larry's suggestion about renaming followlinks in (f)walk to follow_symlin

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Serhiy Storchaka added the comment: > I dislike "followlinks" because "links" is ambiguous; both hard links > and soft links are "links", but it's only modifying behavior regarding > one of them. Technically, in Unix world any file is a hard link. It is impossible to distinguish a hard link fro

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Georg Brandl added the comment: IMO adding follow_symlinks to the functions currently supporting symlinks/followlinks is a bugfix. Such a patch would be ok to go into 3.3. -- ___ Python tracker _

[issue15202] followlinks/follow_symlinks/symlinks flags unification

R. David Murray added the comment: Although I do dislike how long it is, I think I agree with larry on this one that follow_symlinks is the cleanest choice. And we are post feature-freeze, so I think changing it should be done only if there is a strong reason. -- nosy: +r.david.murra

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: > I don't see how this is contrary to PEP 8. PEP 8 says nothing about > the names of function arguments. Certainly it says *something*: http://www.python.org/dev/peps/pep-0008/#function-and-method-arguments But I grant you, it only specifically addresses "sel

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Serhiy Storchaka added the comment: > Also, it's not PEP-8-compliant (which we can forgive because I'm pretty sure > it predates PEP 8). I don't see how this is contrary to PEP 8. PEP 8 says nothing about the names of function arguments. > Already I suspect it is too late. If it ships in 3.3

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Larry Hastings added the comment: I assert that "followlinks" and "symlinks" are both bad names. I dislike "followlinks" because "links" is ambiguous; both hard links and soft links are "links", but it's only modifying behavior regarding one of them. Also, it's not PEP-8-compliant (which we

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : -- type: -> behavior versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Hynek Schlawack added the comment: Yeah, would be nice if that was consistent. -- nosy: +hynek ___ Python tracker ___ ___ Python-bugs

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : -- nosy: +larry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue15202] followlinks/follow_symlinks/symlinks flags unification

Changes by Serhiy Storchaka : -- title: followlinks/follow_symlinks/symlinks flags unification. -> followlinks/follow_symlinks/symlinks flags unification ___ Python tracker ___

[issue15202] followlinks/follow_symlinks/symlinks flags unification.

New submission from Serhiy Storchaka : Now three different flag are used to denote the same behavior. followlinks is used in os.(f)walk, symlinks is used in shutil functions (with opposite meaning), and follow_symlinks is just added to many os functions. Unfortunately, symlinks, like followlin