
On 10/01/2023 01.19, James Addison wrote:
On Sun, 8 Jan 2023 at 20:20, dn <PythonList@danceswithmice.info> wrote:
Herewith a repetition of an earlier repetition of a call for Python examples and use-cases. (to better justify the base-idea, which I support)
(and hence earlier illustration/question: does the sep belong with the string forming the left-side of that partition, or the 'right'?)
There's no connection implied between each separator and the partitions that surround it in the results.
Yet, it is important to justify the proposed "idea" with a full-consideration - not just how an enhanced partition() might work, but how its inputs and outputs might be used, constructed, deconstructed, etc. Consider the power of Python's indexing of collections, extended into slicing. Then, the further expansion into itertools' islice(), pairwise(), and groupby(). (etc) Why? Why not?
In the username/host case, the '@' in 'user@host' isn't instrinsically linked to either the username or hostname component.
Again: the example is weak - not because it fails to make the point, but because existing tools satisfy that need. To progress to a PEP, more and better examples will help promote the case!
(another way to think of it is like a meal-break during a work-day; the meal-break doesn't belong to either the part of the day preceding or the part of the day after the break)
Acceding to my own request for 'Python', please consider: if test1: «A compound statement consists of one or more ‘clauses.’ A clause consists of a header and a ‘suite.’ The clause headers of a particular compound statement are all at the same indentation level. Each clause header begins with a uniquely identifying keyword and ends with a colon.» Thus, the colon relates to the preceding code. NB I was going to mention multiple statements on a physical line, eg: print(x); print(y); print(z) However, there's been a flurry of argument about whether the semi-colon separator begins, ends, or has nothing to do with the expression on either side. Thus, use-cases with different interests... To continue down that 'rabbit hole': if x < y < z: print(x); print(y); print(z) «Also note that the semicolon binds tighter than the colon in this context, so that in the following example, either all or none of the print() calls are executed:» Am not wanting to know the answer, or even to provoke a debate, simply to illustrate that there are multiple ways of looking at things (and thus use-cases) - what binds to what, or binds what to what? - and is the answer different when looking at language syntax compared with a programmer's view more concerned with semantics? Again: am only provoking the OP's thinking towards progressing the "idea"! Web.Ref: https://docs.python.org/3/reference/compound_stmts.html
Why limit the implementation to the same sequence as the separators are expressed in the method-call?
ie why should the order in which the separator arguments were expressed necessarily imply the same order-of-appearance in the subject-string?
There are two reasons for this, one consumer-side and one implementation-side:
1. It discourages consumers from attempting to partition strings with ambiguously-ordered delimiters
(python or pseudo-python) examples? Consider also: "we're all adults here", "with great power comes...", etc What is an "ambiguous order"? What is (logically) wrong with the concept of allowing the coder to break on any and all: colons, question-marks, and/or hash-characters (pound-signs) - regardless of their order of appearance, or repetition, in the subject-string? (I am asking this question!)
1. It allows the arguments to be scanned (iterated) exactly-once while the input is scanned (also iterated) exactly-once
True, but why make that a limit? Might loosening such increase the facility - and the number of use-cases? Consider str.translate( table ) which must iterate in combinatoric-fashion. Consider also float(), split(), strip(), (etc) and the definition of "ASCII whitespace". (doubt any need to say this, but to convince the 'Python-Gods' (and the Python-Community) that this idea has merit, the more use-cases which support the proposal, the more ears that will listen...) -- Regards, =dn