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

[Petr Spacek]

On 8.4.2014 10:49, Jan Cholasta wrote:
> 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.

Okay, use whatever and please add comment # invented by jcholast :-)

-- 
Petr^2 Spacek