Re: Dnf untagging and unpushing of updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
Michael Mráka
Software Management Engineering, Red Hat
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux