Mailman 3 May 2015 - Python-ideas

Policy for altering sys.path
by Thomas Güttler 11 May '15

11 May '15

I am missing a policy how sys.path should be altered. We run a custom sub class of list in sys.path. We set it in sitecustomize.py This instance get replace by a common list in lines like this: sys.path = glob.glob(os.path.join(WHEEL_DIR, "*.whl")) + sys.path The above line is from pip, it similar things happen in a lot of packages. Before trying to solve this with code, I think the python community should agree an a policy for altering sys.path. What can I do to this done? We use Python 2.7. Related: http://bugs.python.org/issue24135 Regards, Thomas Güttler

8 14

Partial operator (and 'third-party methods' and 'piping')
by Koos Zevenhoven 10 May '15

10 May '15

Hi everyone! (Sorry about double posting, but I wanted to start a new thread, which I tried but apparently failed to do last time. Although inspired by and related to the function composition discussion, this is now something different and should not be cluttering the composition thread.) Reading the recent emails in the function composition thread started by Ivan, I realized that my sketch for a composition operator (from yesterday, quoted below) would be much better if it did not actually do function composition . Instead, -> would be quite powerful as 'just' a partial operator -- perhaps even more powerful, as I demonstrate below. However, this is not an argument against @ composition, which might in fact play together with this quite nicely. This allows some nice things with multi-argument functions too. I realize that it may be unlikely that a new operator would be added, but here it is anyway, as food for thought. (With an existing operator, I suspect it would be even less likely, because of precedence rules : ) So, -> would be an operator with a precedence similar to .attribute access (but lower than .attribute): # The simple definition of what it does: arg->func # equivalent to functools.partial(func, arg) This would allow for instance: arg -> spam() -> cheese(kind = 'gouda') -> eggs() which would be equivalent to eggs(cheese(spam(arg), kind = 'gouda')) Or even together together with the proposed @ composition: rms = root @ mean @ square->map # for an iterable non-numpy argument And here's something I find quite interesting. Together with @singledispatch from 3.4 (or possibly an enhanced version using type annotations in the future?), one could add 'third-party methods' to classes in other libraries without monkey patching. A dummy example: from numpy import array my_list = [1,2,3] my_array = array(my_list) my_mean = my_array.mean() # This currently works in numpy from rmslib import rms my_rms = my_array->rms() # efficient rms for numpy arrays my_other_rms = my_list->rms() # rms that works on any iterable One would be able to distinguish between calls to methods and 'third-party methods' based on whether . or -> is used for accessing them, which I think is a good thing. Also, third-party methods would be less likely to mutate the object, just like func(obj) is less likely to mutate obj than obj.method(). See more examples below. I converted my examples from last night to this IMO better version, because at least some of them would still be relevant. On 10.5.2015 2:07, Koos Zevenhoven wrote: > On 10.5.2015 1:03, Gregory Salvan wrote: >> Nobody convinced by arrow operator ? >> >> like: arg -> spam -> eggs -> cheese >> or cheese <- eggs <- spam <- arg >> >> > > I like | a lot because of the pipe analogy. However, having a new > operator for this could solve some issues about operator precedence. > > Today, I sketched one possible version that would use a new .. > operator. I'll explain what it would do (but with your -> instead of > my ..) > > Here, the operator (.. or ->) would have a higher precedence than > function calls () but a lower precedence than attribute access > (obj.attr). > > First, with single-argument functions spam, eggs and cheese, and a > non-function arg: > > arg->eggs->spam->cheese() # equivalent to cheese(spam(eggs(arg))) With -> as a partial operator, this would instead be: arg->eggs()->spam()->cheese() # equivalent to cheese(spam(eggs(arg))) > eggs->spam->cheese # equivalent to lambda arg: cheese(spam(eggs(arg))) > With -> as a partial operator this could be: lambda arg: arg->eggs()->spam()->cheese() > Then, if spam and eggs both took two arguments; eggs(arg1, arg2), > spam(arg1, arg2) > > arg->eggs # equivalent to partial(eggs, arg) > eggs->spam(a, b, c) # equivalent to spam(eggs(a, b), c) With -> as a partial operator, the first one would work, and the second would become: eggs(a,b)->spam(c) # equivalent to spam(eggs(a, b), c) > arg->eggs->spam(b,c) # equivalent to spam(eggs(arg, b), c) > This would become: arg->eggs(b)->spam(c) # equivalent to spam(eggs(arg, b), c) Note that this would be quite flexible in partial 'piping' of multi-argument functions. > So you could think of -> as an extended partial operator. And this > would naturally generalize to functions with even more arguments. The > arguments would always be fed in the same order as in the equivalent > function call, which makes for a nice rule of thumb. However, I > suppose one would usually avoid combinations that are difficult to > understand. > > Some examples that this would enable: > > # Example 1 > from numpy import square, mean, sqrt > rms = square->mean->sqrt # I think this order is fine because it is > not @ > This would become: def rms(arr): return arr->square()->mean()->sqrt() > # Example 2 (both are equivalent) > spam(args)->eggs->cheese() # the shell-syntax analogy that Steven > mentioned. > This would be: spam(args)->eggs()->cheese() Of course the shell piping analogy would be quite far, because it looks so different. > # Example 3 > # Last but not least, we would finally have this > some_sequence->len() > some_object->isinstance(MyType) > And: func->map(seq) func->reduce(seq) -- Koos

