On Sun, May 24, 2020 at 1:42 PM Bernardo Sulzbach < bernardo@bernardosulzbach.com> wrote:

"Serhiy and Remi objected, because it might not be obvious that the length of the path would be the length of string." I find this _really_ unintuitive. If anything, I would expect len(p) to be the "depth" of the path, which doesn't make a lot of sense if it is not an absolute path.

I agree. I expect iteration, indexing, and length to refer to parts, not characters. In particular I'm a bit disappointed that `path[-1]` isn't equal to `path.name`, especially because finding `path.name` was tricky - at first I guessed path.basename (doesn't exist) and path.stem (close, but wrong). Can we implement that instead?

Hello, On Sun, 24 May 2020 08:38:22 -0300 Bernardo Sulzbach <bernardo@bernardosulzbach.com> wrote:

"So I implemented `PurePath.__len__` as `str(len(path))`." Sure you meant len(str(path)), right?

"Serhiy and Remi objected, because it might not be obvious that the length of the path would be the length of string." I find this _really_ unintuitive. If anything, I would expect len(p) to be the "depth" of the path, which doesn't make a lot of sense if it is not an absolute path.

Rather, number of components in a path. E.g. length of Path("../a") is 2.

It is a -1 from me because, besides what I outlined above, if you need the length of the string representation, len(str(p)) is quite short and obvious already.

I fully agree. For people who find string representation of paths to be nice, there's an obvious choice of not using pathlib in the first place, no confusion ensues. And people who choose to use pathlib, should not look for ways to cheat by conflating strings and Path objects with confusing implicit conversions (which will bite people who will need to work with such a code later). -- Best regards, Paul mailto:pmiscml@gmail.com

On 24May2020 13:46, M.-A. Lemburg <mal@egenix.com> wrote:

It would be surprising to have an object which implements .__len__(), but otherwise doesn't allow any indexing, so -1 on such a change.

set() ? I personally don't have a fundamental problem with something having a size but no indexing.

If Paths ever get indexing, it would also be more natural to have those indexes refer to path components.

Aye, I think the same.

The .__len__() would have to map to the number of path components, not the length of a string representation.

Yes, it would be confusing for len() to measure something different to that measured by a numeric index. I think this makes me -1 on the proposal, also because str(Path) is so easy to do. Cheers, Cameron Simpson <cs@cskk.id.au>

On Sun, May 24, 2020 at 1:58 PM Ram Rachum <ram@rachum.com> wrote:

Well, looks like this proposal is dead in the water. Thanks for your opinions everybody, I'll close the PR.

Also, for Alex and Richard, `path.parts` would do the trick.

...

<http://python.org/psf/codeofconduct/>

I know, that's why I said parts. But remembering or looking that up is not easy either, so being able to skip that and just do things like index directly could be useful. On the other hand, str(path) is pretty essential knowledge, there's no point in helping people not look that up.

Hello, On Sun, 24 May 2020 08:23:29 -0400 David Mertz <mertz@gnosis.cx> wrote:

Hi Steven,

On Sun, May 24, 2020, 8:14 AM Steven D'Aprano

...

sorted(paths, key=len∘str, reverse=True) *semi-wink*

Do you have an evil twin with whom you share email.

Yesterday you were arguing against functional programming style on the grounds that filtering based on a predicate was too obscure represented as 'filter(pred, ...))'

Today you want full function composition.

Fwiw, I like function composition. This example makes a good case for it. Too bad that symbol isn't on most keyboards. I don't think 'compose(len, str)' looks so terrible, but it's longer.

Could find a use for that @ operator, finally. Note to myself: should implement that for my pycopy-dev dialect (https://github.com/pfalcon/pycopy). Currently it allows to override methods on (selected) builtin types, but not operators. Need to put that on TODO. -- Best regards, Paul mailto:pmiscml@gmail.com

What's wrong with using @? If I understand correctly, it's used for matrix multiplication, which is far enough from function composition to avoid confusion. And it's slightly similar visually to a circle. On Sun, May 24, 2020 at 4:25 PM Dan Sommers < 2QdxY4RzWzUUiLuE@potatochowder.com> wrote:

On Sunday, May 24, 2020, at 08:07 -0400, Steven D'Aprano wrote:

...

On Sun, May 24, 2020 at 02:27:00PM +0300, Ram Rachum wrote:

...

Today I wrote a script and did this:

sorted(paths, key=lambda path: len(str(path)), reverse=True)

But it would have been nicer if I could do this:

sorted(paths, key=len, reverse=True)

It would have been even nicer if we could compose functions:

sorted(paths, key=len∘str, reverse=True)

*semi-wink*

It started with y = len(str(f(g(h(x))))), which is ugly. Some people like pipes, and wrote object-like functions that could be composed with the "|" character slash:

y = x | h | g | f | str | len

(Or something like that. Maybe there was a ">" at the beginning.) Then a clojure fan I know showed me function called "thread":

f = thread([len, str, f, g, h]) y = f(x)

An untested Python implementation:

def thread(fs): # or maybe you like def thread(*fs) instead fs = reversed(fs) # or not, depending on how fs was constructed def inner(x): for f in fs: x = f(x) return x return inner

sorted(paths, key=thread([len, str]), reverse=True)

On the one hand, it's not quite as concise as composing the functions directly. On the other hand, ∘ ruffles a lot of ASCII feathers (but I'm sure Steven knows that). _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6WEANU... Code of Conduct: http://python.org/psf/codeofconduct/

Changed subject line. This is far from original topic. On Sun, May 24, 2020, 9:35 AM Ram Rachum <ram@rachum.com> wrote:

What's wrong with using @? If I understand correctly, it's used for matrix multiplication, which is far enough from function composition to avoid confusion. And it's slightly similar visually to a circle.

I like @. Function composition is kinda-sorta enough like for product that I can even make sense of the same operator. But how would you go about getting a .__matmul__ attribute onto all functions. For ones you write yourselves, you could decorate them at definition. What about all the other functions though. I suppose this is possible: @compasable def foo(x): return x + "foo" len = composable(len) newfun = len @ foo @ str.upper nbar = newfun("bar") # 6 I deliberately didn't decorate str.upper in the example since it shouldn't matter for a left-associative operator.

Speaking of evil, another evil idea would be to write code that modifies the ast and changes @ between functions to call a compose function instead. On Sun, May 24, 2020, 18:21 Steven D'Aprano <steve@pearwood.info> wrote:

On Sun, May 24, 2020 at 10:49:45AM -0400, David Mertz wrote:

...

But how would you go about getting a .__matmul__ attribute onto all functions. For ones you write yourselves, you could decorate them at definition. What about all the other functions though.

As a functional programming fan, you might not know about this, but we object oriented programming people have this concept called "inheritance" where we would add the attribute to FunctionType once, and just like magic every function would support it!

*wink*

Steven (the evil twin)

P.S. sadly, operator dunders are looked up on the class, not the instance, so adding a `__matmul__` method to individual functions doesn't help. It would have to be done at the class. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7SZBKY... Code of Conduct: http://python.org/psf/codeofconduct/

On Sun, May 24, 2020 at 11:21 AM Steven D'Aprano <steve@pearwood.info> wrote:

...

But how would you go about getting a .__matmul__ attribute onto all functions. For ones you write yourselves, you could decorate them at definition. What about all the other functions though.

As a functional programming fan, you might not know about this, but we object oriented programming people have this concept called "inheritance" where we would add the attribute to FunctionType once, and just like magic every function would support it!

I think I heard of that inheritance thing somewhere! :-) My thought is really that there's no way we're going to get .__matmul__ added (with the meaning "compose") to FunctionType. So I was thinking about what one could do with a separate module. I.e. something that could live on PyPI... before, perhaps someday, being added to standard library. Is there an evil way to monkey patch FunctionType? I.e. without actually recompiling a fork of the interpreter. Alex' forbiddenfruit.curse is pretty cool looking. But it does require explicitly cursing each individual function that might be composed. Alex Hall:

