> pattern matching expressions,

nothing intrinsically 'functional' about this, though it's nice

> syntax for partial application

<https://docs.python.org/3/library/functools.html#functools.p...>

> and composition,

Hmm, to my surprise I can't find this but TBH it's trivial to write, here's an eg <https://stackoverflow.com/questions/16739290/composing-funct...>

> a typing system which can express structural types,

typing is orthogonal to FP (though very nice to have)

> a generalised list comprehension

IDK what this means, what's ungeneral about comprehensions currently?

expressing generic data transformations naturally in syntax, requires: being able to wrap/unwrap data types (ie., pattern matching), composing operations, partially applying them, and providing syntax to support filter/map/flatMap on arbitrary data structures

Pythons failure to provide this, indeed, outright hostility to doing so is half the reason pandas is a mess of incomprehensible syntax

By prioritising assignment expressions and implementing pattern "matching" as a statement, they're clearly showing a lot of hostility to one of the major use cases of their language

(incidentally, recall that C# introduced LINQ in 2008, a generalised comprehension! That's C#.)

There isnt the syntax to reimplement to support natural phrasings of data transformation, in lieu of this, pandas exploits weird operators such as `.loc[a,b]`.

At some point the dam is going to have to break, and python is going to have to introduce something to resolve this mess. However, i'd bet it'll be a decade of tooth-and-nail fighting about it. It isnt a software engineering language for education any more, and i'm not seeing this reality being acknowledged

> pattern matching expressions

Available in 3.10: https://peps.python.org/pep-0636/

> syntax for partial application...

    from functools import partial

    somefunc_arg1_arg2 = partial(somefunc, arg1, arg2)

> ...and composition

A native compositional syntax would be nice.

> a typing system which can express structural types

    # mypy will typecheck this code and see `MyString()` has a `.read()` method, so it's a `Readable` even though it doesn't sub-class `Readable`

    from typing import Any, Protocol

    class Readable(Protocol):
        def read(self) -> Any: ...

    def read_something(something: Readable) -> Any:
        return something.read()

    class MyString:
        a_string: str = "something"
        def read(self) -> str:
            return self.a_string

    read_something(MyString())

> a generalised list comprehension

I agree this would be nice.

they arent expressions, defeating the whole point

that isnt syntax for partial appication, and the protocol system for structrural typing is syntactically and practically absurd

the question is "why do data processing libs in python look syntactically illegible" and the answer is largely, as youve posted above, that python doesnt support useful syntax

Pattern matching is supported in 3.10 and can match classes structurally, as well as other types (edit: I see that you mean you don't like that it's a statement, which I agree with). The typing system supports structural types with Protocol. Personally what I miss most are multi-line lambdas.

I'm not asking for "support" i'm asking for syntax. The question is why the syntax of data processing in python is illegible, not "are things technically possible in python".

Commenters here are keen to say "but dont you know!" -- and, yes, I do.

To be fair the confusion of FP vs FP syntax is from your comment: "Perhaps if python would add more support for FP (rather than its present hostility)"

Python does FP fine and FP via an ugly library or via elegant inbuilt syntax is still FP. I get you want nicer syntax but it wasn't clear.

I dunno, write a PEP and see if it gets support. I hope you succeed!