1 0

Re: [Python-ideas] Function composition (was no subject)
by Koos Zevenhoven 10 May '15

10 May '15

On 2015-05-09 21:16, Steven D'Aprano wrote: > On Sat, May 09, 2015 at 11:38:38AM -0400, Ron Adam wrote: > >> How about an operator for partial? >> >> root @ mean @ map $ square(xs) > Apart from the little matter that Guido has said that $ will never be > used as an operator in Python, what is the association between $ and > partial? > > Most other operators have either been used for centuries e.g. + and - or > at least decades e.g. * for multiplication because ASCII doesn't have > the × symbol. The barrier to using a completely arbitrary symbol with no > association to the function it plays should be considered very high. > > I would only support an operator for function composition if it was at > least close to the standard operators used for function composition in > other areas. @ at least suggests the ∘ used in mathematics, e.g. > sin∘cos, but | is used in pipelining languages and shells and could be > considered, e.g. ls | wc. > > My own preference would be to look at @ as the closest available ASCII > symbol to ∘ and use it for left-to-right composition, and | for > left-to-right function application. E.g. > > (spam @ eggs @ cheese)(arg) is equivalent to spam(eggs(cheese(arg))) > > (spam | eggs | cheese)(arg) is equivalent to cheese(eggs(spam(arg))) > > also known as compose() and rcompose(). > We can read "@" as "of", "spam of eggs of cheese of arg", and | as > a pipe, "spam(arg) piped to eggs piped to cheese". For me these are by far the most logical ones too, for exactly the same reasons (and because of the connection of @ with matrix multiplication and operators that operate from the left). > It's a pity we can't match the shell syntax and write: > > spam(args)|eggs|cheese > > but that would have a completely different meaning. > But it does not need to have a different meaning. You could in addition have: spam @ eggs @ cheese @ arg # equivalent to spam(eggs(cheese(arg))) arg | spam | eggs | cheese # equivalent to cheese(eggs(spam(arg))) Here, arg would thus be recognized as not a function. In this version, your example of spam(args)|eggs|cheese would do exactly the same operation as (spam | eggs | cheese)(args) :-). > David Beazley has a tutorial on using coroutines in pipelines: > > http://www.dabeaz.com/coroutines/ > > where he ends up writing this: > > f = open("access-log") > follow(f, > grep('python', > printer())) > > > Coroutines grep() and printer() make up the pipeline. I cannot help but > feel that the | syntax would be especially powerful for this sort of > data processing purpose: > > # could this work using some form of function composition? > follow(f, grep('python')|printer) > > > This seems promising! -- Koos

