Re: [Python-Dev] Infix operators
On Saturday 26 July 2008 01:23:17 am Nick Coghlan wrote: Sebastien Loisel wrote: However, just for posterity (and I'm not going to pursue the argument further than this), I'll say this. The problem of determining the meaning (or overridability or whatever) of x=4$6 is the same as the problem of determining the meaning of x=fooz(4,6). Since it's not a good argument against user-defined functions, I don't see it as a good argument against user-defined operators. The namespace of usefully mnemonic function names is infinitely larger than that of usefully mnemonic punctuation marks. User-defined functions are good, but once you have those there is no reason to have user-defined operators *as well*. Cheers, Nick. Most mathematicians would disagree with you. I'll grant that it tends to make the code extremely obscure to those who don't work in the field, but it tends to make it much clearer to those who do so work. OTOH, it's also true that there aren't sufficient punctuation symbols. E.g. math people drafted capital sigma as sum of a series, etc. Therefore it seems to me that the appropriate thing is to create a convention that bar-somethingprintable-bar should be interpreted as a user defined operation, e.g. |+| or |@#|. The first one is reasonable as matrix multiplication, the second as some user defined operation that hasn't yet been specified (in this context). And since such things don't yet have a secret name I would suggest that they be defined either via an ordinary def, or via a def with their name in quotes, i.e., either: def |+| or def |+| If an ordinary functional reference is desireable (probably) there could be a decorators that assigned the name, and possibly the precedence, e.g.: @name=madd @precedence=+ def |+| (a, b): etc. The main drawback that I see is that code that relies heavily on this approach would become much less readable to anyone not in the particular field. Think of the first time you encountered the curl or del operators, or even the kronecker delta. OTOH, it seems far too late in the development process to be inserting such a change in Python 2.6 or 3.0. If this is important to you, you should probably propose it for 2.7/3.1. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
On Sun, Jul 27, 2008 at 19:43, Charles Hixson [EMAIL PROTECTED] wrote: Therefore it seems to me that the appropriate thing is to create a convention that bar-somethingprintable-bar And the something-printable shows the main flaw of this approach. Mathematics indeed uses a lot of symbols to make things clear and unambigous. Many of these are hard to print in a line, even with unicode, and entering and editing this from a keyboard would be very difficult. So to make this scheme useable you would have to limit yourself to ascii-codes, and then most of the point goes away since you can't use the proper symbols anyway, and ambiguity is reintroduced. It seems to me that mathematicians who need these things would be better served by dedicated maths-software. Just my 2 cents. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Charles Hixson wrote: [...] OTOH, it seems far too late in the development process to be inserting such a change in Python 2.6 or 3.0. If this is important to you, you should probably propose it for 2.7/3.1. It's been too late for over three months now, and the suggestions I've seen so far are all way impractical anyway. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Sebastien Loisel wrote: However, just for posterity (and I'm not going to pursue the argument further than this), I'll say this. The problem of determining the meaning (or overridability or whatever) of x=4$6 is the same as the problem of determining the meaning of x=fooz(4,6). Since it's not a good argument against user-defined functions, I don't see it as a good argument against user-defined operators. The namespace of usefully mnemonic function names is infinitely larger than that of usefully mnemonic punctuation marks. User-defined functions are good, but once you have those there is no reason to have user-defined operators *as well*. Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Greg Ewing said: I would actually be in favour of adding a matrix multiplication operator That would be helpful to me, for my students as well as my papers. Sincerely, -- Sébastien Loisel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Sebastien Loisel wrote: Greg Ewing said: I would actually be in favour of adding a matrix multiplication operator That would be helpful to me, for my students as well as my papers. Perhaps I'm nobody, but I think this would be ridiculous. Matrices are not native objects to the language. There is no type(matrix). The notion of what makes a Python object a matrix is a convention and to have built-in operators dedicated to such objects makes no sense. There are multiple ways to stuff matrices into Python. Please submit a PEP for a type(matrix) first. Until a matrix is a first-order object in Python, there is no logic to making operators for them. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
On Fri, Jul 25, 2008 at 12:06 AM, Scott Dial [EMAIL PROTECTED] wrote: Perhaps I'm nobody, but I think this would be ridiculous. Matrices are not native objects to the language. There is no type(matrix). The notion of what makes a Python object a matrix is a convention and to have built-in operators dedicated to such objects makes no sense. There are multiple ways to stuff matrices into Python. Please submit a PEP for a type(matrix) first. Until a matrix is a first-order object in Python, there is no logic to making operators for them. Though I would personally find a matrix multiplication operator useful, I have to agree with this. Anyway, it is easy to define pseudo-operators in Python; just create an Operator class and implement its __mul__ and __rmul__ methods appropriately (there are recipes for this around somewhere). Then you can define various custom multiplication operators with syntax like this: A *matrixmul* B A *dot* B A *cross* B A *elementwise* B Some other fun possibilities: A +concat+ B A /solve/ B A **left_inverse** (-1) A **right_inverse** (-1) x **tetrate** y n |choose| k Fredrik ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Scott Dial wrote: Perhaps I'm nobody, but I think this would be ridiculous. Matrices are not native objects to the language. Why should that matter? We already have things like sum(), which operates on any sequence of numbers, without needing a special array of numbers data type. I don't see why one shouldn't be able to perform matrix multiplication on a plausible representation of a matrix using the existing built-in sequence types. Until a matrix is a first-order object in Python, there is no logic to making operators for them. If there were a dedicated matrix type, there would actually be *less* reason to have a new operator, since that type could just implement * as matrix multiplication. However, there are disadvantages to that, which become apparent when numpy is considered. There are good reasons for wanting * to mean elementwise multiplication of numpy arrays. There are also good reasons for wanting to use numpy arrays as matrices, since you get the benefit of all the other powerful things that numpy can do with arrays. You can use a matrix type that's based somehow on a numpy array, but there are problems with that too. E.g. if you add a matrix and a plain numpy array, what type should the result be? If plain numpy arrays can be used directly as matrices, that problem goes away. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Fredrik Johansson wrote: Anyway, it is easy to define pseudo-operators in Python; A *matrixmul* B A *dot* B A *cross* B A *elementwise* B Urg. This is another one of those recipes that I consider is too clever for its own good. Very nice in theory, but I would never use it in real life. What's more, it doesn't address the real problem at hand, which is providing a notation for matrix multiplication that is concise enough to be used *very* frequently -- like multiple times in every line of code that manipulates matrices. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Greg Ewing wrote: Scott Dial wrote: Perhaps I'm nobody, but I think this would be ridiculous. Matrices are not native objects to the language. Why should that matter? We already have things like sum(), which operates on any sequence of numbers, without needing a special array of numbers data type. I would argue that Python contains a array of some_type data type. That sum() performs a left-fold of __add__ on the array is completely independent of them being numbers. In all fact, they could be any type that supports __add__/__radd__ or even a mix of types. I do not believe array of numbers to be analogically equivalent to a matrix of numbers. We have an array of type in Python, we do not have a matrix of type in Python. sum() is not an operator, it is a builtin; the suggestion was for there to be an operator, not a builtin. If you want to suggest there be a mmul() builtin, then perhaps there is a viable answer there, despite the lack of a matrix of type still. I don't see why one shouldn't be able to perform matrix multiplication on a plausible representation of a matrix using the existing built-in sequence types. What is a plausible representation of a matrix? Is it a list of lists? Row-major (m[1][2]) or column-major (m[2][1])? Is it a dictionary of tuple'd indices (m[1,2])? Also, You went on to talk about wanting to using numpy.array. How does this not make it clear that there is not a case of TOOWTDI? -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
On Thu, Jul 24, 2008 at 7:08 PM, Greg Ewing [EMAIL PROTECTED] wrote: Fredrik Johansson wrote: Anyway, it is easy to define pseudo-operators in Python; A *matrixmul* B A *dot* B A *cross* B A *elementwise* B Urg. This is another one of those recipes that I consider is too clever for its own good. Very nice in theory, but I would never use it in real life. That's unfortunate ;), because it's available in Python today, and with the common local caching of globals, can be as short as 3 characters (M for matrixmul, D for dot, X for cross, E for elementwise). What's more, it doesn't address the real problem at hand, which is providing a notation for matrix multiplication that is concise enough to be used *very* frequently -- like multiple times in every line of code that manipulates matrices. This is the first time anyone has mentioned conciseness in this thread. And what's a 3 character operator between friends? The and and not operators don't seem to be bothered by three characters. ;) - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Scott Dial wrote: I would argue that Python contains a array of some_type data type. That sum() performs a left-fold of __add__ on the array is completely independent of them being numbers. That's not strictly true -- it explicitly refuses to operate on strings (or at least it did last time I heard). Guido has said that he *intends* it to only be used for numbers, even if it happens to accidentally do something with other types. However, as I envisage it, the @ operator wouldn't be restricted to numbers either -- it would do whatever the * and + operations do on the elements. sum() is not an operator, it is a builtin; the suggestion was for there to be an operator, not a builtin. That's true, and it means that the built-in implementation wouldn't have as wide applicability as the sum() function, since it would be restricted to lists and tuples (and perhaps array.array instances). But I don't think that's a fatal flaw -- if you create your own sequence type, you have to take steps if you want to be able e.g. to use + to concatenate them, and nobody complains about that. If you want to suggest there be a mmul() builtin, then perhaps there is a viable answer there No, that's not a viable answer to people who want a matrix multiplication operator. They want an operator because a function is nowhere near concise enough. Telling these people they have to use a function to multiply matrices is like telling them they have to use a function to multiply numbers. What is a plausible representation of a matrix? Is it a list of lists? That's one. A tuple of tuples would be another. Row-major (m[1][2]) or column-major (m[2][1])? Pick one and stick to it. Probably row-major, since it's what the numpy matrixmultiply function uses. Is it a dictionary of tuple'd indices (m[1,2])? I think dictionaries would have to be excluded, because there's no easy way of finding out the dimensions, it's not obvious what to do about missing elements, etc. Also, You went on to talk about wanting to using numpy.array. Yes -- what's wrong with that? How does this not make it clear that there is not a case of TOOWTDI? I think there *is* one obvious way of representing a matrix, or any 2D array, using built-in Python types, or rather two ways -- a list of lists if you want mutability, or a tuple of tuples if you want immutability. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Josiah Carlson wrote: This is the first time anyone has mentioned conciseness in this thread. I thought it more or less went without saying. After all, if conciseness isn't a goal, there's nothing wrong with a plain function call, which can be as short as 3 characters as well. The trouble is that, for the people who badly want a matrix multiplication operator, 3 characters is far too long! -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Infix operators
Dear Pythonistas, I've googled for this but I wasn't able to find anything definitive. I was recently looking at scipy to see if I could use it in stead of MATLAB for my class on numerical PDEs, but I noticed that there's some difficulty related to the notation; mainly, the matrix multiplication, and the linear solver (i.e., MATLAB's \ operator). After giving it some thought, I've decided to hold back for now and use MATLAB. Since scipy/numeric python have been around for a while and some of it is even integrated in Python 2.5, I'm sure this conversation has happened before, so please just educate me. Now I think that there's always going to be people wanting more and more operators in Python (although the operators I'm talking about are privileged -- the Chinese were using matrices some 2000 years ago), so I was thinking that it would be simpler to have a way for defining new infix operators, which would simply be binary functions whose names are punctuation marks; see any language with this feature, e.g., Haskell. Now since this is such a simple idea, I'm guessing it occured to pythonistas at some point in 1992, and got voted down and that decision has now become scripture. Is that the case? The one thing which I found was PEP 211 http://www.python.org/dev/peps/pep-0211/, which has an amazing quote from James Rawlings. His comment about inv is completely absurd, and while he claims not to know \ and /, he is quoted as an authority on these operators. This particular PEP should probably be deleted from history. For a more authoritative explanation, a quick search yields MathWorks' own Loren Shure: http://blogs.mathworks.com/loren/2007/05/16/purpose-of-inv/ Essentially, in almost all applications, inv(A) is entirely wrong. You can ask any numerical analyst who works with large problems, and they will confirm it. One of the main reason is that, even if A is sparse, inv(A) is full. That absurdity aside, if I were a language designer, I would be reticent to add one operator to Python (like in PEP 211), because there will always be more operators that people want (how long until someone asks for an operator for the Kronecker product or the convolution?) But why not put in this infix possibility? Sincerely, -- Sébastien Loisel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
On Wed, Jul 23, 2008 at 2:14 PM, Sebastien Loisel [EMAIL PROTECTED] wrote: Dear Pythonistas, I've googled for this but I wasn't able to find anything definitive. I was recently looking at scipy to see if I could use it in stead of MATLAB for my class on numerical PDEs, but I noticed that there's some difficulty related to the notation; mainly, the matrix multiplication, and the linear solver (i.e., MATLAB's \ operator). After giving it some thought, I've decided to hold back for now and use MATLAB. Since scipy/numeric python have been around for a while and some of it is even integrated in Python 2.5, I'm sure this conversation has happened before, so please just educate me. Now I think that there's always going to be people wanting more and more operators in Python (although the operators I'm talking about are privileged -- the Chinese were using matrices some 2000 years ago), so I was thinking that it would be simpler to have a way for defining new infix operators, which would simply be binary functions whose names are punctuation marks; see any language with this feature, e.g., Haskell. Now since this is such a simple idea, I'm guessing it occured to pythonistas at some point in 1992, and got voted down and that decision has now become scripture. Is that the case? The one thing which I found was PEP 211 http://www.python.org/dev/peps/pep-0211/, which has an amazing quote from James Rawlings. His comment about inv is completely absurd, and while he claims not to know \ and /, he is quoted as an authority on these operators. This particular PEP should probably be deleted from history. For a more authoritative explanation, a quick search yields MathWorks' own Loren Shure: http://blogs.mathworks.com/loren/2007/05/16/purpose-of-inv/ Essentially, in almost all applications, inv(A) is entirely wrong. You can ask any numerical analyst who works with large problems, and they will confirm it. One of the main reason is that, even if A is sparse, inv(A) is full. That absurdity aside, if I were a language designer, I would be reticent to add one operator to Python (like in PEP 211), because there will always be more operators that people want (how long until someone asks for an operator for the Kronecker product or the convolution?) But why not put in this infix possibility? Why not add the possibility for arbitrary infix operators? Others will most likely disagree with me, but I would claim that adding arbitrary infix operators are a great way to destroy readability. What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's a custom infix operator. But where is it defined? In the module? In some other module that is imported? Can I override or do some pre-processing to the arguments and pass it on to the previously defined $ operator? So many questions, none of which tell me what '$' does. Really though, PEP 211 was a perfect example of a k-line function that someone attempted to make syntax that really didn't need to be syntax. And arguably, any infix operator will need to result in a lookup for the new infix operator, which will be as fast (or slow) as a globals lookup, so you may as well define your operator as a two-argument function, which has defined semantics, and can be imported and passed just like all functions defined for years. I would argue current operators are *convenience* for the 99%+ majority of mathematical operations done in Python, with well-defined and understood semantics in the 99%+ cases they are used for. Further, the addition of further infix operators are, strictly speaking, a domain-specific language, which Python (as a language) doesn't frown upon, but doesn't encourage either. If you still think that X \ Y would honestly make Python a better language, I would ask you if logix (http://www.livelogix.net/logix/intro.html) would suit you better. It seems to allow you to use arbitrary punctuation for operators. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Dear Josiah, Thank you for your email. On Wed, Jul 23, 2008 at 7:11 PM, Josiah Carlson [EMAIL PROTECTED] wrote: What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's a custom infix operator. But where is it defined? In the module? In some other module that is imported? Can I override or do some pre-processing to the arguments and pass it on to the previously defined $ operator? So many questions, none of which tell me what '$' does. My question is really what the history of this thing is and what sort of opposition there is to this idea, in the python community. From your email, I suspect that this conversation has already taken place. I'm not going to become a python developer/politician and try to push this, my job involves teaching and research in mathematics and the programming language is just a tool. If I want to put food on my family (in the words of a wise man), I can't really spend a whole lot of time on this mailing list debating this. However, just for posterity (and I'm not going to pursue the argument further than this), I'll say this. The problem of determining the meaning (or overridability or whatever) of x=4$6 is the same as the problem of determining the meaning of x=fooz(4,6). Since it's not a good argument against user-defined functions, I don't see it as a good argument against user-defined operators. Of course, obviously the LISP people have decided that fooz(4,6) (or rather, (fooz 4 6)) is okay, and 4$6 is not, so who am I to dispute that. If you still think that X \ Y would honestly make Python a better Well, I'm not arguing for adding one more special-purpose operator, because probably the need for more operators will never end. If arbitrary operators were defined like ordinary functions, they could be brought in with the import numeric or whatever, and docstrings could be looked up, etc... language, I would ask you if logix (http://www.livelogix.net/logix/intro.html) would suit you better. It seems to allow you to use arbitrary punctuation for operators. Thank you for the pointer. I have taken a look and it does look interesting, on first blush I would love to use that language. The main thing is that I worry about being out on the fringe, using a language that nobody uses, and which may get abandoned without warning (like Sun abandoned `self'), or be buggier just because people don't use it... Although I love metaprogramming and I would use it if it were in python, I don't really need to go that far (arbitrary infix operators would suffice to me.) Sincerely, -- Sébastien Loisel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
On Wed, Jul 23, 2008 at 4:48 PM, Sebastien Loisel [EMAIL PROTECTED] wrote: On Wed, Jul 23, 2008 at 7:11 PM, Josiah Carlson [EMAIL PROTECTED] wrote: language, I would ask you if logix (http://www.livelogix.net/logix/intro.html) would suit you better. It seems to allow you to use arbitrary punctuation for operators. Thank you for the pointer. I have taken a look and it does look interesting, on first blush I would love to use that language. The main thing is that I worry about being out on the fringe, using a language that nobody uses, and which may get abandoned without warning (like Sun abandoned `self'), or be buggier just because people don't use it... Have you considered OCaml? (http://en.wikipedia.org/wiki/Ocaml) It's in reasonably broad use and is actively maintained, and it allows user-defined infix operators. A programming language can't be all things to all people. That's why there's room in the world for more than one. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Dear Curt, Thank you for your email. Have you considered OCaml? (http://en.wikipedia.org/wiki/Ocaml) It's I have. I've considered a lot of languages, but OCaml isn't for me. My current language is MATLAB. Python is pretty close in syntax, and it's widely accepted, so you can teach students Python and they can go out and use it. You can also publish a paper and write a code snippet without having to explain the syntax. I'm not trying to go out on the blistering leading edge of computer language sophistication; that would not be good for my students, and it would not be good for my research. For most of my programs, what I need is a language where you don't need to give types or declare variables, because that just takes up space and obscures the math. So I need a mainstream dynamic language like Python or MATLAB. OCaml is not dynamic, and linear algebra in OCaml is a pain in the neck because of the explosion of the number of operators for various pairs of operand types. Sincerely, -- Sébastien Loisel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Sebastien Loisel wrote: Essentially, in almost all applications, inv(A) is entirely wrong. You can ask any numerical analyst who works with large problems, and they will confirm it. One of the main reason is that, even if A is sparse, inv(A) is full. This argues for a function such as solve(A, b). It doesn't argue for an infix operator. But why not put in this infix possibility? Guido is on record as opposing any kind of macros or other extensible syntax, and this probably comes under the same heading. Besides which there are technical difficulties, such as how the parser is supposed to know the precedence of these user-defined operators. To address your original problem, I believe that numpy comes with a matrix type that defines * as matrix multiplication. That's the usual Python solution to these kinds of things -- rather than invent a new operator, invent a new type that behaves the way you want. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Dear Greg, Thanks for your email. Guido is on record as opposing any kind of macros or other extensible syntax, and this probably comes under the same heading. Thanks, that's exactly what I was looking for when I asked: Now since this is such a simple idea, I'm guessing it occured to pythonistas at some point in 1992, and got voted down and that decision has now become scripture. Is that the case? Case closed. Sincerely, -- Sébastien Loisel PS: This argues for a function such as solve(A, b). It doesn't argue for an infix operator. I know, I was demolishing PEP 211, not trying to support my point. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Josiah Carlson wrote: What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's a custom infix operator. But where is it defined? It's not quite as bad as that -- it would be defined by the relevant operator method on one of the operands. But a convention would be needed for mapping arbitary non- alphanumeric sequences to method names, and it's not obvious how to do that. But the main technical problem I see is that of precedence. It would have to be declared somehow, or a declaration imported from another module. If it's imported, then parsing a module can't be done in isolation any more, since it depends on the contents of other modules. Things could get very messy. Really though, PEP 211 was a perfect example of a k-line function that someone attempted to make syntax that really didn't need to be syntax. It looks like a case of someone wanting a matrix multiplication operator in numpy, and then hunting around for something to make it mean in Python. I would actually be in favour of adding a matrix multiplication operator, but I would make it mean matrix multiplication in Python as well, operating on anything that can be treated as a 2D sequence. Why matrix multiplication in particular? Because it's the one thing that you do all the time with matrices for which there isn't an available operator. I think this one addition could be justified on the grounds of very wide usage. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
On Wed, Jul 23, 2008, Sebastien Loisel wrote: [...] I was thinking that it would be simpler to have a way for defining new infix operators, [...] python-dev is the wrong place for this discussion. Please use either comp.lang.python or python-ideas. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
