-
-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
str method argument escaping is inconsistent #401
Comments
Should escape argument (already does):
Unclear, leaning towards should not escape, currently does not:
Unclear, leaning towards should not escape, currently does:
Only wrap result:
|
Despite the long list, the actual change isn't very big, only 8 methods need to be changed to not escape their argument. They're all conceptually similar to the the search methods such as |
Oops, ended up pushing to main instead of a PR branch by mistake. So this is in ef4a839, which also happens to be the 666th commit. |
Prior to #400, some
str
methods were overridden using a generic wrapper that calledescape
on all argument values that werestr
, then wrapped the result inMarkup
. This made typing difficult, and was inefficient. When removing the wrapper, I noticed it was only applied tostr
methods that returnedstr
, not other method that tookstr
arguments. I also noticed that some arguments shouldn't haveescape
called on them even though they arestr
.There are some methods where the escaping makes sense. For example,
str.center
is similar to adding strings, which should escape the values.But there are many other places where the escaping is inconsistent or not obvious. For example,
__contains__
(andfind
,index
, etc.) is not overridden, butstrip
is, so you can get the following behavior.strip
callsescape
on its argument, resulting in the actual call beingstr.strip(s, "<")
. That's definitely not correct, becausestrip
removes any number of each character, in any order, but then intention was obviously to remove the<
.Python 3.9 added
removeprefix
andremovesuffix
, which remove the exact string of characters if it is present. But it's not clear if those should escape their argument, shouldremoveprefix("<")
remove the literal<
, or<
?All methods should at least be consistent. Regardless of which direction we choose, escaping or not, the user can always wrap the argument in
Markup
orescape
to get the other meaning.The text was updated successfully, but these errors were encountered: