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?
Thanks,
Jack
>
> For example:
>
> foo.py
> -------------------
> def some_function():
> print "Some function"
>
> bar.py
> ------------------
> from foo import some_function
>
> quux.py
> ------------------
> from bar import some_function
> some_function()
>
> $ python quux.py
> Some function
>
>
> What you decide to do here seems implementation-specific and not
> related to the ARC case (in my view), but I leave it up to you.
>
> Cheers,
