On Wed, 2008-02-06 at 10:51 +0100, Jaroslav Kysela wrote:
On Thu, 31 Jan 2008, Aldrin Martoq wrote:
While developing pyalsa sequencer API, I found that sometimes 0 is used instead of a #defined value or constant. In my opinion, given that the alsa API is opaque (hides internal structure and provides methods for accessing them), we should define those missing "constants" for being consistent. So far I found: SND_SEQ_BLOCK 0 (blocking mode) SND_SEQ_PORT_CAP_NONE (the port defines no access capabilites)
Note that SND_SEQ_NONBLOCK is flag (bitmask). Also SND_SEQ_PORT_CAP_* defines are bitmasks. I don't see usage to have defined for 0 because it always mean "off state" rather than a direct value. Correct tests are: val&SND_SEQ_NONBLOCK - nonblocking behaviour (val&SND_SEQ_NONBLOCK)==0 - blocking behaviour
Yup, I was sorry for my mistake; I'm fixing (removing) this in my current python binding.
I think my mistake originated because there is no snd_seq_set_mode function API. The snd_seq_nonblock method is inconsistent with the flag behaivor. So, I'm sticking with changing the mode of a Sequencer instance through Sequencer.mode attribute.
Regarding python. I think that we need to settle naming scheme. I just moved my code to follow standard python rules (only class names have upper letters and constants).
Yeah, I think we should follow current python PEP's: a) Naming conventions http://www.python.org/dev/peps/pep-0008/ b) Doc strings http://www.python.org/dev/peps/pep-0257/
a) Says basically: - Class names are CapsWords; like in SeqEvent or SequencerError. - method names are lowercase and _ separated, like in get_mixer_controls(). - members of classes lowercase and _ separated. - There are no strict rules, so this are recommended practices. Sometimes, some modules follow other rules (ex: st_mode).
However, I couldn't find anything regarding constant naming in PEPs. I suggest: - keeping names all uppercase and _ separated. Must follow or imitate original C naming; like in SND_SEQ_NONBLOCK. - I'm not sure if keeping constants "inside" the module or make them exportable ("from alsaseq import *"). In the first way, we may follow python-gtk naming scheme (ex: gtk.gdk.AXIS_IGNORE); in the second way, we may stick to something like alsaseq.SND_SEQ_NONBLOCK or alsaseq.SEQ_NONBLOCK.
http://www.pygtk.org/docs/pygtk/gdk-constants.html
Jaroslav, What do you prefer?
I also chose a different organization for constants in my code to have possibility to enumerate all related bitmasks or numbers using dictionaries. See my python modules. It meas to define SEQ_ADDRESS_* like: seq_address = {'BROADCAST': 0xff, 'SUBSCRIBERS': 0xfe, 'UNKNOWN': 0xfd} open_mode = {'NONBLOCK': 1} etc...
I like your idea, and I'm thinking to change to that.
I first created the Constant class to force use them instead of an integer... The method was, raise a Warning error if the user didn't provide a Constant instance for some argument. That's why I implemented the NumProtocol for Constant: it returns a Constant for a bitwise between Constants... Then I realised this was too much strict type checking (like java) and not the python way, so I'm thinking of removing the numeric protocol for Constant. Note that the current code doesn't throw any warning.
However, I think a Constant class is useful, if you call __repr__ or __str__ to an instance it will return the name instead of looking through a dictionary.
Thanks for all your help, I'm still working for completing the full sequencer API. I'll be done/happy if a cover 80% of it: I've realized that open_lconf will need a new python binding for the Configuration API.