On 01/17/2013 02:40 PM, Jan Cholasta wrote:
On 17.1.2013 12:46, Petr Viktorin wrote:
On 01/17/2013 09:07 AM, Jan Cholasta wrote:


While this works for dict, I'm not sure if it applies to *all* dict-like
classes that we use.

I don't think we have any classes where it doesn't apply.

Once we completely get rid of entry tuples, we can reintroduce a
dict-like __iter__. IMO new code should not be punished (i.e. forced to
use .keys()) for the crimes (i.e. tuples) of the old code.

Yes, eventually. Though I'd like it to raise an exception for some time,
so any external plugins that rely on it fail rather than get bad data.

OK. But I think external plugins will break either-way, as we don't
really maintain backward compatibility in our internal APIs.


We should decided whether we want to use entry['dn'] or entry.dn and use
only that in new code. I like entry.dn more, as it better corresponds to
the special meaning of dn in entries.

I also like entry.dn, at least in most cases, but if we don't
synchronize them then we need to remove entry['dn'] completely. Having
misleading/stale data in the object isn't good.
There are some cases where entry['dn'] makes sense, such as iterating
over all attributes.
If we're going to have validation for every attribute anyway, I don't
think synchronizing the two would be a major problem. Especially since
entry.dn is already a property.


OK, we will deal with that in further patches.

Updated patch attached.

Honza


ACK. I'll start working on top of this.

--
PetrĀ³

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to