[issue22852] urllib.parse wrongly strips empty #fragment
Demian Brecht
report at bugs.python.org
Mon Mar 16 17:40:00 CET 2015
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 <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________
More information about the Python-bugs-list
mailing list