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

Jan Cholasta jcholast at redhat.com
Tue Apr 8 08:49:14 UTC 2014


On 8.4.2014 10:31, Petr Spacek wrote:
> On 8.4.2014 10:29, Jan Cholasta wrote:
>> On 8.4.2014 10:19, Petr Spacek wrote:
>>> 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.
>>
>> Well, it's the same thing python-dns does: dns.name.Name,
>> dns.name.root, ...
>>
>>>
>>> Note: The difference between @ and real "origin" is like "pointer to
>>> origin" and "origin value" in C.
>>>
>>
>> I think a good name would be "self", but that doesn't work very well
>> in Python
>> :-) Perhaps "self_origin" is better?
>
> I'm not big fan of SELF :-)
>
> What is wrong with origin_sign? It seems more understandable than
> self_origin to me.
>

The word "sign" does not really capture the meaning of it. It is a sign 
as long as you look at it in text form, but it has a specific meaning 
and IMO we should capture that meaning in the name rather than what it 
looks like in text.

The constant is named "empty" in python-dns, IMO we should name it the same.

-- 
Jan Cholasta




More information about the Freeipa-devel mailing list