Kristian Ovaska <kristian.ovaska at helsinki.fi> writes:
> David Bolen <db3l at fitlinxx.com>:
> >IMHO, there's nothing wrong with this approach, but you're much better
> >off just importing the definitions module normally ("import xxx"), and
> >then referencing your variables/functions through that module name.
>
> I disagree. I want them to be _handy_, which means no module name.
> Usually no other variables and functions are needed in the scripts
> (except some built-ins, maybe), so it would be annoying to prefix them
> with 'runtime.' (which is the module name I'm using).
As long as you realize the potential maintenance "expense" of this
approach as your code will no longer clearly identify where such
objects came from, versus those actually in the containing modules
namespace. Since you mentioned your reason for separating out the
constants was for code clarity, I would think that would be important.
Personally I don't see it as a problem and it's clearer in the code
where the constants came from. Note that if it's the length of the
name that bothers you, you could import the module using "as r" (2.x)
or just assign "r=runtime" after import (1.5.x), and then use
"r.<constant>" which is hardly more overhead than just "<constant>".
But we could also just agree to disagree on the "handiness" of
referencing an imported object including the module name. It does
help your original issue though since everything would reference the
same object in the loaded constant module.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db3l at fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4