Our recent exciting foray into making handling of + more correct (#129) had some exciting consequences for our codebase at work, but in ways that were surprisingly hard to detect. I found lots of code that other folks had written using selective string replacements and urllib.parse to work around URL's behavior in various places, since more often than not what people want to use hyperlink for is to take an application-level value and send it to another application via encoding in a URL segment or query parameter value, and DecodedURL is not very discoverable unless you're starting with the docs rather than reading any existing code or exploring the library interactively.
I think that it would make sense to move to a naming structure and documentation that reflects that DecodedURL is what you want by default, although the tools available in EncodedURL are valuable and necessary to achieve specific effects sometimes.
I propose that hyperlink.Link would work best for this high-level naming.
Our recent exciting foray into making handling of + more correct (#129) had some exciting consequences for our codebase at work, but in ways that were surprisingly hard to detect. I found lots of code that other folks had written using selective string replacements and
urllib.parseto work aroundURL's behavior in various places, since more often than not what people want to usehyperlinkfor is to take an application-level value and send it to another application via encoding in a URL segment or query parameter value, andDecodedURLis not very discoverable unless you're starting with the docs rather than reading any existing code or exploring the library interactively.I think that it would make sense to move to a naming structure and documentation that reflects that
DecodedURLis what you want by default, although the tools available inEncodedURLare valuable and necessary to achieve specific effects sometimes.I propose that
hyperlink.Linkwould work best for this high-level naming.