John Dennis wrote:
On 07/27/2011 01:52 PM, Rob Crittenden wrote:
John Dennis wrote:
Replace deepcopy with constructor (i.e. type call)
Can now "clone" with configuration changes by passing object
of the same type to it's constructor, e.g.
dn1 = DN(('cn', 'foo')
dn2 = DN(dn1)
dn2 = DN(dn1, first_key_match=False)

Remove pairwise grouping for RDN's. Had previously removed it
for DN's, left it in for RDN's because it seemed to make sense
because of the way RDN's work but consistency is a higher goal.

Add keyword constructor parameters to pass configuration options.

Make first_key_match a configuration keyword.

Updated documentation.

Updated unit test.

FWIW, I noticed the unittest is now running 2x faster, not sure why,
removal of deepcopy? Anyway, hard to argue with performance doubling.

The constructor for RDN changed. It now requires tuples, is this the
pairwise grouping you mention in the commit message?

I played around with creating a variety of DNs, RDNs and AVAs and
everything seems to work as expected, so a qualified ack. I'm just
curious why RDNs require tuples.

I changed it for API consistency. RDN's can be multi-valued (but almost
never are). So the way the constructor was originally written was to
just to accept 2 args, e.g. RDN(attr, value), if the RDN was
multi-valued you would pass 4 args (2 pairs), e.g. RDN(attr1, value1,
attr2, value2). This was exactly how the DN constructor used to work (in
fact the DN constructor was originally based on the RDN constructor).
But as you discovered the behavior was confusing and we changed the DN
constructor to require tuples (or lists). When I changed the DN
constructor I left the RDN constructor with the old previous form
because it's seldom called with an arg list like the confusing DN arg
list. But in hind sight I felt it was better to have consistent API's
with the constructors, that ultimately it was less confusing.

OK, pushed to master and ipa-2-0

I added a missing paren to the end of one of the examples in the commit message. Feeling pedantic this morning.


Freeipa-devel mailing list

Reply via email to