Demian Brecht added the comment:
I've done an initial pass in Rietveld and left some comments, mostly around
docs. Here are some additional questions though:
Given has_* flags can be inferred during instantiation of *Result classes, is
there a reason to have them writable, meaning is there a reason to add them to
the __init__ methods?
I'd also like to see this logic moved out of _NetlocResultMixinBase. I'm
assuming it was put there for backwards compatibility which is understandable,
but I don't think it makes sense to add such logic to a mixin who's purpose is
additional functionality around the netloc attribute. This one's a little more
subjective though, but here's a rough idea of what I'm thinking:
SplitResult = namedtuple('SplitResult', 'scheme netloc path query fragment')
class _SplitResultBase(SplitResult):
def __new__(cls, scheme, netloc, path, query, fragment):
inst = super().__new__(cls, scheme, netloc, path, query, fragment)
inst.has_netloc = bool(netloc)
return inst
>>> s = urlsplit('http://example.com/foo/bar/')
>>> s.has_netloc
True
This keeps backwards compatibility, but also adds the additional logic to the
bases rather than in the mixins. I might also split out the logic into helper
functions in order to avoid duplication between _SplitResultBase and
_ParseResultBase.
This method also avoids the dependency on ordering of base classes as well as
the addition of a variadic signature to (Split|Parse)Result.__init__.
Thoughts?
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue22852>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
