[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