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
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
