Mailman 3 March 2014 - Python-ideas

Infix matrix-multiply, but not general infix operators?
by Jared Grubb March 25, 2014

March 25, 2014

A couple months back, Andrew Barnet brought up the idea of adding a way to apply functions in an infix style. It really didnt gain much traction. (Subject line "Infix Functions") Nathaniel Smith has just proposed a PEP to add an infix matrix multiply operator, and everyone seems to love it. I honestly am surprised at the difference in reaction. Why are we so quick to add a single-purpose punctuation mark, but reject a named infix operator that works for many general cases? Is the matrix-multiply use case so special? I dont oppose the PEP, and I dont mean to derail it. And I know there was quite a bit of discussion on Andrew's email. But I cant help feel that Andrew's idea didnt get the appreciation it should. (But hey, I'm biased because I like the idea :)) Jared QUICK SUMMARY OF ANDREW'S EMAIL: (Not a proposal for syntax or naming) m `cross` n m `dot` n a `Pair` b a `Tree` (b `Tree` c `Tree` d) `Tree` e And of course the matrix multiply (and matrix div that was briefly discussed) are implementable too: m `mmul` n m `mdiv` n

14 20

Re: [Python-ideas] Python-ideas Digest, Vol 88, Issue 199
by Colin J. Williams March 24, 2014

March 24, 2014

#4 seems to refer to the Python basic system. However numpy.array does deal with multi-dimension arrays. On 23-Mar-2014 9:08 PM, python-ideas-request(a)python.org wrote: > ------------------------------ Message: 4 Date: Mon, 24 Mar 2014 > 11:49:43 +1100 From: Steven D'Aprano <steve(a)pearwood.info> To: > python-ideas(a)python.org Subject: Re: [Python-ideas] [RFC] draft PEP: > Dedicated infix operators for matrix multiplication and matrix power > Message-ID: <20140324004943.GX16526@ando> Content-Type: text/plain; > charset=us-ascii On Sun, Mar 23, 2014 at 11:40:10AM +0100, Sturla > Molden wrote: >> On 15/03/14 01:09, Antoine Pitrou wrote: >> >>> Really? That should be up to the third-party library implementing the @ >>> operator for its types, not to the language itself: Python _suggests_ >>> an use case for @, it doesn't mandate it (especially as there's no >>> appropriate data type in the stdlib). >> array.array is an appropriate type for supporting @ for matrix >> multiplication. > No it isn't. The PEP even discusses it: > > > [quote] > array objects cannot represent multidimensional data at all, > which makes ``__matmul__`` much less useful. Second, > providing a quality implementation of matrix multiplication > is highly non-trivial. Naive nested loop implementations > are very slow and providing one in CPython would just create > a trap for users. But the alternative -- providing a modern, > competitive matrix multiply -- would require that CPython link > to a BLAS library, which brings a set of new complications. > In particular, several popular BLAS libraries (including the > one that ships by default on OS X) currently break the use of > ``multiprocessing`` [#blas-fork]_. And finally, we'd have to > add quite a bit beyond ``__matmul__`` before ``memoryview`` > or ``array.array`` would be useful for numeric work -- like > elementwise versions of the other arithmetic operators, just > to start. > [end quote] > > >

3 2

alternative-implementation friendly changes to Python Launcher for Windows
by Vernon D. Cole March 23, 2014

March 23, 2014

A new issue was recently raised on the IronPython group addressing the idea of including a copy of the *Python Launcher for Windows* in the IronPython binary distribution. http://www.python.org/dev/peps/pep-0397/ I would like to get feedback from this group, also, before opening a work item for the suggestion. Please add any comments or suggestions you may have. Here is a partial clip from our discussion... vernondcole <http://www.codeplex.com/site/users/view/vernondcole> wrote Fri > at 2:32 AM > I made a clone of the git version of PLW to look this idea over. It is a > smallish C++ program and should not be too hard to patch to make > alternate-implementation friendly. The problem today is that it is CPython > specific and searches the Windows registry to determine which versions of > Python are present. Alternate implementations are supported only using > entries in the py.ini file and setting the #! line in your source code > approprietly. (Which works great. I even have mine launching perl scripts, > just to proove that it can.) > > I propose adding two features to PLW. > > 1) extend the first command-line switch to also pick items from the py.ini > file. I would like to type: > py -ipy myprogram.py > and have the command associated with "ipy" in my py.ini file executed. > > 2) PLW should have (in py.ini) a [default] section identifying which > command in the [commands] section should be run in the absence of a > command-line switch. > > Alternate implementations should then install (or modify) py.ini to > support their interpreter. > > The extended PLW version ought to be backported to the CPython > distribution, so that any implementation of Python will work. I don't think > that the CPython group would object. > > Note 1: I have not compared to make sure the stand-alone PLW is identical > with the Python 3.3 version. > Note 2: We need to make sure that PLW will work correctly even if no > CPython versions are present. > Note 3: I fear that I have just volunteered to write the patch. Is someone > else out there willing? It's been a very long time since I wrote commercial > quality C code. > > jdhardy <http://www.codeplex.com/site/users/view/jdhardy> wrote Fri at > 5:33 AM > Sounds good. I remember from the original PLW discussion they want it to > work for other implementations but weren't sure what would be needed. It > sounds like you're making that list. :) > > It's probably worth opening bugs on the Python tracker describing what > needs to change, since it's not IronPython specific. If you don't feel > comfortable writing the code perhaps someone over there can, or at least > review the code for you. >

2 1

overloading chained comparison
by Nathaniel Smith March 19, 2014

March 19, 2014

Hi python-ideas, Since Nick is being a killjoy and shutting down bikeshedding in the @ thread [1] until the numpy folks finish bikeshedding over it themselves [2], I thought I'd throw out another idea for... brainstorming [3]. Guido has suggested that while PEP 335 (overloading 'and', 'or', 'not') is rejected, he might be amenable to making chained comparisons like a < b < c overloadable [4]. The idea is that right now, a < b < c always expands to (a < b) and (b < c) and the 'and' forces boolean coercion. When working with arrays, '<' is often used elementwise, so we want the 'and' to apply elementwise as well; in numpy, this is done using '&' (since we can't overload 'and'). So if a, b, c are numpy arrays, we'd like this to instead expand to (a < b) & (b < c) Similar considerations apply to other systems that overload the comparison operators, e.g. DSLs for generating SQL queries. This seems like a good and straightforward enough idea to me in principle, but it's not at all clear to me what the best way to accomplish it in practice is. I thought of three options, but none is obviously Right. To have a way to talk about our options precisely, let's pretend that there's something called operator.chain_comparison, and that the way it works is that a < b <= c produces a call like operator.chain_comparison([a, b, c], [operator.lt, operator.le]) Right now, the semantics are: # Current def chain_comparison(args, ops): for i, op in enumerate(ops): result = op(args[i], args[i + 1]): # short-circuit if not result: return result return result (Of course in reality in CPython the compiler unrolls the loop and inlines this directly into the bytecode, but whatever, that's an implementation detail.) IDEA 1: simple, neat and (sort of) wrong Let's define a new special method __chain_and__; whenever we do a chain comparison, we check for the presence of this method, and if found, we call it instead of using 'and'. The intuition is that if we have a < b < c then this expands to either (a < b) and (b < c) or (a < b).__chain_and__(b < c) depending on whether hasattr((a < b), "__chain_and__"). Notice that the first case is short-circuiting, and the second is not. Which seems totally fine (contra PEP 335), because short-circuiting by definition requires that you make a boolean decision (quit early/don't quit early), and the whole point of these overloads is to avoid boolean coercion. I think in general the semantics here look like: # __chain_and__ def chain_comparison(args, ops): so_far = True for i, op in enumerate(ops): result = op(args[i], args[i + 1]) if hasattr(so_far, "__chain_and__"): so_far = so_far.__chain_and__(result) else: so_far = so_far and result # short-circuit, but only if the next reduction would use 'and': if not hasattr(so_far, "__chain_and__") and not so_far: return so_far return so_far So if 'arr' is a numpy array, then code like 0 < arr < 1 will now work great, because (0 < arr) will return an array of booleans, and this array will have the __chain_and__ method, so we'll end up doing (0 < arr).__chain_and__(arr < 1) and successfully return a single array of booleans indicating which locations in 'arr' are between 0 and 1. But -- suppose that we have, say, a GUI displaying a barchart, and we have a horizontal "threshold" line across the barchart that the user control. The idea is that they can move it up and down, and all the bars that it overlaps will change color, so we can easily see which bars are above the threshold and which are below it. So given the current threshold 't' (an ordinary float or int), and a 1d array holding the various bar heights, we can request the set of overlapping bars as: 0 < x < arr Okay, first problem is that this fails because here we don't want to do (0 < x).__chain_and__(x < arr) because (0 < x) is just False. So okay, let's say we enhance the above definition to allow for __rchain_and__, and we get (x < arr).__rchain_and__(0 < x) Great! So we implement it and we test it in our program and it works -- under ordinary conditions, this spits out a nice 1d array of booleans, our code continues on its merry way, using the values in this array to decide how each bar in our plot should be colored. Until the user slides the threshold line down below zero, at which point (0 < x) starts returning False, and we short-circuit out before even evaluating (x < arr). And then our code blows up because instead of getting an array like we expected, we just get False instead. Oops. __rchain_and__ is useless. So I guess the solution is to write arr > x > 0 which will always work? I'm not sure how common this case is in practice, but I find it somewhat disturbing that with the __chain_and__ approach, a < b < c and c > b > a can return completely different values even for completely well-behaved objects, and there's nothing the person writing overload methods can do about it. Certainly the bug in our original code is not obvious to the casual reader. (And AFAICT the proposal in PEP 335 also has this problem -- in fact PEP 335 basically is the same as this proposal -- so no help there.) IDEA 2: the FULLY GENERAL solution (uh oh) So we started with a call like operator.chain_comparison([a, b, c], [operator.lt, operator.le]) Maybe what we should do is treat *this* as the basic operator, and try calling a special __chain_comparison__ method on a, b, and/or c. Of course this immediately runs into a problem, because all python's existing operators have only 1 or 2 arguments [5], not an indefinite and varying number of arguments. So we can't use the standard __X__/__rX__ dispatch strategy. We need something like multimethod dispatch. (Cue thunder, ominous music.) I know this has been discussed to death, and I haven't read the discussion, so I guess people can have fun educating me if they feel like it. But what I'd suggest in this case is to do what we did in numpy to solve a similar problem [6]. Instead of using a "real" multimethod system, just directly generalize the __X__/__rX__ trick: when looking for a candidate object to call __chain_comparison__ on, take the leftmost one that (a) hasn't been tried, and (b) doesn't have another object which is a proper subclass of its type that also hasn't been tried. If you get NotImplemented, keep trying until you run out of candidates; then fall back to the traditional 'and'-based semantics. This does solve our problematic case above: only 'arr' implements __chain_comparison__, so we have 0 < x < arr becoming arr.__chain_comparison__([0, x, arr], [operator.lt, operator.lt]) and then that can just call the underlying rich comparison operators in a non-short-circuiting loop, and combine the results using '&' instead of 'and'. But it does require a somewhat odd looking piece of machinery for the dispatch. OPTION 3: the FULLY SPECIFIC solution A nice thing about the __chain_comparison__ method is that it will actually be identical for all array-like objects, no matter which library they're defined in. So, if there are multiple array-like objects from different libraries in a single chain, it doesn't matter who gets picked to handle the overall evaluation -- any one of them is good enough, and then the actual interoperability problems are delegated to the rich comparison methods, which already have to have a strategy for dealing with them. In fact, this same __chain_comparison__ can also probably be used for just about anyone who wants to define it -- e.g., I think most DB query DSLs are going to overload & to mean "and", right? So, maybe all we need is a flag that says: if you see an object with this flag anywhere in a chain, then switch to these semantics: # &-flag def chain_comparison(args, ops): for i, op in enumerate(ops): result = op(args[i], args[i + 1]): if i == 0: combined = result else: combined &= result return combined ...and otherwise, use the standard semantics. So that's what I got. None of these approaches seems obviously Right, but they're all at least sort of viable. Anyone else got any ideas? -n [1] https://mail.python.org/pipermail/python-ideas/2014-March/027174.html [2] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069444.html [3] "We're more of the love, bikeshedding, and rhetoric school. Well, we can do you bikeshedding and love without the rhetoric, and we can do you bikeshedding and rhetoric without the love, and we can do you all three concurrent or consecutive. But we can't give you love and rhetoric without the bikeshedding. Bikeshedding is compulsory." [4] https://mail.python.org/pipermail/python-dev/2012-March/117510.html [5] Except pow(), but that doesn't really count because it never dispatches on the third argument. [6] The next release of numpy allows non-numpy array-like classes to handle all numpy math functions in a generic way by dispatch to a special __numpy_ufunc__ method; I can provide more details on what's going on here if anyone's curious: http://docs.scipy.org/doc/numpy-dev/reference/arrays.classes.html#numpy.cla… -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org