But seriously, I don't see that much point to this idea. It's just slightly more concise while not being particularly readable or beginner friendly.

sorted(paths, key=len @ str) sorted(paths, key=lambda p: len(str(p)))

I think once you compose three or more functions, lambda starts to look pretty bad. This is only slightly mitigated by one of those proposals for "a more concise lambda" that occur intermittently. And if you actually save a composed function under a meaningful name for later use, that much more so. Of course, I'm really not all that bothered by `my_op = compose(fun1, fun2, fun3, fun4)`. The @ might be cool, but writing my own HoF compose() isn't hard. I've been playing more lately with R Tidyverse. It's pipe with currying of first argument is actually really nice. The pipe operator is god-awful ugly. But other than that it works nicely. For example: iris %>% group_by(Species) %>% summarize_if(is.numeric, mean) %>% ungroup() %>% gather(measure, value, -Species) %>% arrange(value) It's not abstract composition since it always starts with a concrete object the several operations work on. But it is some of the same feel. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

I’ve never been able to remember whether (f@g)(x) means f(g(x)) or g(f(x)). That pretty much kills the idea for me. On Sun, May 24, 2020 at 11:10 Alex Hall <alex.mojaki@gmail.com> wrote:

On Sun, May 24, 2020 at 6:56 PM David Mertz <mertz@gnosis.cx> wrote:

