To me this is really surprising that 28 years old language has some weird methods like str.swapcase(), but none to cut string from left or right, and two of them which exist only accept string mask.
On март 30 2019, at 12:21 дня, Paul Moore <p.f.mo...@gmail.com> wrote: > On Fri, 29 Mar 2019 at 23:07, Christopher Barker <python...@gmail.com> wrote: > > The proposal at hand is to add two fairly straightforward methods to > > string. So: > > > Some of what you are calling digressions are actually questioning the > design choice behind that proposal. Specifically, there's no > particular justification given for making these methods rather than > standalone functions. But OK, let's stick to the points you want to > make here. > > > > > We are balancing equities here. We have a plethora of changes, on the > > > one side taken by itself each of which is an improvement, but on the > > > other taken as a group they greatly increase the difficulty of > > > learning to read Python programs fluently. > > > > > > Unless the methods are really poorly named, then this will make them maybe > > a tiny bit more readable, not less. But tiny. So “irrelevant” may be > > appropriate here. > And how do we decide if they are poorly named, given that it's *very* > hard to get real-world usage experience for a core Python change > before it's released (essentially no-one uses pre-releases for > anything other than testing that the release doesn't break their > code). > > Note that the proposed name (trim) is IMO "poorly named", because a > number of languages in my experience use that name for what Python > calls "strip", so there would be continual confusion (for me at least) > over which name meant which behaviour... > > > > So we set a bar that the > > > change must clear, and the ability of the change to clear it depends > > > on the balance of equities. > > > > > > Exactly — small impact, low bar. > If we accept your statement that it's a small impact. I contend that > the confusion that this would cause between strip and trim is not > small. It's not *huge*, but it's not small... We can agree to differ, > but if we do then don't expect me to agree to your statement that the > bar can be low, you need to persuade me to agree that the impact is > low if you want me to agree on the matter of the bar. > > > > In this case, where it requires C support and is not possible to "from > > > __future__", the fact that library maintainers can't use it until they > > > drop support for past versions of Python weakens the argument for the > > > change by excluding important bodies of code from using it. > > > > > > But there is no need for __future__ — it’s not a breaking change. It could > > be back ported to any version we want. Same as a __future__ import. > OTOH, it's a new feature, so it won't be acceptable for backporting. > Sorry, but those are the rules. What "we" want isn't relevant here, > unless the "we" in question is the Python core devs, and the core devs > have established the "no backports of new features" rule over many > years, and won't be likely to change it for something that you > yourself are describing as "small impact". > > Paul > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