3 3

A resources tracker ?
by Tarek Ziadé March 18, 2014

March 18, 2014

Hey ResourceWarning instances that are created in some classes' __del__ function, like FileIO are a great tool to track down a program bad behavior. In network programming, that's even more important to avoid crashes, or huge leaks. But some of them are very hard to fix because we don't get much context, we just get warnings at the end of the program execution, when gc.collect is called. sys:1: ResourceWarning: unclosed file <_io.FileIO name=18 mode='wb'> sys:1: ResourceWarning: unclosed file <_io.FileIO name=17 mode='rb'> Here I just know that somewhere, 2 file descriptors where not closed. What I'd like to be able to do is to track down the origin of those warnings. Since __del__ is called asynchronously, it's impossible to track it right now (or I don't know how) What we need is a way to keep track of any resource allocation *when it happens*. Here's an idea: let's add three private functions in Python's io: def __allocate_resource(fd) => records the file descriptor that was allocated, along with the current traceback. def __free_resource(fd) => removes the fd from the list. def __is_resource_allocated(fd) => tell if the resource is in the list. These three functions, plugged in somewhere in io's classes, could be used in conjunction with ResourceWarning: when __del__ is called, if the resource was not freed - we'd be able to know where it was created. Of course these functions are just a brain dump - I have no idea how io internals work. But unless I missed it, something like I've just described is missing in Python. Cheers Tarek

