Strings¶

Triple-quoted strings are always dedented¶

Python's triple-quoted string is exactly the characters between the quotes, indentation included — a multi-line string written inside an indented block carries that indentation as literal content:

def transfer():
    return """
    Move money between two accounts.

    Raises if either account does not exist.
    """

Lucid dedents a triple-quoted string automatically: the smallest leading-whitespace count shared by every line after the first is stripped from all of them, so what the literal reads as — independent of how deeply the surrounding code happens to be nested — is what it means:

def transfer():
    return """
    Move money between two accounts.

    Raises if either account does not exist.
    """

No adjacent string literal concatenation¶

Python concatenates adjacent string literals at compile time. Lucid rejects adjacent string literals. Use an explicit concatenation operation when a string is meant to be joined.

path = "/api/" "users"  # error
path = "/api/" + "users"

Strings are not sequences¶

Python's str satisfies Sequence[str] — isinstance("abc", Sequence) is True — but it does not keep the contract satisfying Sequence is supposed to promise. Sequence.__contains__ means "some element equals this value": x in seq should hold exactly when s[i] == x for some index i. str.__contains__ does substring search instead — "abc" in "abcdef" is True, even though no single index i has s[i] == "abc"; every element of the "sequence" is a one-character string, and "abc" is not one. index and count break the same contract the same way, finding and counting substrings rather than equal elements. str does not even define __reversed__ — reversed("abc") works anyway, but only by falling back to __len__/__getitem__, not because str actually implements the method Sequence advertises.

So a function asking for a sequence or iterable of strings also accepts a single string, and nothing about that is a type error, even though the string doesn't behave like one once inside:

def render_lines(lines: Sequence[str]) -> str:
    return str.join(lines, sep="\n")

render_lines("hello")  # type-checks, returns "h\ne\nl\nl\no"

Lucid keeps str narrower: it is Container[str] and Sized, but not Iterable[str], Collection[str], or Sequence[str]. Strings do not provide __iter__, so the same mistake is a type error instead of a silent, wrong result — and "abc" is Sequence is simply False, closing the gap Python's isinstance("abc", Sequence) leaves open, a result Python's own community has asked for repeatedly, for exactly the contract violations above:

def render_lines(lines: Iterable[str]) -> str:
    return str.join(lines, sep="\n")

render_lines("hello")  # error: str is not Iterable[str]

text: str = "hello"
text[0]    # "h" -- ordinary indexing, no Sequence needed

for ch in text:          # error
    ...

chars: ~Sequence[str] = text.chars
chars[0]
"e" in chars     # true: some element equals "e"
"el" in chars    # false: no element equals "el" -- chars holds one-character str

for ch in text.chars:
    ...

"e" in text     # true: substring search
"el" in text    # true: substring search
len(text)

No % string formatting¶

Python has three generations of string formatting that still coexist: %-formatting, .format(), and f-strings. Lucid keeps one — f-strings — and removes % as a string operator. % stays exactly what it already is for numbers, ordinary modulo; a string on its left side is a type error instead of a second formatting mini-language to learn:

"%s is %d" % (name, age)   # error: % is not a string operator
f"{name} is {age}"

Base-formatted string factories¶

Python's bin, oct, and hex each convert a number to a prefixed string in one base. Lucid moves them onto str itself, as named factories — the same pattern Factory construction already uses for Point.origin() — rather than three unrelated top-level names for one job, "build a str a particular way":

str.bin(255)  # "0b11111111"
str.oct(255)  # "0o377"
str.hex(255)  # "0xff"

join is a named factory, not a method on the separator¶

Python's ",".join(items) calls join on the separator — the smallest, least interesting part of the operation — with the thing actually being joined arriving as the argument, backwards from how the operation reads: "join these items with this separator" becomes "ask this separator to join these items." Lucid keeps join where every other "build a str a particular way" operation already lives, a named factory on str itself, with the pieces being joined as the primary argument and the separator named instead of implied by which object happens to own the method:

str.join(["a", "b", "c"], sep=",")  # "a,b,c"

Collections covers the container types built from values like these — sets, dicts, and records.