Multiple ways to access attributes

[ISE Development]

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]

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]

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.