3 4

Re: [Python-ideas] Please reconsider the Boolean evaluation of midnight
by Alex Rodrigues March 18, 2014

March 18, 2014

I'm +1 for this idea. It's not about whether the style is good (which its not), but its fundamentally about the fact that it will fix bugs.

5 4

Function-like Modules (better control/introspection)
by C Anthony Risinger March 17, 2014

March 17, 2014

hello, could we make modules work more like this... https://gist.github.com/xtfxme/9556806 tl;dr: __code__ object available (potentially a __self__ object), reload by calling, makes working with modules more natural/safe! ENCLOSED: modules-next.py -- C Anthony #----------------------------------------------------------------------------------------( modules-next.py ) # encoding: utf-8 # # modules-next # # C Anthony Risinger import sys m_name = 'modules_next' m_source = r"""\ if __name__ == '{0}': from . import __call__ as reexec from . import __code__ as code from . import __dict__ as ns print('>>> {{0}}: {{1}}\n{{2}}\n'.format(__name__, code, ns.keys())) __name__ = 'modules_next_reloaded' reexec() print('>>> {{0}}: {{1}}\n{{2}}\n'.format(__name__, code, ns.keys())) else: print('!!! __name__ == {{0}}\n'.format(__name__)) def throw(): raise Exception(__name__) """.format(m_name) m_code = compile(m_source, m_name, 'exec') m_dict = { '__file__': __file__ + '.next', '__name__': m_name, '__path__': list(), '__doc__': None, } #...bind namespace/functions module = eval('lambda: None', m_dict) #...automatically expose as attributes module.__dict__ = module.__globals__ #...must be set twice, __code__ sees __dict__, but we see descriptor module.__name__ = m_name #...redefine the function body! module.__code__ = m_code #...yay! we haz legitimate module! sys.modules[m_name] = module print('--* importing...') import modules_next print('>>> {0}: {1}\n{2}\n'.format( __name__, modules_next.__code__, modules_next.__dict__.keys(), )) print('--* importing (for real this time)...') #...import/reload by calling our func-y-module module() print('>>> {0}: {1}\n{2}\n'.format( __name__, modules_next.__code__, modules_next.__dict__.keys(), )) print('--* throwing...') modules_next.throw()

