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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to