On Wed, Feb 16, 2011 at 09:15:25AM +0200, Panu Matilainen wrote: > > Consider module "foo" importing "os", because it needs stuff from > there to do its business. Somebody is developing a piece of code > utilizing the "foo" module, and notices "hey its importing os, how > convenient - now I dont have to add my own os import as I can just > use foo.os." Legitimate? I dont think so... and me thinks the case > we're discussing here is similar. Unfortunately python doesn't have a > good way of expressing the intent of an import
Python does actually have a way of expressing that but it's not precisely a good way. __all__ is used to define which toplevel symbols (including modules that are imported) should be re-exported when you do "from foo import *". This has become a sort of de facto means of expressing intent about imports and public api. There are several reasons that this isn't the greatest mechanism: although it affects "from foo import *" the other modules still show up if you were to do "import foo ; dir(foo)", "import foo.os" will still work if you happen to think that's a good idea for some reason, and while people mostly agree about how __all__ describes intent when dealing with modules importing other modules, they disagree on what it means for the rest of an API (If I don't put a function into __all__ does that mean that I think it's part of the private API? Or just that it shouldn't be exported if someone does "from foo import *"?) > (short of doing > "import foo as _foo" for everything, but AFAIK nobody does that, > small wonder... :) > Someone recently commented that they use this style on python-dev in their module that now lives in the stdlib. Discussion there said that it was okay but not something to be demanded of all developers :-) -Toshio
pgp2j0EfjZZcK.pgp
Description: PGP signature
_______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