4 7

for-loop-if like list comps have?
by Christopher Welborn March 15, 2014

March 15, 2014

mylist = ['apple', 'banana', 'orange', 'grapefruit'] # Why is this okay... for item in [x for x in mylist if 'p' in x]: print(item) # But this isn't? for item in mylist if 'p' in item: SyntaxError: invalid syntax # Instead you have to do another nesting level.. for item in mylist: if 'p' in item: print(item) # Or another way. for item in mylist: if 'p' not in item: continue print(item) ...And there is 'filter', 'lambdas', and whatever else to achieve the same result. But the list comprehension is already closely related to a for-loop, and it seems natural to go from: [x for x in mylist if x] to: for x in mylist if x: Just an idea, sorry if it has been mentioned before. -- \¯\ /¯/\ \ \/¯¯\/ / / Christopher Welborn (cj) \__/\__/ / cjwelborn at live·com \__/\__/ http://welbornprod.com

3 4

[RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power
by Mark Daoust March 15, 2014

March 15, 2014

*>Aaron Meurer* asmeurer at gmail.com <python-ideas%40python.org?Subject=Re%3A%20%5BPython-ideas%5D%20Fwd%3A%20%5BRFC%5D%20draft%20PEP%3A%20Dedicated%20infix%20operators%0A%20for%20matrix%20multiplication%20and%20matrix%20power&In-Reply-To=%3C9e2519ad-0940-478c-bff0-39f47ab1e826%40googlegroups.com%3E> > *>Sat Mar 15 01:48:46 CET 2014* > > > Like Robert I have the suspicion that the best option is to make @ > > right-associative and place it just above (more tightly binding) than > > > > *. But I'll poll numpy-discussion and friends and see if anyone has > > ideas for more objective measures. > > > > I guess a common case would be a*B@x, where a is a scalar. Is it more > efficient or numerically stable to evaluate that one way or the other? I'm not a numerical linear algebra expert, but I disagree. If your matrix code needs to be optimized, there's no way around thinking about your specific situation. Optimizing matrix expressions is a tricky problem. <http://en.wikipedia.org/wiki/Matrix_chain_multiplication> http://en.wikipedia.org/wiki/Matrix_chain_multiplication http://www.youtube.com/watch?v=nVt24G_2VC0 If you want a different order use parenthesis, or build a symbolic expression. I don't think either choice of priority, or associativity will be the right often enough be worth an affront to the "principal of least surprise". Things are nice and clear the way they are. >From the docs http://docs.python.org/3.4/reference/expressions.html#binary-arithmetic-ope… : """The binary arithmetic operations have the conventional priority levels... Apart from the power operator[s], there are only two levels, one for multiplicative operators and one for additive operators""" let's keep it like this: Vote P/E/MD/AS not P/E/M/MD/AS. I think that if there is a reason to change is Greg is on the right track: *>Greg Ewing* greg.ewing at canterbury.ac.nz <python-ideas%40python.org?Subject=Re%3A%20%5BPython-ideas%5D%20%5BRFC%5D%20draft%20PEP%3A%20Dedicated%20infix%20operators%20for%0A%20matrix%20multiplication%20and%20matrix%20power&In-Reply-To=%3C53243F9D.1060802%40canterbury.ac.nz%3E> *>Sat Mar 15 12:55:09 CET 2014* >Often,matrix @ vector represents a linear operator acting on an element of a vector space. When you chain them, > A @ B @ C @ v >conceptually represents acting on v with C, then B, then A. PS: >*Nathaniel Smith* njs at pobox.com <python-ideas%40python.org?Subject=Re%3A%20%5BPython-ideas%5D%20Fwd%3A%20%5BRFC%5D%20draft%20PEP%3A%20Dedicated%20infix%20operators%0A%20for%20matrix%20multiplication%20and%20matrix%20power&In-Reply-To=%3CCAPJVwBmm%2BWDCpsRDAVOZ%3DYgRX5u7HfWZ%2BCs2NWdHev9_v8_PsQ%40mail.gmail.com%3E> >*Fri Mar 14 22:21:12 CET 2014* > >The 'matrix @@ -1' notation will probably be a nice win for >beginners and other less-sophisticated programmers ... There's a spot where I like the Facade approach: return an object that only has one method, numpy.solve as __mul__. Make it hard to do badly. >[x.M * y] This is an interesting suggestion! I think it hasn't received full consideration before ... >but this might well be the next-best thing to a real operator. Maybe It is a real operator, it's just spelled ".M*" instead of "@" ;) Thanks for all the work on this Nathaniel. Mark Daoust

1 0

Re: [Python-ideas] Fwd: [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power
by Aaron Meurer March 15, 2014

March 15, 2014

On Friday, March 14, 2014 7:46:11 PM UTC-5, Aaron Meurer wrote: On Friday, March 14, 2014 4:21:12 PM UTC-5, Nathaniel Smith wrote: > On Fri, Mar 14, 2014 at 5:53 PM, Guido van Rossum <gu...(a)python.org> > wrote: > >> > I have now read the PEP, and I think it's good. I think it's a waste of > time > >> > to keep bikeshedding on the choice of operator -- @ is the best > compromise. > >> > I do have a few specific notes: > >> > > >> > - Right associativity is not unheard of in Python. E.g. **. If you > >> > think that for other reasons @ should be right associative, don't > >> > let Python's tradition stop you. But then you need to decide which > >> > of * and @ binds more tightly -- e.g. does a*b@c mean a*(b@c) or > >> > (a*b)@c? And if you choose the latter, it follows that a@b*c means > >> > a@(b*c) -- is that okay? (And similar examples exist for the other > >> > choice.) > >> > Like Robert I have the suspicion that the best option is to make @ > >> right-associative and place it just above (more tightly binding) than > >> *. But I'll poll numpy-discussion and friends and see if anyone has > ideas for more objective measures. > I guess a common case would be a*B@x, where a is a scalar. Is it more efficient or numerically stable to evaluate that one way or the other? Aaron Meurer > > - Did you consider a duck-typing (is that the word?) attribute? > >> > E.g. a*b is elementwise multiplication; a.M*b must be used for > >> > matrix multiplication. (Your use of .T as "transpose" made me think > >> > of this.) Of course the question is, can you get those packages > >> > that currently use * for matrix multiply to comply? (I don't consider > >> > this a serious counter-proposal. But you list a bunch of rejected > >> > alternatives; this could be in that list. > >> > This is an interesting suggestion! I think it hasn't received full > >> consideration before because the tangle between numpy.ndarray and > >> numpy.matrix means that the most obvious implementation for an > >> ndarray.M attribute would be to return a full-fledged numpy.matrix > >> object... and no-one wants to encourage proliferation of numpy.matrix > >> objects. But returning a tiny special-purpose class that only > >> implements __mul__ would avoid that objection. At that point it's > >> basically a nicer version of the "user-defined infix" '*dot*' operator > >> idea. It has similar problems with needing an unaesthetically magical > >> implementation, producing a proliferation of special classes (one > >> extra one for each array type), requiring an allocation on every call, > >> etc., but this might well be the next-best thing to a real operator. > >> > All in all, I think we'd rather have a real operator, so if you're > >> happy to go with @ then I won't put lots of effort into finding > >> horrible problems that force us to reject .M ;-), but I'll certainly > >> add it to the PEP in any case. > >> > > - Is @@ really necessary? It seems you are adding it mostly because > >> > it's cute and because of the parallel with **, not because it is > >> > actually important enough to add new syntax. And then later you use > >> > it as an argument for @, which seems a bit circular. Also, if we > >> > were to make @ right-associative, the parallel with ** is already > >> > imperfect. > >> > @@ hasn't received as much attention as the rest of the proposal, so > >> I'll check in with numpy-discussion etc. on this as well. But my > >> personal feeling is +0 on @@ -- all else being equal, it's nicer to > >> have it than not. Is all else equal? Given the existence of @, the > >> increase in language complexity is small (or arguably negative, since > >> people who know *, **, @ may be surprised to find @@ missing, and have > >> to memorize its non-existence as an extra rule); the opportunity cost > >> is low (given the existence of @ I can't imagine we'll want to use the > >> token @@ for something else later); and @@ will be used in real life, > >> if not as often as @ itself -- 'vec @@ 2' for squared Euclidean length > >> probably won't be too uncommon, 'matrix @@ n' gets used for things > >> like simulating random walks on graphs or other markov chains, and the > >> 'matrix @@ -1' notation will probably be a nice win for beginners and > >> other less-sophisticated programmers who just want to get some > >> computation done in a way that doesn't require them to keep a more > >> complicated mapping between math and code notation in their head or > >> caring about numerical details. I think of @@ being like, say, '%=' -- > >> nothing one would ever add syntax for in isolation, but if designing > >> an overall system of operators then it makes more sense. > >> > Probably in the end it just comes down to your aesthetic judgement > >> :-). Numeric folk will be fine either way. > >> > (And I wouldn't consider @@ a *strong* argument for spelling '@' as > >> '@'; it's just mentioned in that section because there aren't really > >> *any* strong arguments for preferring one spelling versus another, we > >> have to make a decision, and so a weak argument is better than > >> nothing. Two useful operators for the complexity cost of one is a good > >> deal? :shrug: Obviously if @@ gets dropped I'll drop that bullet point > >> as well.) > >> > > - For better counts of usages, perhaps Sourcegraph.com might help? It > >> > is a source code query engine that has a Python parser and (limited) > >> > type inference built in (also separately available as pysonar on > >> > github IIRC). To be clear, I don't need more numbers to be convinced. > >> > Oo, that is shiny, thanks for the tip. > >> > > Once we've decided on associativity and @@, I'm ready to accept. > >> > Wonderful to hear! Thanks for giving this so much time and attention > >> (on no warning)! > >> > -n > >> > -- > >> Nathaniel J. Smith > >> Postdoctoral researcher - Informatics - University of Edinburgh > >> http://vorpus.org > >> _______________________________________________ > >> Python-ideas mailing list > >> Python...(a)python.org > >> https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >

1 0