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

[Petr Spacek]

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.

-- 
Petr^2 Spacek