nvie
mkmodule -p doesn't create package if there's module with the same name
Looking at comment in code I assume you are aware of this, but let's make it official issue. If you use mkmodule -p foo (undocumented btw - will look at it when we resolve this one) it first creates foo.py and then promotes it. Problem arises when there's already existing foo.py. I think, in this case, promoting module to package isn't good idea and it should be created straight away. Perhaps creating class Package similar to Module would be useful. Also, I'd probably rather create new command mkpackage for this.
Actually, this is as-intended. mkmodule -p behaves like promote when the module path already exists, otherwise creates it. I've added an explicit test case for this, to express this intent. I think this is useful behaviour when you're using this in custom shell scripts (since you can't test for module existence from the shell interface).
As another example, this is pretty much the same logic as it applies to the following scenario:
$ mkmodule foo.bar
$ echo "print 'Hello'" >> foo/bar.py
$ mkmodule foo.bar.qux
$ cat foo/bar/__init__.py
print 'Hello'
(The foo.bar module is silently converted into a package to make room for the qux.py creation.)
Well, it really does work when you test only Module. But integrated to command, it breaks up because of this condition. Just try to create foo.py and then run mkmodule -p foo. I made, for now, very quick and dirty fix: https://github.com/ondrowan/python-fu/commit/8d66c5f0ec4c03055470012a71ed8b1cfc5b331a, haven't had time for more. Take it as proof of concept.
Ah, I see what you mean now. Yep, this should be fixed. I'll look at your patch tomorrow.