[Python-ideas] Re: len(path) == len(str(path))

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

[Python-ideas] Re: Function composition

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

[Python-ideas] Re: Function composition

On 24May2020 19:28, David Mertz wrote: On Sun, May 24, 2020 at 6:56 PM Steven D'Aprano 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 |

[Python-ideas] Re: Function composition

On 25/05/20 3:27 am, Ram Rachum wrote: 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. How do you tell just from the ast whether a particular @ is between functions? -- Greg

[Python-ideas] Re: Function composition

On Sunday, May 24, 2020, at 18:58 -0400, Chris Angelico wrote: > 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

[Python-ideas] Re: len(path) == len(str(path))

On 24May2020 13:46, M.-A. Lemburg 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

[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

[Python-ideas] Re: Function composition

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

[Python-ideas] Re: Function composition

On 24/05/2020 23:58, Chris Angelico wrote: 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

[Python-ideas] Re: Function composition

JavaScript has an early proposal for this use-case: https://github.com/tc39/proposal-partial-application#pipeline-and-partial-application where "cat data | sort | cut -d; -f6 | grep ^foo | sort -r | uniq -c" could be represented as: data |> sort |> cut(?, delimeter=";", fields=6) |>

[Python-ideas] Re: Function composition

On Sun, May 24, 2020 at 6:56 PM Steven D'Aprano 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

[Python-ideas] Re: Function composition

On Mon, May 25, 2020 at 8:54 AM Steven D'Aprano 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"

[Python-ideas] Re: Function composition

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

[Python-ideas] Re: Function composition

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

[Python-ideas] Re: Function composition

On Sun, May 24, 2020 at 11:17 PM Tim Peters wrote: > [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

[Python-ideas] Re: Function composition

Dang, you're right. It works as you'd expect without overthinking it. :-) I guess what has always (seriously, since my undergrad years studying math!) confused me is that somehow when this function is introduced they say (g*f)(x) = g(f(x)). The

[Python-ideas] Re: Function composition

On Sun, May 24, 2020, 5:11 PM Alex Hall > 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

[Python-ideas] Re: Function composition

[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

[Python-ideas] Re: Function composition

On Sun, May 24, 2020 at 10:53 PM David Mertz wrote: > On Sun, May 24, 2020, 3:43 PM Guido van Rossum 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

[Python-ideas] Re: Function composition

On Sun, May 24, 2020, 3:43 PM Guido van Rossum 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

[Python-ideas] Re: Optional keyword arguments

On Sun, May 24, 2020 at 10:05 PM Dominik Vilsmeier wrote: > On 24.05.20 18:34, Alex Hall wrote: > > > OK, let's forget the colon. The point is just to have some kind of > 'modifier' on the default value to say 'this is evaluated on each function > call', while still having something that looks

[Python-ideas] Re: Optional keyword arguments

On 24.05.20 19:38, David Mertz wrote: As syntax, I presume this would be something like: output = [] for x in data:     a = delayed inc(x)     b = delayed double(x)     c = delayed add(a, b) output.append(c) total = sum(outputs)  # concrete answer here. Obviously the simple example of adding

[Python-ideas] Re: Optional keyword arguments

On 24.05.20 18:34, Alex Hall wrote: OK, let's forget the colon. The point is just to have some kind of 'modifier' on the default value to say 'this is evaluated on each function call', while still having something that looks like `arg=`. Maybe something like:      def func(options=from

[Python-ideas] Re: Optional keyword arguments

On Mon, May 25, 2020 at 3:42 AM David Mertz wrote: > The pattern: > > def fun(..., option=None): > if option is None: > option = something_else > > Becomes second nature very quickly. Once you learn it, you know it. A line > of two of code isn't a big deal. > And it isn't entirely

[Python-ideas] Re: Function composition

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 wrote: > On Sun, May 24, 2020 at 6:56 PM David Mertz wrote: > >> On Sun, May 24, 2020 at 11:21 AM Steven D'Aprano >> wrote: >> >>> > But

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On 24/05/2020 19:01, David Mertz wrote: The old images I find lack the '1', but not the '0'.  What model was this you had? Sorry, no way I can remember that far back.  I'm not even certain about the missing 0. On Sun, May 24, 2020 at 1:48 PM Rob Cliffe via Python-ideas

[Python-ideas] Re: Function composition

On Sun, May 24, 2020 at 6:56 PM David Mertz wrote: > On Sun, May 24, 2020 at 11:21 AM Steven D'Aprano > 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

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On 22/05/2020 13:28, Steven D'Aprano wrote: On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote: I had a customer who was old enough to use upper case letter O for zero and lower case letter l for 1 because she was old enough to have learned to type before typewriters had number

[Python-ideas] Re: Optional keyword arguments

On Sun, May 24, 2020 at 12:36 PM Alex Hall wrote: > OK, let's forget the colon. The point is just to have some kind of > 'modifier' on the default value to say 'this is evaluated on each function > call', while still having something that looks like `arg=`. Maybe > something like: > > def

[Python-ideas] Re: Function composition

On Sun, May 24, 2020 at 11:21 AM Steven D'Aprano 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,

[Python-ideas] Re: Optional keyword arguments

On Sat, May 23, 2020 at 2:37 AM Steven D'Aprano wrote: > On Thu, May 21, 2020 at 02:50:00PM +0200, Alex Hall wrote: > > or a more realistic example: > > > > def func(options=:{}): > > > Add annotations and walrus operator: > > def flummox(options:dict=:(a:={x: None})): > > and we now

[Python-ideas] Re: Optional keyword arguments

On Sat, May 23, 2020 at 11:34 PM Tiago Illipronti Girardi < tiagoigira...@gmail.com> wrote: > A programmer making the least effort wouldn't update themselves on the > grammar: the patch would be useless. This is taking my words a bit far. Typing annotations are tedious and have to be done

[Python-ideas] Re: Function composition

On Sun, May 24, 2020 at 4:55 PM David Mertz wrote: > Changed subject line. This is far from original topic. > > On Sun, May 24, 2020, 9:35 AM Ram Rachum wrote: > >> What's wrong with using @? If I understand correctly, it's used for >> matrix multiplication, which is far enough from function

[Python-ideas] Re: Function composition

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 wrote: > On Sun, May 24, 2020 at 10:49:45AM -0400, David Mertz wrote: > > > But how would you go about

[Python-ideas] Re: Function composition

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

[Python-ideas] Function composition

Changed subject line. This is far from original topic. On Sun, May 24, 2020, 9:35 AM Ram Rachum 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

[Python-ideas] Re: len(path) == len(str(path))

On Sun, May 24, 2020 at 3:38 PM Ram Rachum 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. > The matrix multiplication PEP

[Python-ideas] Re: len(path) == len(str(path))

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 < 2qdxy4rzwzuui...@potatochowder.com> wrote: >

[Python-ideas] Re: len(path) == len(str(path))

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:

[Python-ideas] Re: len(path) == len(str(path))

Hello, On Sun, 24 May 2020 08:23:29 -0400 David Mertz 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

[Python-ideas] Re: len(path) == len(str(path))

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

[Python-ideas] Re: len(path) == len(str(path))

On Sun, May 24, 2020 at 1:58 PM Ram Rachum 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. > >> > > I know, that's why I

[Python-ideas] Re: len(path) == len(str(path))

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

[Python-ideas] Re: len(path) == len(str(path))

Like several other commenters, I would expect len(path) to be its depth, not the length of its string representation. On Sun, May 24, 2020, 7:30 AM Ram Rachum wrote: > Hi everyone, > > I submitted a PR today, and Serhiy decided it needs a discussion on > python-ideas and agreement from core

[Python-ideas] Re: len(path) == len(str(path))

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. On Sun, May 24, 2020 at 2:55 PM Richard Damon wrote: > On 5/24/20 7:27 AM, Ram Rachum wrote: > > Hi everyone, > > > > I

[Python-ideas] Re: len(path) == len(str(path))

Hello, On Sun, 24 May 2020 08:38:22 -0300 Bernardo Sulzbach 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

[Python-ideas] Re: len(path) == len(str(path))

On Sun, May 24, 2020 at 1:42 PM Bernardo Sulzbach < berna...@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

[Python-ideas] Re: len(path) == len(str(path))

On 5/24/20 7:27 AM, Ram Rachum wrote: > Hi everyone, > > I submitted a PR today, and Serhiy decided it needs a discussion on > python-ideas and agreement from core developers before it could go > forward. > > BPO: https://bugs.python.org/issue40752  > PR: 

[Python-ideas] Re: len(path) == len(str(path))

On 24.05.2020 13:27, Ram Rachum wrote: > Hi everyone, > > I submitted a PR today, and Serhiy decided it needs a discussion on > python-ideas and agreement from core developers before it could go forward. > > BPO: https://bugs.python.org/issue40752  > PR: 

[Python-ideas] Re: len(path) == len(str(path))

"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

[Python-ideas] len(path) == len(str(path))

Hi everyone, I submitted a PR today, and Serhiy decided it needs a discussion on python-ideas and agreement from core developers before it could go forward. BPO: https://bugs.python.org/issue40752 PR: https://github.com/python/cpython/pull/20348 Today I wrote a script and did this: