[Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin

Petr Spacek pspacek at redhat.com
Tue Apr 8 08:19:01 UTC 2014


On 8.4.2014 10:14, Jan Cholasta wrote:
> On 8.4.2014 10:09, Alexander Bokovoy wrote:
>> On Tue, 08 Apr 2014, Jan Cholasta wrote:
>>> On 8.4.2014 10:01, Alexander Bokovoy wrote:
>>>> On Tue, 08 Apr 2014, Petr Spacek wrote:
>>>>> On 8.4.2014 09:22, Jan Cholasta wrote:
>>>>>> On 4.4.2014 12:59, Petr Spacek wrote:
>>>>>>> On 3.4.2014 15:35, Jan Cholasta wrote:
>>>>>>>> I would shorten "origin_sign" to just "sign".
>>>>>>> Sign of what? Decay? :-) I don't think that sign is descriptive
>>>>>>> enough,
>>>>>>> I would personally stick with origin_sign.
>>>>>>
>>>>>> Whoops, I meant "origin". The "_sign" bit seems a little bit
>>>>>> redundant to me.
>>>>>
>>>>> "Origin" is an established term for the name of the parent.
>>>>>
>>>>> name = "blabla.example."
>>>>> origin of "name" = "example."
>>>>>
>>>>> Anyway, I still think that DNSName('@') is better than any constant
>>>>> with cryptic name.
>>>>>
>>>>> Honza, can you see any problem with this? I know this creates instance
>>>>> again and again, but is it a real problem? I would like to avoid
>>>>> premature optimization... :-)
>>>> What about making all these fixed names as constants and then simply
>>>> return those?
>>>>
>>>> class DNSName:
>>>>     DNS_ORIGIN = DNSName('@')
>>>>      ...
>>>>
>>>>     @staticmethod ...
>>>>     def ...
>>>>         return DNS_ORIGIN
>>>>
>>>> they would be singletons...
>>>
>>> Unfortunately you can't do that, because at the time DNSName is
>>> parsed, it is not defined yet:
>>>
>>>>>> class X:
>>> ...   x = X()
>>> ...
>>> Traceback (most recent call last):
>>>  File "<stdin>", line 1, in <module>
>>>  File "<stdin>", line 2, in X
>>> NameError: name 'X' is not defined
>> Then we can split these classes: define DNSName with purely static
>> methods as child of DNSNameBase which would have all the expected
>> methods. DNSName can then have constants of DNSNameBase() and return
>> those.
>>
>
> IMO this is an overkill. I would prefer if we did what I suggested earlier:
> put DNSName into a new module dnsutil and make the constants global for the
> module.

I consider this less readable but I'm not Python expert so I'm fine this approach.

Note: The difference between @ and real "origin" is like "pointer to origin" 
and "origin value" in C.

-- 
Petr^2 Spacek




More information about the Freeipa-devel mailing list