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

Martin Basti mbasti at redhat.com
Wed Apr 9 08:23:40 UTC 2014


On Tue, 2014-04-08 at 11:01 +0200, Petr Spacek wrote:
> 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 :-)
> 

I vote for 'empty' as is used in dnspython or 'zone_record' as is used
in FreeIPA dns plugin now

I agree to make global constants in new dnsutil module
-- 
Martin^2 Basti




More information about the Freeipa-devel mailing list