5 8

Re: [Python-ideas] Function composition (was no subject)
by Koos Zevenhoven 10 May '15

10 May '15

On 10.5.2015 2:28, Ivan Levkivskyi wrote: > functions. In other words I agree with Andrew that "elementwise" is a > good match with compose, and what we really need is to "pipe" things > that take a vector (or just an iterable) and return a vector (iterable). > > So that probably a good place (in a potential future) for compose > would be not functools but itertools. But indeed a good place to test > this would be Numpy. > Another way to deal with elementwise operations on iterables would be to make a small, mostly backwards compatible change in map: When map is called with just one argument, for instance map(square), it would return a function that takes iterables and maps them element-wise. Now it would be easier to use map in pipelines, for example: rms = sqrt @ mean @ map(square) or values->map(square)->mean->sqrt() Or if the change in map is not popular, there could be something like functools.mapper(func) that does that. Or even something more crazy, like square.map(seq), so that square.map could be used in pipelines. -- Koos

6 10

Re: [Python-ideas] Function composition (was no subject)
by Koos Zevenhoven 10 May '15

10 May '15

Just a small correction to my below email (the definition of "feed"): On 10.5.2015 18:15, Koos Zevenhoven wrote: > On 10.5.2015 5:56, Steven D'Aprano wrote: > > [...] >>> You could in addition have: >>> >>> spam @ eggs @ cheese @ arg # equivalent to spam(eggs(cheese(arg))) >>> >>> arg | spam | eggs | cheese # equivalent to cheese(eggs(spam(arg))) >>> >>> Here, arg would thus be recognized as not a function. >> No. I think it is absolutely vital to distinguish by syntax the >> difference between composition and function application, and not try to >> "do what I mean". DWIM software has a bad history of doing the wrong >> thing. >> >> Every other kind of callable uses obj(arg) to call it: types, functions, >> methods, partial objects, etc. We shouldn't make function composition >> try to be different. If I write sqrt@100 I should get a runtime error, >> not 10. >> >> I don't mind if the error is delayed until I actually try to call the >> composed object, but at some point I should get a TypeError that 100 is >> not callable. >> > > That is in fact a part of why I added a function call () to the sketch > in my recent post (extended partial operator, there using ->). This > way, the composition operator would never do the actual call by > itself, but instead make a partial. But I admit that (sqrt@100)() > still would give 10, not the runtime error you want (which may indeed > cause problems with callable arguments). It only solves half the problem. > > Another way to feed the left-to-right | composition from the left > would of course be > > (feed(x) | spam | eggs | cheese)() # feed would be just def > feed(x): return x > Sorry, I messed that up. "feed" would of course be: def feed(x): def feeder(): return x return feeder > But I'm not sure I like it. Luckily, (cheese @ eggs @ spam)(x) does > not have this problem. However, if cheese, eggs and spam were matrix > transformations, one would write > > cheese @ eggs @ spam @ x > > But perhaps numpy would want to bridge this gap with extended behavior > (allow calling numpy functions with @ or "calling a matrix > transformation" with () ). Or perhaps not :). > > -- Koos > > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/

1 0

Re: [Python-ideas] Function composition (was no subject)
by Koos Zevenhoven 10 May '15

10 May '15

