Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Multiple ways to access attributes (http://www.velocityreviews.com/forums/t957484-multiple-ways-to-access-attributes.html)

ISE Development 02-10-2013 10:44 PM

Multiple ways to access attributes
 
Is it considered acceptable practice (e.g. not confusing, not
surprising or not Pythonic) to allow multiple ways to access
the same attributes?

For example, supposing I am providing access to external
devices, that these parameters may vary slightly between
devices (e.g. different models, etc...) and that the device
may be queried for parameter meta-data (such as name, data
type, data value constraints), would the following API be
acceptable (in the sense alluded to above)? Or would it be
generally considered a distortion of Python idealogy (e.g.
like PERL's 'more than one way to do it' approach)?

class option
-> represents a single option
-> two attributes: info (the parameter meta-data)
value (the parameter getsetter)

class options:
-> represents the device parameter interface
-> provides the following API:

iter(options)
-> iterable through all parameter meta-data

options[0]
-> access parameter 0 meta-data
-> key is integer

options['foo']
-> access parameter 'foo' (returns an 'option' object)
-> key is basestring
-> useful when processing the parameters generically

options.foo
-> same as options['foo']
-> useful for well-known, often used parameters
(really just short-hand for the user)

options.keys()
-> iterator through option names (a specific meta-data
field)

options.values()
-> iterator through option values

options.items()
-> iterator through (name,value) tuples


-- isedev

Mitya Sirenef 02-10-2013 11:23 PM

Re: Multiple ways to access attributes
 
On 02/10/2013 05:44 PM, ISE Development wrote:
> Is it considered acceptable practice (e.g. not confusing, not
> surprising or not Pythonic) to allow multiple ways to access
> the same attributes?
>
> For example, supposing I am providing access to external
> devices, that these parameters may vary slightly between
> devices (e.g. different models, etc...) and that the device
> may be queried for parameter meta-data (such as name, data
> type, data value constraints), would the following API be
> acceptable (in the sense alluded to above)? Or would it be
> generally considered a distortion of Python idealogy (e.g.
> like PERL's 'more than one way to do it' approach)?



There should be one-- and preferably only one --obvious way to do it.

The reason for this guideline is that if there were many similar ways to
do the same thing (in the language itself), without one way standing out
as an obvious, idiomatic choice, you would end up with every program
using its own approach and it would be much harder to read and
understand other people's programs. If there's one obvious, preferred
way, you can look at code from hundreds of people and you will know
immediately what they are doing and why.

This does not apply to your case. You are already creating a custom
interface for working with options.

Does your approach make the code more readable and easier to work with?
If yes, this is perfectly fine.

[snip]

-m


--
Lark's Tongue Guide to Python: http://lightbird.net/larks/

Many possessions, if they do not make a man better, are at least expected
to make his children happier; and this pathetic hope is behind many
exertions. George Santayana


MRAB 02-10-2013 11:23 PM

Re: Multiple ways to access attributes
 
On 2013-02-10 22:44, ISE Development wrote:
> Is it considered acceptable practice (e.g. not confusing, not
> surprising or not Pythonic) to allow multiple ways to access
> the same attributes?
>
> For example, supposing I am providing access to external
> devices, that these parameters may vary slightly between
> devices (e.g. different models, etc...) and that the device
> may be queried for parameter meta-data (such as name, data
> type, data value constraints), would the following API be
> acceptable (in the sense alluded to above)? Or would it be
> generally considered a distortion of Python idealogy (e.g.
> like PERL's 'more than one way to do it' approach)?
>
> class option
> -> represents a single option
> -> two attributes: info (the parameter meta-data)
> value (the parameter getsetter)
>
> class options:
> -> represents the device parameter interface
> -> provides the following API:
>
> iter(options)
> -> iterable through all parameter meta-data
>
> options[0]
> -> access parameter 0 meta-data
> -> key is integer
>
> options['foo']
> -> access parameter 'foo' (returns an 'option' object)
> -> key is basestring
> -> useful when processing the parameters generically
>
> options.foo
> -> same as options['foo']
> -> useful for well-known, often used parameters
> (really just short-hand for the user)
>
> options.keys()
> -> iterator through option names (a specific meta-data
> field)
>
> options.values()
> -> iterator through option values
>
> options.items()
> -> iterator through (name,value) tuples
>

These features make it look like a dict: options['foo'],
options.keys(), options.values(), options.items(). OK so far.

What does iter(options) yield? If the class looks like a dict, it
should probably behave like a dict, yielding the keys.

I'm not sure about options[0]. Would that be the same as
list(options.values())[0]? A dict would treat that in the same way as
options['foo'] i.e. the 0 is a key. -1 for that.

options.foo is a 'magic' attribute; it may or may not exist. -1 for
that.



All times are GMT. The time now is 05:01 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.