On Monday, February 29, 2016 12:39:40 PM CST Michael Mraka wrote:
Brian C. Lane wrote: % % This code was in a top level module and was not marked with _ as is % the python convention for private methods. Whether or not you document % the api is immaterial. If you expose a method it is going to eventually % get used by someone.
What exactly mean "top level module"? I'd consider dnf to be top level not dnf.arch.
% See % https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces % for the correct way to manage exposing public methods (eg. use of % __all__ and _)
Public and internal interfaces
... Documented interfaces are considered public, unless the documentation explicitly declares them to be provisional or internal interfaces exempt from the usual backwards compatibility guarantees. All *undocumented* interfaces should be assumed to be internal.
% Also, it is pretty clear that this method is in use by dnf users. It % would be far better if you added arch.py with a deprecation warning % instead of insisting that all your users rewrite their code across 4 % releases.
After the dnf build today composing broke again https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20160309.n. 1/logs/x86_64/buildinstall-Server.x86_64.log
I have yet again untagged the dnf build from rawhide, and given negative feedback on the updates to make sure they do not go out also. I could not find a Fedora 24 update for the build there. Please fix this in dnf approrpiately. you have to assume people are using an api call that does not have _ infront of it as is the python standard, regardless of if you documented the interface or not.
Dennis