-1 on "cut*" (feels too much like what .partition() does) -0 on "trim*" (this is the name used in .NET instead of "strip", so I foresee new confusion) +1 on "remove*" (because this is exactly what it does)
I'm also most strongly in favor of "remove*" (out of the above options). I'm opposed to cut*, mainly because it's too ambiguous in comparison to other options such as "remove*" and "replace*", which would do a much better job of explaining the operation performed. Without the .NET conflict, I would normally be +1 on "trim*" as well; with it in mind though, I'd lower it down to +0. Personally, I don't consider a conflict in a different ecosystem enough to lower it down to -0, but it still has some influence on my preference. So far, the consensus seems to be in favor of "remove*" with several +1s and no arguments against it (as far as I can tell), whereas the other options have been rather controversial. On Tue, Mar 24, 2020 at 3:38 PM Steve Dower <steve.dower@python.org> wrote:
-1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with
+1 on "remove*" for the same reasons as "trim*".
And if no consensus is reached in this thread for a name I would assume
On 24Mar2020 1849, Brett Cannon wrote: preexisting methods. the SC is going to ultimately decide on the name if the PEP is accepted as the burden of being known as "the person who chose _those_ method names on str" is more than any one person should have bear. ;)
-1 on "cut*" (feels too much like what .partition() does) -0 on "trim*" (this is the name used in .NET instead of "strip", so I foresee new confusion) +1 on "remove*" (because this is exactly what it does)
Cheers, Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KVU75BNX... Code of Conduct: http://python.org/psf/codeofconduct/