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