homepage

> I’d say that urlparse should raise an exception when a ws/wss URI contains a fragment part.
Yep, better.
> I’m not sure this will be possible; from a glance at the source and a quick test, urlparse will happily break the Generic URI Syntax RFC and return a path including a # character!
That's unfortunate.
In that case I'd probably prefer the lesser evil, namely that urlparse be set up (falsely) such that ws/wss scheme would falsely allow fragments, so I get back the non-empty fragment as a separate component, and check myself.
If urlparse returns the fragment (falsely) within path, then a user could check only by searching for # in the path. Also hacky .. even worse than compare fragment for != "". 
Essentially, this would be exactly "the hack" that I posted in my very first comment:
urlparse.uses_fragment.extend(wsschemes)
===
Alternative: make this bug dependent on fixing urlparse for fragment rules in generic URI RFC and don't do anything until then?