Adding a field to a 'foreign' object from the outside

[atleta]

Hi,

I'm working with a callback API (a DBus one) and I'd need to store
some state between the calls somewhere. I know that it's possible to
extend an object with fields after creation, so I could just store my
data in the session object that is passed in with every callback.
However it stinks from OO perspective, at least to me. The other
option, something that I'd do in java for example, would be to set up
a mapping (a dict) using the session object as a key. Which one is the
'pythonic' way? Do you use the first method (modifying an object that
you don't even control the source of) or do you write a bit more code
and go with the second one?

Thanks,
Laszlo

 

[James Mills]

I'm working with a callback API (a DBus one) and I'd need to store
some state between the calls somewhere. I know that it's possible to
extend an object with fields after creation, so I could just store my
data in the session object that is passed in with every callback.
However it stinks from OO perspective, at least to me. The other
option, something that I'd do in java for example, would be to set up
a mapping (a dict) using the session object as a key. Which one is the
'pythonic' way? Do you use the first method (modifying an object that
you don't even control the source of) or do you write a bit more code
and go with the second one?

The more elegant approach is your 2nd one.
A wrapper object that hold the extra data and functionality
you require while maintaining the APIs needs.

Tacking things on is a bit hackish (but nonetheless probably works).

--JamesMills

 

[Diez B. Roggisch]

Hi,

I'm working with a callback API (a DBus one) and I'd need to store
some state between the calls somewhere. I know that it's possible to
extend an object with fields after creation, so I could just store my
data in the session object that is passed in with every callback.
However it stinks from OO perspective, at least to me. The other
option, something that I'd do in java for example, would be to set up
a mapping (a dict) using the session object as a key. Which one is the
'pythonic' way? Do you use the first method (modifying an object that
you don't even control the source of) or do you write a bit more code
and go with the second one?

For me, the first one. Creatin a mapping is cumbersome, opens up all
kinds of questions like "how to remove stale entries" and is a level of
indirection that one has to be aware of.

The session object is obviously intended to be that - a storage for
information persistent over the course of the actions working with it.
So - use it.

Python is dynamic. Use that dynamicity. The java & C++-guys would do it
- if they could.

Diez

 

[Bruno Desthuilliers]

atleta a écrit :

Hi,

I'm working with a callback API (a DBus one) and I'd need to store
some state between the calls somewhere. I know that it's possible to
extend an object with fields after creation, so I could just store my
data in the session object that is passed in with every callback.
However it stinks from OO perspective,

Why so ? And what does your API documentation says about this session
object?

at least to me. The other
option, something that I'd do in java for example, would be to set up
a mapping (a dict) using the session object as a key.

Is this object _safely_ usable as a key somehow ? And if yes, do you
have a way to deal with stale sessions ?

Which one is the
'pythonic' way?

The simplest. But as far as I'm concerned, I don't have enough context
to say which one it would be here.

Do you use the first method (modifying an object that
you don't even control the source of) or do you write a bit more code
and go with the second one?

Depends - cf above. But as a guideline, unless the library provides a
defined way to solve this problem or the library documentation clearly
states I should *not* store my own data in the session object (but then
what's the point of a session object ???), I'd just use it.

 

[Steve Holden]

Hi,

I'm working with a callback API (a DBus one) and I'd need to store
some state between the calls somewhere. I know that it's possible to
extend an object with fields after creation, so I could just store my
data in the session object that is passed in with every callback.
However it stinks from OO perspective, at least to me. The other
option, something that I'd do in java for example, would be to set up
a mapping (a dict) using the session object as a key. Which one is the
'pythonic' way? Do you use the first method (modifying an object that
you don't even control the source of) or do you write a bit more code
and go with the second one?

Or there's a third option. Write a class that implements a __call__()
method, and use an instance of that class as your callback. Then the
data can be stored as the callback object's private instance data.

regards
Steve