pyexiv2-developers team mailing list archive

[Olivier Tilloy <olivier@xxxxxxxxxx>]

On 2010-02-17, Damien Moore <damienlmoore@xxxxxxxxx> wrote:
> Sorry for all of the questions. As you've probably gathered I'm a
> little clueless about the XMP spec...

Well, I'm not an XMP guru myself, but from the little I know of the 
spec, I'd say it's denser but at least much better designed and more 
consistent than its EXIF and IPTC counterparts.

> > meta[key] always returns a {Exif,Iptc,Xmp}Tag object. That's a bit more code
> > to write for application developers, but that's also much more flexible: a
> > tag object contains more information than just a value.
>
> I understand that evaluating meta[key] (i.e. using __getitem__),
> should return a *Tag object. But...
> (thinking out loud) I'm not sure why meta[key]=value (i.e.
> __setitem__) shouldn't be interpretable as
> meta[key]=*Tag(key,value). For example:
>
> def __setitem__(self,key,value):
>     try:
>         #try setting the key assuming that value is a *Tag type
>     except TypeError:
>         tag_class=lookup_tag_type(key)
>         if value.__class__ != tag_class:
>             value=tag_class(key,value)
>             #try setting again
>
> Is the issue that lookup_tag_type is expensive?

No, it's not particularly expensive. You have a point here, it would be 
pretty handy to allow direct value assignment, and it shouldn't be that 
much work to implement.

> I agree that direct support for this is probably no big deal because I
> can do what I need in helper functions.

That was my initial thought, but if every single application developer 
ends up writing the same monkey helper code, then something in the API 
is missing...

> > should I assume that the user wants
> > to set the value, or the raw_value?
>
> I guess always assume a value because that is how the *Tag __init__
> call works right?

Right, you have another point here :)

> If someone wants to do something more complicated they can use the full idiom.
>
> > if key in meta.xmp_keys:
> >    meta[key].value = value
> > else:
> >    meta[key] = XmpTag(key, value)
>
> I gather this is also true for exif and iptc keys? This is a break
> from dictionary syntax, but I guess it makes sense that the user needs
> to be explicit about adding new keys. (Again, not a big deal, but
> something that wasn't immediately obvious). I guess I don't like the
> redundancy of having to refer to the key twice when adding it (invites
> someone to try: meta[key1]=XmpTag(key2,value)). A simple alternative
> would be:
>
> meta.add(XmpTag(key,value))

That is another possibility, that would be rendered kind of useless if I 
implement direct value assignment.

> btw, setting the value property will update raw_value and vice versa right?

Yes, it will, of course! In fact, the raw value is always set, while the 
value is lazily computed when accessed. Which guarantees that at a low 
level accessing the raw value will always succeed, even if for some 
reason the conversion to a python type fails.

> > > {'x-default': ['test2', 'test3']}
> > > #works as expected
> > Actually, it shouldn't. According to the XMP specification, the type of
> > Xmp.dc.subject is "bag Text", meaning it expects a list of values, not a
> > dictionary (it's not a LangAlt).
>
> So for key=="Xmp.dc.subject" this should work:
> meta[key]=XmpTag(key,['test2','test3'])

Yes it will.

> Please don't interpret these comments/questions as a request to change
> anything. It's just taking a little bit to get my head around the new
> API.

No problem. Again, thanks for your valuable feedback. I'll definitely 
look into implementing direct value assignment within the next few days.

> cheers,
> Damien

Cheers,

Olivier