On 10.5.2015 5:56, Steven D'Aprano wrote: [...] >> You could in addition have: >> >> spam @ eggs @ cheese @ arg # equivalent to spam(eggs(cheese(arg))) >> >> arg | spam | eggs | cheese # equivalent to cheese(eggs(spam(arg))) >> >> Here, arg would thus be recognized as not a function. > No. I think it is absolutely vital to distinguish by syntax the > difference between composition and function application, and not try to > "do what I mean". DWIM software has a bad history of doing the wrong > thing. > > Every other kind of callable uses obj(arg) to call it: types, functions, > methods, partial objects, etc. We shouldn't make function composition > try to be different. If I write sqrt@100 I should get a runtime error, > not 10. > > I don't mind if the error is delayed until I actually try to call the > composed object, but at some point I should get a TypeError that 100 is > not callable. > That is in fact a part of why I added a function call () to the sketch in my recent post (extended partial operator, there using ->). This way, the composition operator would never do the actual call by itself, but instead make a partial. But I admit that (sqrt@100)() still would give 10, not the runtime error you want (which may indeed cause problems with callable arguments). It only solves half the problem. Another way to feed the left-to-right | composition from the left would of course be (feed(x) | spam | eggs | cheese)() # feed would be just def feed(x): return x But I'm not sure I like it. Luckily, (cheese @ eggs @ spam)(x) does not have this problem. However, if cheese, eggs and spam were matrix transformations, one would write cheese @ eggs @ spam @ x But perhaps numpy would want to bridge this gap with extended behavior (allow calling numpy functions with @ or "calling a matrix transformation" with () ). Or perhaps not :). -- Koos

1 0

Re: [Python-ideas] Function composition (was no subject)
by Koos Zevenhoven 10 May '15

10 May '15

On 8.5.2015 8:19, Rustom Mody wrote: > On Wed, May 6, 2015 at 6:45 PM, Ivan Levkivskyi <levkivskyi(a)gmail.com > <mailto:levkivskyi@gmail.com>> wrote: > > > def sunique(lst): > return sorted(list(set(lst))) > > vs. > > sunique = sorted @ list @ set > > > I would like to suggest that if composition is in fact added to python > its order is 'corrected' > ie in math there are two alternative definitions of composition > > [1] f o g = λ x • g(f(x)) > [2] f o g = λ x • f(g(x)) > > [2] is more common but [1] is also used > > And IMHO [1] is much better for left-to-right reading so your example > becomes > sunique = set @ list @ sorted > which reads as smoothly as a classic Unix pipeline: > > "Unnamed parameter input to set; output inputted to list; output > inputted to sort" > > While both versions make sense, [2] is the one that resembles the chaining of linear operators or matrices, since column vectors are the convention. For the left-to-right pipeline version, some other operator might be more appropriate. Also, it would then be more clear to also feed x into the pipeline from the left, instead of putting (x) on the right like in a normal function call. As a random example, (root @ mean @ square)(x) would produce the right order for rms when using [2]. -- Koos

9 17

Re: [Python-ideas] Function composition (was no subject)
by Ivan Levkivskyi 10 May '15

10 May '15

