[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