...

On Sun, May 24, 2020 at 11:21 AM Steven D'Aprano <steve@pearwood.info> wrote:

...

...

But how would you go about getting a .__matmul__ attribute onto all functions. For ones you write yourselves, you could decorate them at definition. What about all the other functions though.

As a functional programming fan, you might not know about this, but we object oriented programming people have this concept called "inheritance" where we would add the attribute to FunctionType once, and just like magic every function would support it!

I think I heard of that inheritance thing somewhere! :-)

My thought is really that there's no way we're going to get .__matmul__ added (with the meaning "compose") to FunctionType. So I was thinking about what one could do with a separate module. I.e. something that could live on PyPI... before, perhaps someday, being added to standard library.

Is there an evil way to monkey patch FunctionType? I.e. without actually recompiling a fork of the interpreter. Alex' forbiddenfruit.curse is pretty cool looking. But it does require explicitly cursing each individual function that might be composed.

forbiddenfruit patches the type, look again. I used a loop because there isn't just one FunctionType: `type(compose) != type(len)`.

...

Alex Hall:

...

But seriously, I don't see that much point to this idea. It's just slightly more concise while not being particularly readable or beginner friendly.

sorted(paths, key=len @ str) sorted(paths, key=lambda p: len(str(p)))

I think once you compose three or more functions, lambda starts to look pretty bad.

It does? How? It sounds like the problem isn't the syntax for lambda, but just function composition in general, maybe because of too many parentheses. Maybe you'd like to change:

foo = bar(len(str(path)))

into

foo = (bar @ len @ str)(path)

In any case, it's rare to be able to simply compose three unary functions, e.g. `sorted(paths, key=bar @ len @ str)`. Usually you need to do something slightly more complicated, e.g. a second argument somewhere, and if you throw in functools.partial I think that's easily worse.

...

This is only slightly mitigated by one of those proposals for "a more concise lambda" that occur intermittently. And if you actually save a composed function under a meaningful name for later use, that much more so.

Why is:

my_op = bar @ len @ str

even more of an improvement over:

my_op = lambda p: bar(len(str(p)))

than @ is an improvement in the previous examples? If the answer is that you're not supposed to assign lambdas, I think the same logic should dictate not assigning compositions.

In fact, the reason to not assign lambdas is for better tracebacks, and now that I think of it, function composition would completely destroy tracebacks. For example:

``` for function in [ lambda p: str(len(p)), str @ len, ]: try: function(3) except: traceback.print_exc()

```

Output:

``` Traceback (most recent call last): File "main.py", line 15, in <module> function(3) File "main.py", line 11, in <lambda> lambda p: str(len(p)), TypeError: object of type 'int' has no len() Traceback (most recent call last): File "main.py", line 15, in <module> function(3) File "main.py", line 5, in <lambda> return lambda *args, **kwargs: self(other(*args, **kwargs)) TypeError: object of type 'int' has no len() ```

https://repl.it/@alexmojaki/LeanEnergeticPublisher-1

So based on that I'm strongly against this kind of proposal without syntactic support.

