On 03/10/10 03:14 PM, Jack Schwartz wrote: > HI Shawn. > > On 03/10/10 01:03 PM, Shawn Walker wrote: >> On 03/10/10 02:52 PM, Jack Schwartz wrote: >>> Hi Sebastien. >>> >>> On 03/10/10 07:50 AM, Sebastien Roy wrote: >>>> On 03/10/10 02:56 AM, Frank Che wrote: >>>>> The project team has updated the exported interface table according to >>>>> the review feedbacks. I have just updated file 'spec.txt' in the case >>>>> directory to reflect this change. >>>> >>>> I'm sorry to keep harping on this point, but the python module and/or >>>> package names are still not included as an exported interface, and >>>> that seems like an important detail. Programs need to "import >>>> <module>" to get at this stuff, right? What is that? Assuming that we >>>> resolve this issue, I give the case a +1. >>> Since I wrote the specs that the below issues deal with (with the help >>> of the DDU team, of course), I feel it is appropriate for me to >>> respond... >>> >>> For convenience regarding modifying the case documents, current >>> filenames and the classes/functions they contain are: >>> >>> ddu_devdata.py : >>> ddu_dev_data class >>> ddu_errors.py: >>> contains all DDU-specific exception classes. >>> ddu_function.py: >>> ddu_build_repo_list() >>> ddu_devscan() >>> ddu_package_lookup() >>> ddu_install_package() >>> ddu_package.py: >>> ddu_package_object class >>> ddu_repo.py: >>> ddu_repo_object class >>>> That said, looking more closely at the API, I have some additional >>>> feedback. It's a Consolidation Private API and these are all >>>> superficial issues, so I don't feel strongly about the below issues. >>>> >>>> * There's no need to prefix all of your symbols with "ddu_". Don't you >>>> need to access your base methods using <module>.<function>() anyway? >>>> E.g., ddu.devscan() seems cleaner than ddu.ddu_devscan(). >>> Yes and no. One can access methods as you say, but more commonly, one >>> says at the top of a python module: >>> >>> from DDU.ddu_function.py import ddu_package_lookup >>> >>> and then uses ddu_package_lookup henceforth in that module without a >>> prefix. No need to muddy up the code unnecessarily with <module> every >>> time you call a function. >>> >>> This is standard practice and what the DDU code does. >> >> While it is common, there is a subtle consequence to doing so. >> >> Doing an import that way means that your namespace will contain that >> other module's symbols too. > If we import a specific function and not *, shouldn't that mean that the > namespace gets only that function, and not all in the module? Why would > it get the whole module?
As my example showed, it will at least contain the specific symbols you imported. Obviously '*' is really bad. So just something to keep in mind. -- Shawn Walker
