-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add shutil.chown to allow to use user and group name (and not only uid/gid) #56400
Comments
Hi, following up the discussion on http://mail.python.org/pipermail/python-dev/2011-May/111642.html here'a patch to introduce shutil.chown() along with doc, tests and a change in os doc to link to the new function (I also took the occasion to rewrap os.chown() doc text). As of now only the one-file function is implemented, let's see at a later time what's about for a recursive one. The patch was prepared against default, but it probably makes sense to backport it to 2.7? Any comment/suggestion is welcome! |
As a new feature, it can't be added to 2.7. |
I didn't test, but after skimming through the code I think that if an invalid user name/group name is provided, os.chown is passed None, which will fail with ValueError. Also, you could initialize _user to -1 instead of None, and replace Same goes for _group. |
As a general rule, rewrapping is not done in patches, it can make review less easy. The committer can do it, sometimes in a second commit. I commented on the review page. |
I added comments in the code review. this patch is looking good once the comments are addressed. thanks for your contribution! As for talk of support for recursion... thats what os.walk() is for. it doesn't belong as part of any particular individual function itself. |
The python-dev discussion talked about chowntree vs. os.walk: I find those arguments of convenience and precedent convincing. |
@eric: ok, I was just asking given the "unusual" situation 2.7 is (i.e. a very long support series), but it's perfectly fine not to backport the feature. @Charles-François: I changed a bit the logic: I check for 'None' at first, since it signals that we don't want to change the uid/gid, and then I recheck for None after _get_uid/gid, and only there raise a ValueError (is there a better exception for cases like this?) - what do you think about it? @Éric: re rewrap: I kinda find that almost every core dev has his opinion on this :) some don't want to rewrap, others are fine if you're touching that paragraph, and so on. Anyhow, to be on the safe-side, I un-rewrapped the first paragraph of os.chown(). @gregory: I'd like to first concentrate on the "single path" function, then we'll look at the "tree" version. Thanks a lot to everyone for the review/comment/inspiration: attached you can find the updated patch. If something still needs a fix, I'd be happy to work on it. |
|
Here's the updated patch following review on Rietveld |
shutil_chown-default-v3.patch:
|
haypo, you missed this comment from gps on Rietveld:
I agree the patch is ready. |
I've applied some of the suggestions Victor made (and also refresh to be cleanly applicable on default). |
Sorry for the late reply: I've applied Éric comments made on Rietveld. |
You should replace the v5 file (or even remove all files, for clarity) with the actual output of hg diff, not hg status ;-) |
Gaaah, sorry about that: I've just uploaded the correct fifth version. |
I wonder if we should raise LookupError for unknown uids/gids. Do we have other APIs with similar semantics? |
grepping over the stdlib, LookupError is only used in codecs exception; also the documentation of LE is "The base class for the exceptions that are raised when a key or index used on a mapping or sequence is invalid: IndexError, KeyError. This can be raised directly by codecs.lookup()." so I guess it's not the right exception of this case. |
Well, you could consider codecs an example in the stdlib of using it, and the doc could be changed to something like "stdlib modules that look up information in specialized data sources may raise this error directly". Whether this is a good idea or not, I'm not sure, but it feels more logical than ValueError. |
On Mon, Aug 8, 2011 at 00:12, R. David Murray <report@bugs.python.org> wrote:
Sure, I was just showing my line of reasoning :) I'm ok either way: if |
LookupError sounds good. About the latest patch: I wonder if using !a instead of !r in the format strings for exceptions would be more helpful (maybe you’ve seen a recent python-dev subthread about that). I don’t like seeing escapes for perfectly common characters like ß or é, but OTOH escapes help disambiguating different characters that look the same. Apart from these two points, this is good to go. A doc addition for LookupError would be an independent changeset; it has nothing to do with adding shutil.chown. |
after a review from Ezio (thanks!) we've come out with this updated patch; main changes are in the test suite, where now it's checked that chown() succeed. about !r/!a I've left !r; and changed the 2 ValueError in LookupError (the first, in case no arguments are passed, it's still there). |
version 7 here we come :) I've addressed Eric's commenta on rietveld (all but one, I need input from him) and also updated the tests for new helper functions. |
New changeset d1fd0f0f8e68 by Sandro Tosi in branch 'default': |
At last, it's in :) thanks a lot to all the people that helped me in the process! |
You may add shutil.chmod to the "What's New in Python 3.3?" document. |
Raymond, are you still taking care of the whatsnew? |
New changeset 5d317e38da44 by Sandro Tosi in branch 'default': |
Ezio: I think that Raymond is in charge of the 3.3 whatsnew too. The rules in a comment at the top of the file still apply: there are already around 30 notes to the file. |
New changeset f2cb733c9a37 by Sandro Tosi in branch 'default': |
I have added 'chown' in shutil.__all__. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: