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

[Jan Cholasta]

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?

-- 
Jan Cholasta