I was thinking about recent ideas discussed here. I also returned back to origins of my initial idea. The point is that it came from Numpy, I use Numpy arrays everyday, and typically I do exactly something like root(mean(square(data))). Now I am thinking: what is actually a matrix? It is something that takes a vector and returns a vector. But on the other hand the same actually do elementwise functions. It does not really matter, what we do with a vector: transform by a product of matrices or by composition of functions. In other words I agree with Andrew that "elementwise" is a good match with compose, and what we really need is to "pipe" things that take a vector (or just an iterable) and return a vector (iterable). So that probably a good place (in a potential future) for compose would be not functools but itertools. But indeed a good place to test this would be Numpy. An additional comment: it is indeed good to have both @ and | for compose and rcompose. Side note, one can actually overload __rmatmul__ on arrays as well so that you can write root @ mean @ square @ data Moreover, one can overload __or__ on arrays, so that one can write data | square | mean | root even with ordinary functions (not Numpy's ufuncs or composable) . These examples are actually "flat is better than nested" in the extreme form. Anyway, they (Numpy) are going to implement the @ operator for arrays, may be it would be a good idea to check that if something on the left from me (array) is not an array but a callable then apply it elementwise. Concerning the multi-argument functions, I don't like $ symbol, don't know why. It seems really unintuitive why it means partial application. One can autocurry composable functions and apply same rules that Numpy uses for ufuncs. More precisely, if I write add(data1, data2) with arrays it applies add pairwise. But if I write add(data1, 42) it is also fine, it simply adds 42 to every element. With autocurrying one could write root @ mean @ add(data) @ square @ data2 or root @ mean @ square @ add(42) @ data However, as I see it now it is not very readable, so that may be the best choise is to reserve @ and | for "piping" iterables through transformers that take one argument. In other words it should be left to user to make add(42) of an appropriate type. It is the same logic as for decorators, if I write @modify(arg) def func(x): return None I must care that modify(arg) evaluates to something that takes one callable and returns a callable. On May 9, 2015, at 01:36, Stephen J. Turnbull <stephen(a)xemacs.org> wrote: > > > > Andrew Barnert writes: > >>> On May 8, 2015, at 19:58, Stephen J. Turnbull <stephen(a)xemacs.org> > wrote: > >>> > >>> Koos Zevenhoven writes: > >>> > >>>> As a random example, (root @ mean @ square)(x) would produce the right > >>>> order for rms when using [2]. > >>> > >>> Hardly interesting. :-) The result is an exception, as root and square > >>> are conceptually scalar-to-scalar, while mean is sequence-to-scalar. > >> > >> Unless you're using an elementwise square and an array-to-scalar > >> mean, like the ones in NumPy, > > > > Erm, why would square be elementwise and root not? I would suppose > > that everything is element-wise in Numpy (not a user yet). > > Most functions in NumPy are elementwise when applied to arrays, but can > also be applied to scalars. So, square is elementwise because it's called > on an array, root is scalar because it's called on a scalar. (In fact, root > could also be elementwise--aggregating functions like mean can be applied > across just one axis of a 2D or higher array, reducing it by one dimension, > if you want.) > > Before you try it, this sounds like a complicated nightmare that can't > possibly work in practice. But play with it for just a few minutes and it's > completely natural. (Except for a few cases where you want some array-wide > but not element-wise operation, most famously matrix multiplication, which > is why we now have the @ operator to play with.) > > >> in which case it works perfectly well... > > > > But that's an aspect of my point (evidently, obscure). Conceptually, > > as taught in junior high school or so, root and square are scalar-to- > > scalar. If you are working in a context such as Numpy where it makes > > sense to assume they are element-wise and thus composable, the context > > should provide the compose operator(s). > > I was actually thinking on these lines: what if @ didn't work on > types.FunctionType, but did work on numpy.ufunc (the name for the > "universal function" type that knows how to broadcast across arrays but > also work on scalars)? That's something NumPy could implement without any > help from the core language. (Methods are a minor problem here, but it's > obvious how to solve them, so I won't get into it.) And if it turned out to > be useful all over the place in NumPy, that might turn up some great uses > for the idiomatic non-NumPy Python, or it might show that, like elementwise > addition, it's really more a part of NumPy than of Python. > > But of course that's more of a proposal for NumPy than for Python. > > > Without that context, Koos's > > example looks like a TypeError. > > >> But Koos's example, even if it was possibly inadvertent, shows that > >> I may be wrong about that. Maybe compose together with element-wise > >> operators actually _is_ sufficient for something beyond toy > >> examples. > > > > Of course it is!<wink /> I didn't really think there was any doubt > > about that. > > I think there was, and still is. People keep coming up with abstract toy > examples, but as soon as someone tries to give a good real example, it only > makes sense with NumPy (Koos's) or with some syntax that Python doesn't > have (yours), because to write them with actual Python functions would > actually be ugly and verbose (my version of yours). > > I don't think that's a coincidence. You didn't write "map square" because > you don't know how to think in Python, but because using compose profitably > inherently implies not thinking in Python. (Except, maybe, in the case of > NumPy... which is a different idiom.) Maybe someone has a bunch of obvious > good use cases for compose that don't also require other functions, > operators, or syntax we don't have, but so far, nobody's mentioned one. > > ------------------------------ > > On 5/9/2015 6:19 AM, Andrew Barnert via Python-ideas wrote: > > > I think there was, and still is. People keep coming up with abstract toy > examples, but as soon as someone tries to give a good real example, it only > makes sense with NumPy (Koos's) or with some syntax that Python doesn't > have (yours), because to write them with actual Python functions would > actually be ugly and verbose (my version of yours). > > > > I don't think that's a coincidence. You didn't write "map square" > because you don't know how to think in Python, but because using compose > profitably inherently implies not thinking in Python. (Except, maybe, in > the case of NumPy... which is a different idiom.) Maybe someone has a bunch > of obvious good use cases for compose that don't also require other > functions, operators, or syntax we don't have, but so far, nobody's > mentioned one. > > I agree that @ is most likely to be usefull in numpy's restricted context. > > A composition operator is usually defined by application: f@g(x) is > defined as f(g(x)). (I sure there are also axiomatic treatments.) It > is an optional syntactic abbreviation. It is most useful in a context > where there is one set of data objects, such as the real numbers, or one > set + arrays (vectors) defined on the one set; where all function are > univariate (or possible multivariate, but that can can be transformed to > univariate on vectors); *and* where parameter names are dummies like > 'x', 'y', 'z', or '_'. > > The last point is important. Abbreviating h(x) = f(g(x)) with h = f @ g > does not lose any information as 'x' is basically a placeholder (so get > rid of it). But parameter names are important in most practical > contexts, both for understanding a composition and for using it. > > dev npv(transfers, discount): > '''Return the net present value of discounted transfers. > > transfers: finite iterable of amounts at constant intervals > discount: fraction per interval > ''' > divisor = 1 + discount > return sum(tranfer/divisor**time > for time, transfer in enumerate(transfers)) > > Even if one could replace the def statement with > npv = <some combination of @, sum, map, add, div, power, enumerate, ...> > with parameter names omitted, it would be harder to understand. Using > it would require the ability to infer argument types and order from the > composed expression. > > I intentionally added a statement to calculate the common subexpression > prior to the return. I believe it would have to put back in the return > expression before converting. > > -- > Terry Jan Reedy > > > > ------------------------------ > > On 05/09/2015 03:21 AM, Andrew Barnert via Python-ideas wrote: > >> >I suppose you could write (root @ mean @ (map square)) (xs), > > > Actually, you can't. You could write (root @ mean @ partial(map, > > square))(xs), but that's pretty clearly less readable than > > root(mean(map(square, xs))) or root(mean(x*x for x in xs). And that's > > been my main argument: Without a full suite of higher-level operators > > and related syntax, compose alone doesn't do you any good except for toy > > examples. > > How about an operator for partial? > > root @ mean @ map $ square(xs) > > > Actually I'd rather reuse the binary operators. (I'd be happy if they were > just methods on bytes objects BTW.) > > compose(root, mean, map(square, xs)) > > root ^ mean ^ map & square (xs) > > root ^ mean ^ map & square ^ xs () > > Read this as... > > compose root, of mean, of map with square, of xs > > Or... > > apply(map(square, xs), mean, root) > > map & square | mean | root (xs) > > xs | map & square | mean | root () > > > Read this as... > > apply xs, to map with square, to mean, to root > > > These are kind of cool, but does it make python code easier to read? That > seems like it may be subjective depending on the amount of programming > experience someone has. > > Cheers, > Ron > > > > ------------------------------ > > Hi, > I had to answer some of these questions when I wrote Lawvere: > https://pypi.python.org/pypi/lawvere > > First, there is two kind of composition: pipe and circle so I think a > single operator like @ is a bit restrictive. > I like "->" and "<-" > > Then, for function name and function to string I had to introduce function > signature (a tuple). > It provides a good tool for decomposition, introspection and comparison in > respect with mathematic definition. > > Finally, for me composition make sense when you have typed functions > otherwise it can easily become a mess and this make composition tied to > multiple dispatch. > > I really hope composition will be introduced in python but I can't see how > it be made without rethinking a good part of function definition. > > > > 2015-05-09 17:38 GMT+02:00 Ron Adam <ron3200(a)gmail.com>: > > > > > > > On 05/09/2015 03:21 AM, Andrew Barnert via Python-ideas wrote: > > > >> >I suppose you could write (root @ mean @ (map square)) (xs), > >>> > >> > > Actually, you can't. You could write (root @ mean @ partial(map, > >> square))(xs), but that's pretty clearly less readable than > >> root(mean(map(square, xs))) or root(mean(x*x for x in xs). And that's > >> been my main argument: Without a full suite of higher-level operators > >> and related syntax, compose alone doesn't do you any good except for toy > >> examples. > >> > > > > How about an operator for partial? > > > > root @ mean @ map $ square(xs) > > > > > > Actually I'd rather reuse the binary operators. (I'd be happy if they > > were just methods on bytes objects BTW.) > > > > compose(root, mean, map(square, xs)) > > > > root ^ mean ^ map & square (xs) > > > > root ^ mean ^ map & square ^ xs () > > > > Read this as... > > > > compose root, of mean, of map with square, of xs > > > > Or... > > > > apply(map(square, xs), mean, root) > > > > map & square | mean | root (xs) > > > > xs | map & square | mean | root () > > > > > > Read this as... > > > > apply xs, to map with square, to mean, to root > > > > > > These are kind of cool, but does it make python code easier to read? > That > > seems like it may be subjective depending on the amount of programming > > experience someone has. > > > > Cheers, > > Ron > > > > >

3 4

Re: [Python-ideas] Function composition (was no subject)
by Koos Zevenhoven 09 May '15

09 May '15

On 10.5.2015 1:03, Gregory Salvan wrote: > Nobody convinced by arrow operator ? > > like: arg -> spam -> eggs -> cheese > or cheese <- eggs <- spam <- arg > > I like | a lot because of the pipe analogy. However, having a new operator for this could solve some issues about operator precedence. Today, I sketched one possible version that would use a new .. operator. I'll explain what it would do (but with your -> instead of my ..) Here, the operator (.. or ->) would have a higher precedence than function calls () but a lower precedence than attribute access (obj.attr). First, with single-argument functions spam, eggs and cheese, and a non-function arg: arg->eggs->spam->cheese() # equivalent to cheese(spam(eggs(arg))) eggs->spam->cheese # equivalent to lambda arg: cheese(spam(eggs(arg))) Then if, spam and eggs both took two arguments; eggs(arg1, arg2), spam(arg1, arg2) arg->eggs # equivalent to partial(eggs, arg) eggs->spam(a, b, c) # equivalent to spam(eggs(a, b), c) arg->eggs->spam(b,c) # equivalent to spam(eggs(arg, b), c) So you could think of -> as an extended partial operator. And this would naturally generalize to functions with even more arguments. The arguments would always be fed in the same order as in the equivalent function call, which makes for a nice rule of thumb. However, I suppose one would usually avoid combinations that are difficult to understand. Some examples that this would enable: # Example 1 from numpy import square, mean, sqrt rms = square->mean->sqrt # I think this order is fine because it is not @ # Example 2 (both are equivalent) spam(args)->eggs->cheese() # the shell-syntax analogy that Steven mentioned. # Example 3 # Last but not least, we would finally have this :) some_sequence->len() some_object->isinstance(MyType) -- Koos

1 0

Why don't CPython strings implement slicing using a view?
by Neil Girdhar 09 May '15

09 May '15

Since strings are constant, wouldn't it be much faster to implement string slices as a view of other strings? For clarity, I'm talking about CPython. I'm not talking about anything the user sees. The string views would still look like regular str instances to the user.

12 23