I've been playing more lately with R Tidyverse. It's pipe with currying

...

of first argument is actually really nice. The pipe operator is god-awful ugly. But other than that it works nicely. For example:

iris %>% group_by(Species) %>% summarize_if(is.numeric, mean) %>% ungroup() %>% gather(measure, value, -Species) %>% arrange(value)

It's not abstract composition since it always starts with a concrete object the several operations work on. But it is some of the same feel.

https://github.com/0101/pipetools _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JURJ5Y... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido (mobile)

On Sun, May 24, 2020 at 10:53 PM David Mertz <mertz@gnosis.cx> wrote:

On Sun, May 24, 2020, 3:43 PM Guido van Rossum <guido@python.org> wrote:

...

I’ve never been able to remember whether (f@g)(x) means f(g(x)) or g(f(x)). That pretty much kills the idea for me.

Well, it means whichever one the designers decide it should mean. But obviously it's a thing to remember, and one that could sensibly go the other way.

On the other hand, when I showed an example using filter() a couple days ago, I had to try it to remember whether the predicate or the iterable came first. Lots of such decisions are pretty arbitrary.

But when you *read* a call to filter(), it's generally pretty obvious which argument is which, even if you don't remember the signature. You just need to see which one's callable or which one's iterable (few things are both). You can probably guess just from the variable names. If you read `f@g`, you can only guess if one of `f(g(x))` or `g(f(x))` is nonsense, which I think is typically less obvious. Taking the `len@str` example, `str(len(path))` is a sensible expression, it's just a terrible sort key, and having to think that far sucks for readability. Also in the paths example, if you remember wrong and write the equivalent of `sorted(paths, key=lambda path: str(len(path)))`, you get a list in nonsense order which may be confusing to debug. If you get the order wrong in `filter()`, you should eventually get an error like `TypeError: 'list' object is not callable`.

[Guido]

...

I’ve never been able to remember whether (f@g)(x) means f(g(x)) or g(f(x)). That pretty much kills the idea for me.

[David Mertz]

Well, it means whichever one the designers decide it should mean. But obviously it's a thing to remember, and one that could sensibly go the other way.

On the other hand, when I showed an example using filter() a couple days ago, I had to try it to remember whether the predicate or the iterable came first. Lots of such decisions are pretty arbitrary.

Best I know, f@g applies g first in every language that implements a composition operator, and in mathematics. While that may be arbitrary, it's easy to remember: (f@g)(x) "looks a heck of a lot more like" f(g(x)) than g(f(x)) because the former leaves the identifiers in the same order.

Tiimmy:

Best I know, f@g applies g first in every language that implements a

...

composition operator, and in mathematics. While that may be arbitrary,

...

it's easy to remember: (f@g)(x) "looks a heck of a lot more like" f(g(x)) than g(f(x))

On Sun, May 24, 2020 at 5:39 PM Guido van Rossum <guido@python.org> wrote:

Dang, you're right. It works as you'd expect without overthinking it. :-)

I think one thing that pulls in different directions is that both composition and piping are useful, and do something closely related. But in one the data "goes" forward and in the other the data "goes backward." I use bash a lot, and writing something like this is common: cat data | sort | cut -d; -f6 | grep ^foo | sort -r | uniq -c My data is moving left to right through the operations. In contrast, I might write in some hypothetical programming language: myfilter = uniq[count] ∘ sort[reverse] ∘ grep[^foo] ∘ cut[;,f6] ∘ sort result = myfilter(data) (In my just-now-invented PL, the square brackets are some kind of partial application operators) Here my data is moving right to left within the composition. Haskell spells pipes approximately `>>`, F# as `|>`, R as `%>%`, and so on. But some of the same languages also have composition (point-free style) that reverses the order of operations (using different symbols). -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On Mon, May 25, 2020 at 8:54 AM Steven D'Aprano <steve@pearwood.info> wrote:

On Sun, May 24, 2020 at 06:31:46PM -0400, David Mertz wrote:

...

I think one thing that pulls in different directions is that both composition and piping are useful, and do something closely related. But in one the data "goes" forward and in the other the data "goes backward."

The same rule applies to function application though.

...

I use bash a lot, and writing something like this is common:

cat data | sort | cut -d; -f6 | grep ^foo | sort -r | uniq -c

And today's "Useless Use Of cat Award" goes to... :-)

sort data | ...

(What is it specifically about cat that is so attractive? I almost certainly would have done exactly what you did, even knowing that sort will take a file argument.)

<data sort | ... (When you use cat in a pipeline: https://http.cat/304 )

Compared to the regular old function call syntax:

uniq(sort(grep(cut(sort(data)))))

(ignoring extra arguments) where the data still moves right to left.

On the third hand, even if your language doesn't have pipes, it may have methods:

data.sort().cut().grep().sort().uniq()

which now moves left to right again.

Maybe it's function call syntax that is the weird one. It might be familiar to us, but maybe it's the one that's actually causing the weirdness. Suppose we wrote the function last: (data)sort Now it's basically become a pipeline. And yet this syntax looks so utterly bizarre that none of us would accept it... ChrisA

On Sun, May 24, 2020, 9:03 PM Rob Cliffe via Python-ideas

In fact it's *more* intuitive than what we do now (evaluation is strictly left-to-right), as can be seen with composed functions:

((path)str)len

Forth was created in 1970. The idea isn't brand new. C is two years newer (1972). But Algol is 12 years older (1958). Most languages of the last 30 years seem to be influenced most by C, or at least the Algol tradition for basic syntax. That doesn't mean it's better, but it won out for whatever reason. Smalltalk (1972) is interestingly different from either the Forth or Algol style. But closer to Forth. Fwiw, I don't think I'd have much difficulty adjusting to the postfix calling style, but Python isn't going to do that, even in version 17.3 in 2100.

On Sun, May 24, 2020 at 6:56 PM Steven D'Aprano <steve@pearwood.info> wrote:

...

I use bash a lot, and writing something like this is common: cat data | sort | cut -d; -f6 | grep ^foo | sort -r | uniq -c

And today's "Useless Use Of cat Award" goes to... :-)

sort data | ...

(What is it specifically about cat that is so attractive? I almost certainly would have done exactly what you did, even knowing that sort will take a file argument.)

This is probably going afield since it is a bash thing, not a Python thing. But I can actually answer this quite specifically. When I write a pipeline like that, I usually do not do it in one pass. I write a couple of the stages, look at what I have, and then add some more stages until I get it right. Many of the commands in the pipeline can take a file argument (not just sort, also cut, also grep, also uniq... everything I used in the example). But I find fairly often that I need to add a step BEFORE what I initially thought was first processing step. And then I have to remove the filename as an argument of that no-longer-first step. Rinse and repeat. With `cat` I know it does nothing, and I won't have to change it later (well, OK, sometimes I want -n or -s). So it is a completely generic "data" object ... sort of like how I would write "fluent programming" starting with a Pandas DataFrame, for example, and calling chains of methods.. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On 24May2020 19:28, David Mertz <mertz@gnosis.cx> wrote:

On Sun, May 24, 2020 at 6:56 PM Steven D'Aprano <steve@pearwood.info> wrote:

...

...

I use bash a lot, and writing something like this is common: cat data | sort | cut -d; -f6 | grep ^foo | sort -r | uniq -c

And today's "Useless Use Of cat Award" goes to... :-)

sort data | ...

(What is it specifically about cat that is so attractive? I almost certainly would have done exactly what you did, even knowing that sort will take a file argument.)

This is probably going afield since it is a bash thing, not a Python thing. But I can actually answer this quite specifically.

When I write a pipeline like that, I usually do not do it in one pass. I write a couple of the stages, look at what I have, and then add some more stages until I get it right. Many of the commands in the pipeline can take a file argument (not just sort, also cut, also grep, also uniq... everything I used in the example).

People forget that redirections may appear anywhere rather than just at the end of the command: <data sort | cut | ... >output But I take your point on incremental build-the-pipeline, I do that a lot. Cheers, Cameron Simpson <cs@cskk.id.au>

Really, I don't think new syntax is needed for that, as it is trivially resolved by a function call (I would type an example but Ricky's answer covers it) Moreover, such a callable, or other helper-callables can trivially enable ways of connecting the piped values through specific (positional/named) parameters in the next calls - allowing a whole Graph of functions to be composed. (And it is so easy to do and flexible extendable, I can't see a place for that in the stdlib) On Mon, 25 May 2020 at 00:11, Ricky Teachey <ricky@teachey.org> wrote:

Here's another whacky idea: how about adding a so-called FuncSeq to the collections library for composing functions?

Since FuncSeq is (obviously) a sequence, that might help with the intuition of the function application order. The idea is the function application order is the same as the iteration order of the sequence:

from collections import FuncSeq

fun_seq = FuncSeq([str, len]) fun_seq(789) # 3 fun_seq[::-1]("789") # '3'

--- Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IFTDGP... Code of Conduct: http://python.org/psf/codeofconduct/

On Sun, May 24, 2020 at 4:55 PM David Mertz <mertz@gnosis.cx> wrote:

Changed subject line. This is far from original topic.

On Sun, May 24, 2020, 9:35 AM Ram Rachum <ram@rachum.com> wrote:

...

What's wrong with using @? If I understand correctly, it's used for matrix multiplication, which is far enough from function composition to avoid confusion. And it's slightly similar visually to a circle.

I like @. Function composition is kinda-sorta enough like for product that I can even make sense of the same operator.

But how would you go about getting a .__matmul__ attribute onto all functions.

That's easy, especially when everyone is talking about evil. ``` from forbiddenfruit import curse def compose(self, other): return lambda *args, **kwargs: self(other (*args, **kwargs)) for func in [compose, len]: curse(type(func), "__matmul__", compose) assert (len @ str)(789) == 3 ``` https://repl.it/@alexmojaki/LeanEnergeticPublisher#main.py But seriously, I don't see that much point to this idea. It's just slightly more concise while not being particularly readable or beginner friendly. ``` sorted(paths, key=len @ str) sorted(paths, key=lambda p: len(str(p))) ``` I think the problem is just that lambda isn't the nicest syntax, and we'd like something more concise, e.g. ``` sorted(paths, key=:len(str($))) ``` which would be more generally useful. But I know this kind of thing has been discussed to death.

As we already, in the interpreter, use _ for last result, *vars for unpacking a list of positional variables and ** for unpacking to a dictionary how about (and this already messes up I18N if you are using _() as an alias for T() to mark strings for translation). We also currently use the syntax A().B() to do call method A and then call method B of the result How about: @piped A(params).B(_, options).C(*_).D(**_) As a reasonably recognisable (ASCII only) syntax where the @piped decorator tells us to call each function as soon as we have any returned value(s). The other familiar option, (for those used to the bash shell), would be to use a bare - as the marker for where to put the result(s) from the previous stage. Steve Barnes -----Original Message----- From: Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> Sent: 25 May 2020 02:28 To: Dan Sommers <2QdxY4RzWzUUiLuE@potatochowder.com> Cc: python-ideas@python.org Subject: [Python-ideas] Re: len(path) == len(str(path)) Dan Sommers writes:

On the other hand, ∘ ruffles a lot of ASCII feathers (but I'm sure > Steven knows that).

On the gripping hand, "<>" looks more or less like a circle :-), and we could finally put barry_as_FLUFL __past__ us! ;-) Here's a wacky syntax idea: to get a partially applied function of one argument, substitute the composition symbol for the argument. So if you have def foo(file, data) and def bar(x, parms) -> data, you could compose them with composed = foo(file, <>) <> bar(<>, parms) (closing over file and parms), and then apply composed(x). Not sure about readability, especially with lots of arguments, or usability. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LVBKHR... Code of Conduct: http://python.org/psf/codeofconduct/

Kyle Stanley wrote:

While I'm -1 on the original proposal, I think the idea of PurePath.__len__ returning the number of components in the path may be worth some further consideration.

FYI PEP 428 says: In this proposal, the path classes do not derive from a builtin type. This contrasts with some other Path class proposals which were derived from str. They also do not pretend to implement the sequence protocol: if you want a path to act as a sequence, you have to lookup a dedicated attribute (the parts attribute). So while __len__() is not the whole sequence protocol, it seems like the idea was to explicitely use `len(path.parts)` instead of `len(path)` for this.