Python binding: ProxyObject questions

[Jeroen T. Vermeulen]

On Fri, August 25, 2006 22:27, John (J5) Palmieri wrote:

>> A cast sounds like a nice trick.  From what I can see so far there's
>> just
>> no way to add Python methods to a proxy that would be guaranteed not to
>> clash with the dbus object's methods...
>
> There is one way.  Put an underscore as the first character i.e.
> _connect.  D-Bus methods need to start with a letter.

The way I read the spec, an underscore *is* allowed as a first character,
just not a digit!

http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names

<<
Member names

Member (i.e. method or signal) names:

 * Must only contain the ASCII characters "[A-Z][a-z][0-9]_" and may not
begin with a digit.

 * Must not contain the '.' (period) character.

 * Must not exceed the maximum name length.

 * Must be at least 1 byte in length.
>>

That's the only restriction I see on method names...


>> I was about to document the basics of the Python API in my new
>> tutorial...
>>  Do you think it would be better to hold off on that?
>
> Documenting them would be a great way for us to make sure we keep
> backwards compat.  We need to do that because we don't want to leave
> projects like OLPC out in the cold.  Plus they will help in the design
> of the new API.

I'd rather keep anything obsolete or confusing out of the tutorial--it's
meant as an introduction for new users, not as a reference for developers
to keep track of old code!

This strikes me as more of a job for a regular test suite.  Documentation
doesn't tell you when you go wrong--at least not without considerable
human initiative, effort, and determination.  Besides, for the very same
reason it's hard enough to keep the documentation itself accurate!

As for OLPC, the $100 laptop isn't even out yet, and lots of work remains
to be done on the software anyway AFAIK.  Wouldn't it be better for them
(being the MIT OLPC team, I guess) at least not to keep using anything
that is obsolescent now?


Jeroen