Hello, On Wed, 1 Apr 2020 10:01:06 +0100 Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 1 Apr 2020 at 02:07, Steven D'Aprano <steve@pearwood.info> wrote:
Paul has not suggested making StringIO look and feel like a string. Nobody is going to add 45+ string methods to StringIO. This is a minimal extension to the StringIO class which will allow people to improve their string building code with a minimal change.
Thanks for paring the proposal down to its bare bones, there's a lot of side questions being discussed here that are confusing things for me.
With this in mind, and looking at the bare proposal, my immediate thought is who's going to use this new approach:
[]
I hope this isn't going to trigger another digression, but it seems to me that the answer is "nobody, unless they are taught about it, or work it out for themselves[1]".
Roughly speaking, the answer would be about the same in idea as answers to the following questions: * Who'd be using assignment expressions? (2nd way to do assignment, whoa!) * Who'd be using f-strings? (3rd (or more) way to do string formatting, bhoa!) * Who'd be writing s = s.removeprefix("foo") instead of "if s.startswith("foo"): s = s[3:]" (PEP616)? * Who'd be using binary operator @ ? * Who'd be using using unary operator + ?
My reasons for saying this are that it adds no value over the current idiom of building a list then using join(), so people who already write efficient code won't need to change. The people who *might* change to this are people currently writing
buf = '' # repeated many times buf += 'substring'
Those people have presumably not yet learned about the (language independent) performance implication of repeated concatenation of immutable strings[2].
Ok, so we found the answers to all those questions - people who might have a need to use, would use it. You definitely may argue of how many people (in absolute and relative figures) would use it. Let the binary operator @ and unary operator + be your aides in this task.
At the moment, the message is relatively clear - "build a list and join it" (it's very rare that anyone suggests StringIO currently).
I don't know how much you mix with other Pythonistas, but word "clear" is an exaggeration. From those who don't like it, the usual word is "ugly", though I've seen more vivid epithets, like "repulsive": https://mail.python.org/pipermail/python-list/2006-January/403480.html More cool-headed guys like me just call it "complete wastage of memory".
This proposal is presumably intended to make "use StringIO and +=" a more attractive alternative alternative proposal (because it avoids the need to rewrite all those += lines).
Aye.
So we now find ourselves in the position of having *two* "recommended approaches" to addressing the performance issue with string concatenation.
The scholasm of "there's only one way to do it" is getting old for this language. Have you already finished explaining everyone why we needed assignment expressions, and why Python originally had % as a formatting operator, and some people swear to keep not needing anything else? What's worse, is that "there's only one way to do it" gets routinely misinterpreted as "One True Way (tm)". And where Python is deficient to other languages, there's rising small-scale exceptionalism along the lines "we don't have it, and - we don't need it!". The issue is that some (many) Python programmers use a lot of different languages, and treat Python first of all as a generic programming language, not as a bag of tricks of a particular implementation. And of course, there never will be agreement between the one-true-way-tm vs nice-generic-languages factions of the community.
I'd contend that there's a benefit in having a single well-known idiom for fixing this issue when beginners hit it. Clarity of teaching, and less confusion for people who are learning that they need to address an issue that they weren't previously aware of.
Another acute and beaten topic in the community. Python is a melting pot for diverse masses - beginners, greybeards, data scientists, scripting kiddies, PhD, web programmers, etc. That's one of the greatest achievements of Python, but also one of the pain points. I wonder how many people escaped from Python to just not be haunted by that "beginners" chanting. Python is beginners-friendly language, period, can't change that. Please don't bend it to be beginner-only. Please let people learn computer science inside Python, not learn bag of tricks to then escape in awe and make up haikus along the lines of: A language, originally for kids, Now for grown-up noobs. (Actual haiku seen on Reddit, sorry, can't find a link now, reproduced from memory, the original might have sounded better). [] -- Best regards, Paul mailto:pmiscml@gmail.com