Added the rename method to the module uos - #2082

Thanks for your patch! Unfortunately, its commit message don't follow the project conventions. These are described in https://github.com/micropython/micropython/blob/master/CODECONVENTIONS.md , and you were presented link to this document when you prepared this pull request (via https://github.com/micropython/micropython/blob/master/CONTRIBUTING.md document, which contains links to other important information).

Before the patch can be merged, the commit message(s) should be fixed. We encourage you to do this on your side (via git interactive rebase features, git rebase -i). Alternatively, project maintainers may fix it (at their choice), but if that's done, it will always lead to delayed processing (up to 1 month).

The project codebase receives high praises for its quality and cleanliness, that was enables us (contributors) to easily prepare patches for it. Let's make sure that after our contributions, the codebase stays clean as before! Thanks!

Hi Paul. I tried to follow you suggestions, but got screwed up by git. I think I'll wait.
Best Regards

As far as I can see, everything is ok. And thanks for trying it (otherwise can be seen just as a reminder for next time ;-) ).

Merged, thanks! Any other missing method is of course not on purpose, but an omission. Feel free to report them/submit patches too.

Hello Paul,

is it worth a change to add aliases of remove named unlink and rmdir to
the code, like it is in WiPy and PybOard? It's just the QSTR definition,
but obviously redundant.

Regards, Robert

On 16.05.2016 14:25, Paul Sokolovsky wrote:

Merged, thanks! Any other missing method is of course not on purpose,
but an omission. Feel free to report them/submit patches too.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#2082 (comment)

add aliases of remove named unlink

Nope, I don't think it needs to be added, unless there's a specific reason to add it, and I can't think of one where reply "user remove() instead" wouldn't work. Feel free to share if you have one.

rmdir

Is a different case, it POSIX OS (and thus in Python), you can't delete a directory with remove(), it should be proper rmdir(), whcih is probably not exposed in FatFs VFS object yet at all. I'm not sure if you hint that with FatFS, remove() can remove a dir though. If so, as a quick fix, we can make rmdir() be an alias to remove() indeed.

Hello Paul,
thank you for the response. I would add unlink() as alias only for
compatibility with the Pyboard and WiPy port.
rmdir() is a slightly different topic. In WipPY it's simple alias to
remove(), in PybOard remove() is used for deleting, but if that fails, a
specific error message is prepared. Using remove() to remove a directory
obviously works, just the potential error message is not 100% right, and
surely there will be people who complain, if that call was named rmdir().

I made a trial coding of chdir(), by just copying in the code from the
stmhal port. That works but from the code style is does not fit into the
vfs proxy structure. Again, this is not urgently needed, You can always
specify the full path, avoiding chdir().

Nothing of that is important, and since the policy of the ESP8266 port
seems to keep it as minimal as possible and avoid any redundancy,
leaving that off is a good decision, and I want to respect that.
Kind Regards, Robert

On 18.05.2016 22:28, Paul Sokolovsky wrote:

add aliases of remove named unlink

Nope, I don't think it needs to be added, unless there's a specific
reason to add it, and I can't think of one where reply "user remove()
instead" wouldn't work. Feel free to share if you have one.

rmdir

Is a different case, it POSIX OS (and thus in Python), you can't delete
a directory with remove(), it should be proper rmdir(), whcih is
probably not exposed in FatFs VFS object yet at all. I'm not sure if you
hint that with FatFS, remove() can remove a dir though. If so, as a
quick fix, we can make rmdir() be an alias to remove() indeed.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#2082 (comment)