Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 2011-12-16, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Eelco wrote: the actual english usage of the phrase, which omits the negation completely :). (I could care less) No, that's the American usage. That's the _ignorant_ American usage. Americans with a clue use the couldn't version. I won't comment on the relative sizes of the two groups. The English usage is I couldn't care less, which has the advantage of actually making sense. Indeed. -- Grant Edwards grant.b.edwardsYow! HUGH BEAUMONT died at in 1982!! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 16, 3:58 am, MRAB pyt...@mrabarnett.plus.com wrote: On 16/12/2011 02:14, alex23 wrote: Eelcohoogendoorn.ee...@gmail.com wrote: To tie it back in with python language design; all the more reason not to opt for pseudo-backwards compatibility. If python wants a remainder function, call it 'remainder'. Not 'rem', not 'mod', and certainly not '%'. Python has def, del, int, str, len, and so on. rem or mod (Ada has both, I believe) would be in keeping with the language. def and del are keywords, and thus in another league. Having shorthand notation for types is somewhat defensible, though I believe I would prefer a more verbose form there too; how often to you encounter these in python anyway? len is a bit of an eeysore to me too; I understand having it as a builtin is a matter of optimization or something, but I do wish we would be given the option of just saying list.length Good luck with the PEP. Its the more pythonic way; a self-describing name, rather than poorly defined or poorly understood cryptology. Although practicality beats purity. I'm still utterly agog that anyone finds the operator % confusing. In financial circles it could be an operator for calculating percentages, eg. 5 % x would be 5 percent of x. It's an oddity, but an established one. :-) Well yes, thats the only argument ive heard so far that resonated with me. These syntax details are not a very big deal, and backwards compatibility with yourself is quite a big deal. Its nice to keep 'what ought to have been done' and 'what ought we to do' seperate in such discussions. Im not sure we ought to change these syntax details (I mean relating to mod and such), but I am quite sure of what I would have done if I could go back in time. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 16, 6:30 am, alex23 wuwe...@gmail.com wrote: On Dec 16, 3:01 pm, Chris Angelico ros...@gmail.com wrote: And I would be most sorry to see % renamed to mod in Python. Hello, %s! My favourite number is %d. mod (Fred,42) # This just looks wrong. Finally we can give this operator a more fitting name - I propose 'inject' - and put an end to this insane desire to leverage off pre- existing knowledge of other languages. Furthermore, I suggest that no two languages should ever have identical semantics, just to avoid potential confusion. New concepts for all! Dont get me started on that one. Its that I never work with strings... 'leverage of pre-existing knowledge'... I would hardly call the particular names of functions the knowledge about a language. The only argument that bears any weight with me is backwards compatibility with itself. Pseudo-backwards compatibility with other languages, I couldnt not care less for. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 16, 3:25 pm, Eelco hoogendoorn.ee...@gmail.com wrote: Pseudo-backwards compatibility with other languages, I couldnt not care less for. Double negations n Goedelian situations have interesting implications (tho here its triple) -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 16 dec, 18:38, rusi rustompm...@gmail.com wrote: On Dec 16, 3:25 pm, Eelco hoogendoorn.ee...@gmail.com wrote: Pseudo-backwards compatibility with other languages, I couldnt not care less for. Double negations n Goedelian situations have interesting implications (tho here its triple) Heh. Well at least my extra (unintended) negation is semantically consistent with the actual english usage of the phrase, which omits the negation completely :). (I could care less) But ill stick with trying to change one language at a time :). -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
Eelco wrote: the actual english usage of the phrase, which omits the negation completely :). (I could care less) No, that's the American usage. The English usage is I couldn't care less, which has the advantage of actually making sense. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 17, 12:49 am, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Eelco wrote: the actual english usage of the phrase, which omits the negation completely :). (I could care less) No, that's the American usage. The English usage is I couldn't care less, which has the advantage of actually making sense. -- Greg Oh thanks for clearing that up, never noticed a division along these lines. And yes, I agree; 'I couldnt care less' makes much more sense. 'I could care less' can only make sense if you interpret it sarcastically, as if omitting an 'oh wait, I cant', but that does not seem congruent with how its typically pronounced. Just another case of suboptimal language design; but where can you submit EEP's? -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
In article 2420abd7-7d91-4bc9-bb3b-d8ec1680e...@u32g2000yqe.googlegroups.com, Eelco hoogendoorn.ee...@gmail.com wrote: And yes, I agree; 'I couldnt care less' makes much more sense. 'I could care less' can only make sense if you interpret it sarcastically, as if omitting an 'oh wait, I cant', but that does not seem congruent with how its typically pronounced. I care so little about the subject that I am unwilling to spend one of my precious apostrophes to properly express the sentiment -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Fri, 16 Dec 2011 11:40:11 -0800, Eelco wrote: On 16 dec, 18:38, rusi rustompm...@gmail.com wrote: On Dec 16, 3:25 pm, Eelco hoogendoorn.ee...@gmail.com wrote: Pseudo-backwards compatibility with other languages, I couldnt not care less for. Double negations n Goedelian situations have interesting implications (tho here its triple) Heh. Well at least my extra (unintended) negation is semantically consistent with the actual english usage of the phrase, which omits the negation completely :). (I could care less) Oh please. I could care less is not English. That's American. Here in Australia, we follow the English practice of saying that we couldn't care less. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Fri, Dec 16, 2011 at 7:54 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Fri, 16 Dec 2011 11:40:11 -0800, Eelco wrote: On 16 dec, 18:38, rusi rustompm...@gmail.com wrote: On Dec 16, 3:25 pm, Eelco hoogendoorn.ee...@gmail.com wrote: Pseudo-backwards compatibility with other languages, I couldnt not care less for. Double negations n Goedelian situations have interesting implications (tho here its triple) Heh. Well at least my extra (unintended) negation is semantically consistent with the actual english usage of the phrase, which omits the negation completely :). (I could care less) Oh please. I could care less is not English. That's American. Here in Australia, we follow the English practice of saying that we couldn't care less. Well the phrase is still somewhat controversial in the US. I never heard it until age 19 (in 1966) and have always been somewhat disdainful of those using it. But it appears to be hopeless. http://articles.boston.com/2010-10-24/lifestyle/29303907_1_care-peeves-decades -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 15, 4:43 am, rusi rustompm...@gmail.com wrote: On Dec 14, 10:15 pm, Eelco hoogendoorn.ee...@gmail.com wrote: 'Kindof' off-topic, but what the hell :). deja-vu We keep having these debates -- so I wonder how off-topic it is... And so do famous CSists:http://research.microsoft.com/en-us/um/people/gurevich/opera/123.pdf /deja-vu Well, you are right, there are some deep links here. My view of what is wrong with mainstream mathematics is its strange interpretation of the semantics of classical logic. (And I dont think any other schools get it quite right either; I think finitists may avoid the mistakes of others, but are rightfully accussed of being needlessly restrictive, for instance) This is best illustrated by means of the principle of explosion. It rests on assuming a contradiction, and then assigning rather peculiar semantics to them. What is typically left unstated are the semantics of symbol lookup, but apparently it is implicitly understood one can pick whatever value upon encountering a contradicting symbol. There is no well defined rule for the lookup of a twice-defined symbol. Of course the sane thing to do, to a mind grown up around computer languages, upon encountering a twice defined symbol, is not to continue to generate deductions from both branches, but to throw an exception and interrupt the specific line of reasoning that depends on this contradicting symbol right then and there. Conceptually, we can see something is wrong with these undefined semantics right away. A logical system that allows you to draw conclusions as to where the pope shits from assertions about natural numbers could not more obviously be broken. If you dont have this broken way of dealing with contradictions, one does not have to do one of many silly and arbitrary things to make infinity work, such as making a choice between one-to-one correspondence and subset-relations for determining the cardinality of a set; one can simply admit the concept of infinity, while useful, is not consistent, keep the contradiction well handled instead of having it explode in your face (or explode into the field of transfinite analysis; a consequece of 'dealing' with these issues by rejecting the intuitively obviously true relation between subset relations and cardinality), and continue reasoning with the branches of your argument that you are interested in. In other words, what logic needs is a better exception-handling system, which completes the circle with programming languages quite nicely. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 12/14/11 12:32 PM, Steven D'Aprano wrote: On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote: I'm not misunderstanding any argument. There was no argument. There was a blanket pronouncement that _in mathematics_ mod is not a binary operator. I should learn to challenge such pronouncements and ask what the problem is. Maybe next time. So this was *one* person making that claim? I understand that, in general, mathematicians don't have much need for a remainder function in the same way programmers do -- modulo arithmetic is far more important. But there's a world of difference between saying In mathematics, extracting the remainder is not important enough to be given a special symbol and treated as an operator and saying remainder is not a binary operator. The first is reasonable; the second is not. The professional mathematicians that I know personally don't say that remainder is not a binary operator. They *do* say that modulo is not an operator in mathematics just because they have reserved that word and the corresponding notation to define the congruence relations. So for example, the following two statements are equivalent: 42 = 2 mod 5 2 = 42 mod 5 The mod 5 notation modifies the entire equation (or perhaps the = sign if you like to think about it like that), not the term it is immediately next to. Python's % operator is a binary operator that binds to a particular term, not the whole equation. The following two are not equivalent statements: 42 == 2 % 5 2 == 42 % 5 It's mostly kvetching on their part that programming language designers misunderstood the notation and applied the name to something that is confusingly almost, but not quite, the same thing. They aren't saying that you couldn't *define* such an operator; they would just prefer that we didn't abuse the name. But really, it's their fault for using notation that looks like an operator. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Thu, Dec 15, 2011 at 9:47 PM, Robert Kern robert.k...@gmail.com wrote: 42 = 2 mod 5 2 = 42 mod 5 It might make more sense to programmers if you think of it as written: 42 = 2, mod 5 2 = 42, mod 5 ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 15, 2:44 pm, Eelco hoogendoorn.ee...@gmail.com wrote: In other words, what logic needs is a better exception-handling system, which completes the circle with programming languages quite nicely. :) Cute... but dangerously recursive (if taken literally) Remember that logic is the foundation of programming language semantics. And your idea (suggests) that programming language semantics be made (part of) the foundation of logic. Of course I assume you are not being very literal. Still the dangers of unnoticed circularity are often... well unnoticed :-) eg. McCarthy gave the semantics of lisp in lisp -- a lisp interpreter in lisp is about a page of code. It probably was a decade before someone realized that the same semantics would 'work' for lazy or applicative (eager) order evaluation. This then begs the question what exactly it means for that semantics to 'work'... -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 15, 3:58 pm, Chris Angelico ros...@gmail.com wrote: On Thu, Dec 15, 2011 at 9:47 PM, Robert Kern robert.k...@gmail.com wrote: 42 = 2 mod 5 2 = 42 mod 5 It might make more sense to programmers if you think of it as written: 42 = 2, mod 5 2 = 42, mod 5 ChrisA For the record I should say that the guy who taught me abstract algebra, said about as much: He said that the notation a == b mod n should be written as a ==n b (read the == as 3 horizontal lines and the n as a subscript) -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 15, 11:47 am, Robert Kern robert.k...@gmail.com wrote: On 12/14/11 12:32 PM, Steven D'Aprano wrote: On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote: I'm not misunderstanding any argument. There was no argument. There was a blanket pronouncement that _in mathematics_ mod is not a binary operator. I should learn to challenge such pronouncements and ask what the problem is. Maybe next time. So this was *one* person making that claim? I understand that, in general, mathematicians don't have much need for a remainder function in the same way programmers do -- modulo arithmetic is far more important. But there's a world of difference between saying In mathematics, extracting the remainder is not important enough to be given a special symbol and treated as an operator and saying remainder is not a binary operator. The first is reasonable; the second is not. The professional mathematicians that I know personally don't say that remainder is not a binary operator. They *do* say that modulo is not an operator in mathematics just because they have reserved that word and the corresponding notation to define the congruence relations. So for example, the following two statements are equivalent: 42 = 2 mod 5 2 = 42 mod 5 The mod 5 notation modifies the entire equation (or perhaps the = sign if you like to think about it like that), not the term it is immediately next to. Python's % operator is a binary operator that binds to a particular term, not the whole equation. The following two are not equivalent statements: 42 == 2 % 5 2 == 42 % 5 It's mostly kvetching on their part that programming language designers misunderstood the notation and applied the name to something that is confusingly almost, but not quite, the same thing. They aren't saying that you couldn't *define* such an operator; they would just prefer that we didn't abuse the name. But really, it's their fault for using notation that looks like an operator. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco Thanks Robert, I think you cut right through the confusion there. To tie it back in with python language design; all the more reason not to opt for pseudo-backwards compatibility. If python wants a remainder function, call it 'remainder'. Not 'rem', not 'mod', and certainly not '%'. Its the more pythonic way; a self-describing name, rather than poorly defined or poorly understood cryptology. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 15, 11:56 am, rusi rustompm...@gmail.com wrote: On Dec 15, 2:44 pm, Eelco hoogendoorn.ee...@gmail.com wrote: In other words, what logic needs is a better exception-handling system, which completes the circle with programming languages quite nicely. :) Cute... but dangerously recursive (if taken literally) Remember that logic is the foundation of programming language semantics. And your idea (suggests) that programming language semantics be made (part of) the foundation of logic. Of course I assume you are not being very literal. Still the dangers of unnoticed circularity are often... well unnoticed :-) Well, logic as a language has semantics, one way or the other. This circularity is a general theme in epistemology, and one that fits well with the view of deduction-induction as a closed loop cycle. Knowledge does not flow from axioms to theorems; axioms without an encompassing context are meaningless symbols. Its a body of knowledge as a whole that should be put to the test; the language and the things we express in it are inseperable. (the not-quite-famous-enough Quine in a nutshell) The thing is that our semantics of logic are quite primitive; cooked up in a time where people spent far less time thinking about these things, and having a far narrower base of experience to draw ideas from. They didnt have the luxury of already having grown up studying a dozen formal languages before embarking on creating their own. It other words, the semantics of logic is a legacy piece of crap, but an insanely firmly entrenched one. I mean, there are many sensible ways of defining semantics of conflicting symbols, but you'll find on studying these things that the guys who (often implicitly) laid down these rules didnt even seemed to have consciously thought about them. Not because they were stupid; far from it, but for similar reasons as to why the x86 architecture wasnt concieved of the day after the invention of the transistor. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
rusi writes: On Dec 15, 3:58 pm, Chris Angelico wrote: On Thu, Dec 15, 2011 at 9:47 PM, Robert Kern wrote: 42 = 2 mod 5 2 = 42 mod 5 It might make more sense to programmers if you think of it as written: 42 = 2, mod 5 2 = 42, mod 5 ChrisA For the record I should say that the guy who taught me abstract algebra, said about as much: He said that the notation a == b mod n should be written as a ==n b (read the == as 3 horizontal lines and the n as a subscript) I think the modulus is usually given in parentheses and preferably some whitespace: in text, a == b (mod n), using == for the triple -, and in a display: a == b(mod n). I think even a == b == c (mod n), without repeating the modulus every time. (A subscript sounds good if the modulus is simple. Perhaps it often is.) That way it does not even look like a binary operator. I think Graham, Knuth, and Patashnik play it nicely in their book Concrete Mathematics, where they have both mods: the congruence relation, and the binary operator. The book is targeted for computer scientists. As if mathematicians didn't use the exact same notations for different purposes, even in the same context, and often with no problems whatsoever as long as all parties happen to know what they are talking about. Often the uses are analogous, but at least the two main uses of (x,y) differ wildly. (So Knuth uses (x .. y) for the interval, but he is a programmer.) -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 12/15/2011 6:04 AM, rusi wrote: On Dec 15, 3:58 pm, Chris Angelicoros...@gmail.com wrote: On Thu, Dec 15, 2011 at 9:47 PM, Robert Kernrobert.k...@gmail.com wrote: 42 = 2 mod 5 2 = 42 mod 5 It might make more sense to programmers if you think of it as written: 42 = 2, mod 5 2 = 42, mod 5 Better, using ascii text, would be 42 =mod5 2 where =mod is a parameterized equivalence relation that is coarser than = (which is =mod-infinity). divmod(a,inf) = 0,a. =mod1 is the most coarse relation in that it make every count equivalent. divmod(a,1) = a,1. For the record I should say that the guy who taught me abstract algebra, said about as much: He said that the notation a == b mod n should be written as a ==n b (read the == as 3 horizontal lines and the n as a subscript) The 3 horizontal line symbol is often used for equivalence relations other than =. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
Eelco hoogendoorn.ee...@gmail.com wrote: To tie it back in with python language design; all the more reason not to opt for pseudo-backwards compatibility. If python wants a remainder function, call it 'remainder'. Not 'rem', not 'mod', and certainly not '%'. Good luck with the PEP. Its the more pythonic way; a self-describing name, rather than poorly defined or poorly understood cryptology. Although practicality beats purity. I'm still utterly agog that anyone finds the operator % confusing. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 16/12/2011 02:14, alex23 wrote: Eelcohoogendoorn.ee...@gmail.com wrote: To tie it back in with python language design; all the more reason not to opt for pseudo-backwards compatibility. If python wants a remainder function, call it 'remainder'. Not 'rem', not 'mod', and certainly not '%'. Python has def, del, int, str, len, and so on. rem or mod (Ada has both, I believe) would be in keeping with the language. Good luck with the PEP. Its the more pythonic way; a self-describing name, rather than poorly defined or poorly understood cryptology. Although practicality beats purity. I'm still utterly agog that anyone finds the operator % confusing. In financial circles it could be an operator for calculating percentages, eg. 5 % x would be 5 percent of x. It's an oddity, but an established one. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Fri, Dec 16, 2011 at 1:58 PM, MRAB pyt...@mrabarnett.plus.com wrote: In financial circles it could be an operator for calculating percentages, eg. 5 % x would be 5 percent of x. It's an oddity, but an established one. :-) And I would be most sorry to see % renamed to mod in Python. Hello, %s! My favourite number is %d. mod (Fred,42) # This just looks wrong. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 16, 3:01 pm, Chris Angelico ros...@gmail.com wrote: And I would be most sorry to see % renamed to mod in Python. Hello, %s! My favourite number is %d. mod (Fred,42) # This just looks wrong. Finally we can give this operator a more fitting name - I propose 'inject' - and put an end to this insane desire to leverage off pre- existing knowledge of other languages. Furthermore, I suggest that no two languages should ever have identical semantics, just to avoid potential confusion. New concepts for all! -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 15, 2011 8:01 PM, MRAB pyt...@mrabarnett.plus.com wrote: Python has def, del, int, str, len, and so on. rem or mod (Ada has both, I believe) would be in keeping with the language. I think I would have to object to rem purely on the basis that it denotes comments in BASIC. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 14, 4:18 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: They might not be willing to define it, but as soon as we programmers do, well, we did. Having studied the contemporary philosophy of mathematics, their concern is probably that in their minds, mathematics is whatever some dead guy said it was, and they dont know of any dead guy ever talking about a modulus operation, so therefore it 'does not exist'. You've studied the contemporary philosophy of mathematics huh? How about studying some actual mathematics before making such absurd pronouncements on the psychology of mathematicians? The philosophy was just a sidehobby to the study of actual mathematics; and you are right, studying their works is the best way to get to know them. Speaking from that vantage point, I can say with certainty that the vast majority of mathematicians do not have a coherent philosophy, and they adhere to some loosely defined form of platonism. Indeed that is absurd in a way. Even though you may trust these people to be perfectly functioning deduction machines, you really shouldnt expect them to give sensible answers to the question of which are sensible axioms to adopt. They dont have a reasoned answer to this, they will by and large defer to authority. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
Steven D'Aprano writes: On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote: [quoting Jussi Piitulainen jpiit...@ling.helsinki.fi] They recognize modular arithmetic but for some reason insist that there is no such _binary operation_. But as I said, I don't understand their concern. (Except the related concern about some programming languages, not Python, where the remainder does not behave well with respect to division.) I've never come across this, and frankly I find it implausible that *actual* mathematicians would say that. Likely you are misunderstanding a technical argument about remainder being a relation rather than a bijunction. The argument would go something like this: (For 'bijunction', read 'function'.) I'm not misunderstanding any argument. There was no argument. There was a blanket pronouncement that _in mathematics_ mod is not a binary operator. I should learn to challenge such pronouncements and ask what the problem is. Maybe next time. But you are right that I don't know how actual mathematicians these people are. I'm not a mathematician. I don't know where to draw the line. A Finnish actual mathematician stated a similar prejudice towards mod as a binary operator in a Finnish group. I asked him what is wrong with Knuth's definition (remainder after flooring division), and I think he conceded that it's not wrong. Number theorists just choose to work with congruence relations. I have no problem with that. He had experience with students who confused congruences modulo some modulus with a binary operation, and mixed up their notations because of that. That is a reason to be suspicious, but it is a confusion on the part of the students. Graham, Knuth, Patashnik contrast the two concepts explicitly, no confusion there. And I know that there are many ways to define division and remainder so that x div y + x rem y = x. Boute's paper cited in [1] advocates a different one and discusses others. [1] http://en.wikipedia.org/wiki/Modulo_operation But I think the argument there are several such functions, therefore, _in mathematics_, there is no such function is its own caricature. Remainder is not uniquely defined. For example, the division of -42 by -5 can be written as either: 9*-5 + 3 = -42 8*-5 + -2 = -42 so the remainder is either 3 or -2. Hence remainder is not a bijection (1:1 function). Is someone saying that _division_ is not defined because -42 div -5 is somehow both 9 and 8? Hm, yes, I see that someone might. The two operations, div and rem, need to be defined together. (There is no way to make remainder a bijection. You mean it is not a function if it is looked at in a particular way.) [The square root was relevant but I snipped it.] Similarly, we can sensibly define the remainder or modulus operator to consistently return a non-negative remainder, or to do what Python does, which is to return a remainder with the same sign as the divisor: ... There may be practical or logical reasons for preferring one over the other, but either choice would make remainder a bijection. One might even define two separate functions/operators, one for each behaviour. Scheme is adopting flooring division, ceiling-ing division, rounding division, truncating division, centering division, and the Euclidean division advocated by Boute, and the corresponding remainders. There is no better way to bring home to a programmer the points that there are different ways to define these, and they come as div _and_ rem. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
Nick Dokos writes: Jussi Piitulainen wrote: They recognize modular arithmetic but for some reason insist that there is no such _binary operation_. But as I said, I don't understand their concern. (Except the related concern about some programming languages, not Python, where the remainder does not behave well with respect to division.) They are probably arguing that it's uniquely defined only on ZxN and that there are different conventions to extend it to ZxZ (the programming languages problem that you allude to above - although I don't know what you mean by does not behave well wrt division). I think Boute [1] says Standard Pascal or some such language failed to have x div y + x rem y = x, but I can't check the reference now. That at least waes what I had in mind. Having x rem y but leaving it underspecified is another such problem: then it is unspecified whether the equation holds. [1] http://en.wikipedia.org/wiki/Modulo_operation If you choose one convention and stick to it, it becomes a well-defined binary operation. That's what I'd like to think. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 14 dec, 09:56, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: Steven D'Aprano writes: On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote: [quoting Jussi Piitulainen jpiit...@ling.helsinki.fi] They recognize modular arithmetic but for some reason insist that there is no such _binary operation_. But as I said, I don't understand their concern. (Except the related concern about some programming languages, not Python, where the remainder does not behave well with respect to division.) I've never come across this, and frankly I find it implausible that *actual* mathematicians would say that. Likely you are misunderstanding a technical argument about remainder being a relation rather than a bijunction. The argument would go something like this: (For 'bijunction', read 'function'.) I'm not misunderstanding any argument. There was no argument. There was a blanket pronouncement that _in mathematics_ mod is not a binary operator. I should learn to challenge such pronouncements and ask what the problem is. Maybe next time. But you are right that I don't know how actual mathematicians these people are. I'm not a mathematician. I don't know where to draw the line. A Finnish actual mathematician stated a similar prejudice towards mod as a binary operator in a Finnish group. I asked him what is wrong with Knuth's definition (remainder after flooring division), and I think he conceded that it's not wrong. Number theorists just choose to work with congruence relations. I have no problem with that. He had experience with students who confused congruences modulo some modulus with a binary operation, and mixed up their notations because of that. That is a reason to be suspicious, but it is a confusion on the part of the students. Graham, Knuth, Patashnik contrast the two concepts explicitly, no confusion there. And I know that there are many ways to define division and remainder so that x div y + x rem y = x. Boute's paper cited in [1] advocates a different one and discusses others. [1] http://en.wikipedia.org/wiki/Modulo_operation But I think the argument there are several such functions, therefore, _in mathematics_, there is no such function is its own caricature. Indeed. Obtaining a well defined function is just a matter of picking a convention and sticking with it. Arguably, the most elegant thing to do is to define integer division and remainder as a single operation; which is not only the logical thing to do mathematically, but might work really well programmatically too. The semantics of python dont really allow for this though. One could have: d, r = a // b But it wouldnt work that well in composite expressions; selecting the right tuple index would be messy and a more verbose form would be preferred. However, performance-wise its also clearly the best solution, as one often needs both output arguments and computing them simultaniously is most efficient. At least numpy should have something like: d, r = np.integer_division(a, b) And something similar in the math module for scalars. Remainder is not uniquely defined. For example, the division of -42 by -5 can be written as either: 9*-5 + 3 = -42 8*-5 + -2 = -42 so the remainder is either 3 or -2. Hence remainder is not a bijection (1:1 function). Is someone saying that _division_ is not defined because -42 div -5 is somehow both 9 and 8? Hm, yes, I see that someone might. The two operations, div and rem, need to be defined together. (There is no way to make remainder a bijection. You mean it is not a function if it is looked at in a particular way.) Surjection is the word you are looking for That is, if one buys the philosophy of modernists like bourbaki in believing there is much to be gained by such pedantry. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 14, 1:56 pm, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: Is someone saying that _division_ is not defined because -42 div -5 is somehow both 9 and 8? Hm, yes, I see that someone might. The two operations, div and rem, need to be defined together. - Haskell defines a quot-rem pair and a div-mod pair as follows: (from http://www.haskell.org/onlinereport/basic.html) (x `quot` y)*y + (x `rem` y) == x (x `div` y)*y + (x `mod` y) == x `quot` is integer division truncated toward zero, while the result of `div` is truncated toward negative infinity. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Wed, Dec 14, 2011 at 10:47 PM, rusi rustompm...@gmail.com wrote: `quot` is integer division truncated toward zero, while the result of `div` is truncated toward negative infinity. All these problems just because of negative numbers. They ought never to have been invented. At least nobody rounds toward positive infinity... oh wait, that's legal too. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com wrote: On Dec 14, 4:18 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: They might not be willing to define it, but as soon as we programmers do, well, we did. Having studied the contemporary philosophy of mathematics, their concern is probably that in their minds, mathematics is whatever some dead guy said it was, and they dont know of any dead guy ever talking about a modulus operation, so therefore it 'does not exist'. You've studied the contemporary philosophy of mathematics huh? How about studying some actual mathematics before making such absurd pronouncements on the psychology of mathematicians? The philosophy was just a sidehobby to the study of actual mathematics; and you are right, studying their works is the best way to get to know them. Speaking from that vantage point, I can say with certainty that the vast majority of mathematicians do not have a coherent philosophy, and they adhere to some loosely defined form of platonism. Indeed that is absurd in a way. Even though you may trust these people to be perfectly functioning deduction machines, you really shouldnt expect them to give sensible answers to the question of which are sensible axioms to adopt. They dont have a reasoned answer to this, they will by and large defer to authority. Please come down from your vantage point for a few moments and consider how insulting your remarks are to people who have devoted most of their intellectual energy to the study of mathematics. So you've studied a bit of mathematics and a bit of philosophy? Good start, keep working at it. You think that every mathematician should be preoccupied with what axioms to adopt, and why? Mathematics is a very large field of study and yes, some mathematicians are concerned with these issues (they are called logicians) but for most it isn't really about axioms. Mathematics is bigger than the axioms that we use to formalise it. Most mathematicians do not need to care about what precise axiomatisation underlies the mathematics that they practise because they are thinking on a much higher level. Just like we do not worry about what machine language instruction actually performs each step of the Python program we are writing. You say that mathematicians defer to authority, but do you really think that thousands of years of evolution and refinement in mathematics are to be discarded lightly? I think not. It's good to have original ideas, to pursue them and to believe in them, but it would be foolish to think that they are superior to knowledge which has been accumulated over so many generations. You claim that mathematicians have a poor understanding of philosophy. It may be so for many of them, but how is this a problem? I doesn't prevent them from having a deep understanding of their field of mathematics. Do philosophers have a good understanding of mathematics? Cheers, -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
Eelco writes: On 14 dec, 09:56, Jussi Piitulainen wrote: But I think the argument there are several such functions, therefore, _in mathematics_, there is no such function is its own caricature. Indeed. Obtaining a well defined function is just a matter of picking a convention and sticking with it. Arguably, the most elegant thing to do is to define integer division and remainder as a single operation; which is not only the logical thing to do mathematically, but might work really well programmatically too. The semantics of python dont really allow for this though. One could have: d, r = a // b But it wouldnt work that well in composite expressions; selecting the right tuple index would be messy and a more verbose form would be preferred. However, performance-wise its also clearly the best solution, as one often needs both output arguments and computing them simultaniously is most efficient. The current Scheme draft does this. For each rounding method, it provides an operation that provides both the quotient and the remainder, an operation that provides the quotient, and an operation that provides the remainder. The both-values operation is more awkward to compose, as you rightly say. It's just a matter of naming them all. Python has a good default integer division as the pair of operators // and %. Python also supports the returning of several values from functions as tuples. It can be done. Is someone saying that _division_ is not defined because -42 div -5 is somehow both 9 and 8? Hm, yes, I see that someone might. The two operations, div and rem, need to be defined together. (There is no way to make remainder a bijection. You mean it is not a function if it is looked at in a particular way.) Surjection is the word you are looking for Um, no, I mean function. The allegedly alleged problem is that there may be two (or more) different values for f(x,y), which makes f not a _function_ (and the notation f(x,y) maybe inappropriate). Surjectivity is as much beside the point as bijectivity, but I think we have surjectivity for rem: Z * Z - Z if we use a definition that produces both positive and negative remainders, or rem: Z * Z - N if we have non-negative remainders (and include 0 in N, which is another bone of contention). We may or may not want to exclude 0 as the modulus, or divisor if you like. It is at least a special case. It's injectivity that fails: 9 % 4 == 6 % 5 == 3 % 2, while Python quite sensibly has (9, 4) != (6, 5) != (3, 2). (How I love the chaining of the comparisons.) That is, if one buys the philosophy of modernists like bourbaki in believing there is much to be gained by such pedantry. I think something is gained. Not sure I would call it philosophy. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote: Steven D'Aprano writes: On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote: [quoting Jussi Piitulainen jpiit...@ling.helsinki.fi] They recognize modular arithmetic but for some reason insist that there is no such _binary operation_. But as I said, I don't understand their concern. (Except the related concern about some programming languages, not Python, where the remainder does not behave well with respect to division.) I've never come across this, and frankly I find it implausible that *actual* mathematicians would say that. Likely you are misunderstanding a technical argument about remainder being a relation rather than a bijunction. The argument would go something like this: (For 'bijunction', read 'function'.) Oops, you're right of course. It's been about 20 years since I've needed to care about the precise difference between a bijection and a function, and I made a mistake. And then to add to my shame, I also misspelt bijection. I'm not misunderstanding any argument. There was no argument. There was a blanket pronouncement that _in mathematics_ mod is not a binary operator. I should learn to challenge such pronouncements and ask what the problem is. Maybe next time. So this was *one* person making that claim? I understand that, in general, mathematicians don't have much need for a remainder function in the same way programmers do -- modulo arithmetic is far more important. But there's a world of difference between saying In mathematics, extracting the remainder is not important enough to be given a special symbol and treated as an operator and saying remainder is not a binary operator. The first is reasonable; the second is not. But you are right that I don't know how actual mathematicians these people are. I'm not a mathematician. I don't know where to draw the line. A Finnish actual mathematician stated a similar prejudice towards mod as a binary operator in a Finnish group. I asked him what is wrong with Knuth's definition (remainder after flooring division), and I think he conceded that it's not wrong. Number theorists just choose to work with congruence relations. I have no problem with that. Agreed. [...] (There is no way to make remainder a bijection. You mean it is not a function if it is looked at in a particular way.) You're right, of course -- remainder cannot be 1:1. I don't know what I was thinking. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 14 dec, 12:55, Arnaud Delobelle arno...@gmail.com wrote: On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com wrote: On Dec 14, 4:18 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: They might not be willing to define it, but as soon as we programmers do, well, we did. Having studied the contemporary philosophy of mathematics, their concern is probably that in their minds, mathematics is whatever some dead guy said it was, and they dont know of any dead guy ever talking about a modulus operation, so therefore it 'does not exist'. You've studied the contemporary philosophy of mathematics huh? How about studying some actual mathematics before making such absurd pronouncements on the psychology of mathematicians? The philosophy was just a sidehobby to the study of actual mathematics; and you are right, studying their works is the best way to get to know them. Speaking from that vantage point, I can say with certainty that the vast majority of mathematicians do not have a coherent philosophy, and they adhere to some loosely defined form of platonism. Indeed that is absurd in a way. Even though you may trust these people to be perfectly functioning deduction machines, you really shouldnt expect them to give sensible answers to the question of which are sensible axioms to adopt. They dont have a reasoned answer to this, they will by and large defer to authority. Please come down from your vantage point for a few moments and consider how insulting your remarks are to people who have devoted most of their intellectual energy to the study of mathematics. So you've studied a bit of mathematics and a bit of philosophy? Good start, keep working at it. Thanks, I intend to. You think that every mathematician should be preoccupied with what axioms to adopt, and why? Of course I dont. If you wish to restrict your attention to the exploration of the consequences of axioms others throw at you, that is a perfectly fine specialization. Most mathematicians do exactly that, and thats fine. But that puts them in about as ill a position to judged what is, or shouldnt be defined, as the average plumber. Compounding the problem is not just that they do not wish to concern themselves with the inductive aspect of mathematics, they would like to pretend it does not exist at all. For instance, if you point out to them a 19th century mathematician used very different axioms than a 20th century one, (and point out they were both fine mathematicians that attained results universally celebrated), they will typically respond emotionally; get angry or at least annoyed. According to their pseudo-Platonist philosophy, mathematics should not have an inductive side, axioms are set in stone and not a human affair, and the way they answer the question as to where knowledge about the 'correct' mathematical axioms comes from is by an implicit or explicit appeal to authority. They dont explain how it is that they can see 'beyond the platonic cave' to find the 'real underlying truth', they quietly assume somebody else has figured it out in the past, and leave it at that. You say that mathematicians defer to authority, but do you really think that thousands of years of evolution and refinement in mathematics are to be discarded lightly? I think not. It's good to have original ideas, to pursue them and to believe in them, but it would be foolish to think that they are superior to knowledge which has been accumulated over so many generations. For what its worth; insofar as my views can be pidgeonholed, im with the classicists (pre-20th century), which indeed has a long history. Modernists in turn discard large swaths of that. Note that its largely an academic debate though; everybody agrees that 1+1=2. But there are some practical consequences; if I were the designated science-Tsar, all transfinite-analysist would be out on the street together with the homeopaths, for instance. You claim that mathematicians have a poor understanding of philosophy. It may be so for many of them, but how is this a problem? I doesn't prevent them from having a deep understanding of their field of mathematics. Do philosophers have a good understanding of mathematics? As a rule of thumb: absolutely not, no. I dont think I can think of any philosopher who turned his attention to mathematics that ever wrote anything interesting. All the interesting writers had their boots on mathematical ground; Quine, Brouwer, Weyl and the earlier renaissance men like Gauss and contemporaries. The fragmentation of disciplines is infact a major problem in my opinion though. Most physicists take their mathematics from the ivory- math tower, and the mathematicians shudder at the idea of listning back to see which of what they cooked up is actually anything but mental masturbation, in the meanwhile cranking out more gibberish about alephs. If any well-reasoned philosophy enters into
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote: Arguably, the most elegant thing to do is to define integer division and remainder as a single operation; which is not only the logical thing to do mathematically, but might work really well programmatically too. The semantics of python dont really allow for this though. One could have: d, r = a // b That would be: divmod(17, 5) (3, 2) But it wouldnt work that well in composite expressions; selecting the right tuple index would be messy and a more verbose form would be preferred. However, performance-wise its also clearly the best solution, as one often needs both output arguments and computing them simultaniously is most efficient. Premature optimization. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 14 dec, 13:22, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: Is someone saying that _division_ is not defined because -42 div -5 is somehow both 9 and 8? Hm, yes, I see that someone might. The two operations, div and rem, need to be defined together. (There is no way to make remainder a bijection. You mean it is not a function if it is looked at in a particular way.) Surjection is the word you are looking for Um, no, I mean function. The allegedly alleged problem is that there may be two (or more) different values for f(x,y), which makes f not a _function_ (and the notation f(x,y) maybe inappropriate). Surjectivity is as much beside the point as bijectivity, but I think we have surjectivity for rem: Z * Z - Z if we use a definition that produces both positive and negative remainders, or rem: Z * Z - N if we have non-negative remainders (and include 0 in N, which is another bone of contention). We may or may not want to exclude 0 as the modulus, or divisor if you like. It is at least a special case. It's injectivity that fails: 9 % 4 == 6 % 5 == 3 % 2, while Python quite sensibly has (9, 4) != (6, 5) != (3, 2). (How I love the chaining of the comparisons.) My reply was more to the statement you quoted than to yours; sorry for the confusion. Yes, we have surjectivity and not injectivity, thats all I was trying to say. That is, if one buys the philosophy of modernists like bourbaki in believing there is much to be gained by such pedantry. I think something is gained. Not sure I would call it philosophy. Agreed; its more the notion that one stands to gain much real knowledge by writing volumnius books about these matters that irks me, but I guess thats more a matter of taste than philosophy. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
rusi writes: On Dec 14, 1:56 pm, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: Is someone saying that _division_ is not defined because -42 div -5 is somehow both 9 and 8? Hm, yes, I see that someone might. The two operations, div and rem, need to be defined together. - Haskell defines a quot-rem pair and a div-mod pair as follows: (from http://www.haskell.org/onlinereport/basic.html) (x `quot` y)*y + (x `rem` y) == x (x `div` y)*y + (x `mod` y) == x `quot` is integer division truncated toward zero, while the result of `div` is truncated toward negative infinity. Exactly what I mean. (I gave an incorrect equation but meant this.) -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
Steven D'Aprano writes: On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote: I'm not misunderstanding any argument. There was no argument. There was a blanket pronouncement that _in mathematics_ mod is not a binary operator. I should learn to challenge such pronouncements and ask what the problem is. Maybe next time. So this was *one* person making that claim? I've seen it a few times from a few different posters, all on Usenet or whatever this thing is nowadays called. I think I was careful to say _some_ mathematicians, but not careful to check that any of them were actually mathematicians speaking as mathematicians. The context seems to be a cultural divide between maths and cs. Too much common ground yet very different interests? I understand that, in general, mathematicians don't have much need for a remainder function in the same way programmers do -- modulo arithmetic is far more important. But there's a world of difference between saying In mathematics, extracting the remainder is not important enough to be given a special symbol and treated as an operator and saying remainder is not a binary operator. The first is reasonable; the second is not. Yes. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 14, 1:38 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote: Arguably, the most elegant thing to do is to define integer division and remainder as a single operation; which is not only the logical thing to do mathematically, but might work really well programmatically too. The semantics of python dont really allow for this though. One could have: d, r = a // b That would be: divmod(17, 5) (3, 2) Cool; if only it were in the math module id be totally happy. But it wouldnt work that well in composite expressions; selecting the right tuple index would be messy and a more verbose form would be preferred. However, performance-wise its also clearly the best solution, as one often needs both output arguments and computing them simultaniously is most efficient. Premature optimization. We are talking language design here, not language use. Whether or not this is premature is a decision that should be left to the user, if at all possible, which in this case it very well is; just provide multiple functions to cover all use cases (only return divisor, only return remainder, or both) -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Thu, Dec 15, 2011 at 12:29 AM, Eelco hoogendoorn.ee...@gmail.com wrote: On Dec 14, 1:38 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: That would be: divmod(17, 5) (3, 2) Cool; if only it were in the math module id be totally happy. That's easily solved. import math math.divmod=divmod del __builtins__.divmod :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Wed, Dec 14, 2011 at 6:29 AM, Eelco hoogendoorn.ee...@gmail.com wrote: On Dec 14, 1:38 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote: Arguably, the most elegant thing to do is to define integer division and remainder as a single operation; which is not only the logical thing to do mathematically, but might work really well programmatically too. The semantics of python dont really allow for this though. One could have: d, r = a // b That would be: divmod(17, 5) (3, 2) Cool; if only it were in the math module id be totally happy. Probably it's not in math because it's not a thin wrapper around a C math library function, which is how the module was conceived. There are already some exceptions in the math module, but I think they are all newer than divmod. -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 14 December 2011 12:33, Eelco hoogendoorn.ee...@gmail.com wrote: On 14 dec, 12:55, Arnaud Delobelle arno...@gmail.com wrote: On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com wrote: On Dec 14, 4:18 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: They might not be willing to define it, but as soon as we programmers do, well, we did. Having studied the contemporary philosophy of mathematics, their concern is probably that in their minds, mathematics is whatever some dead guy said it was, and they dont know of any dead guy ever talking about a modulus operation, so therefore it 'does not exist'. You've studied the contemporary philosophy of mathematics huh? How about studying some actual mathematics before making such absurd pronouncements on the psychology of mathematicians? The philosophy was just a sidehobby to the study of actual mathematics; and you are right, studying their works is the best way to get to know them. Speaking from that vantage point, I can say with certainty that the vast majority of mathematicians do not have a coherent philosophy, and they adhere to some loosely defined form of platonism. Indeed that is absurd in a way. Even though you may trust these people to be perfectly functioning deduction machines, you really shouldnt expect them to give sensible answers to the question of which are sensible axioms to adopt. They dont have a reasoned answer to this, they will by and large defer to authority. Please come down from your vantage point for a few moments and consider how insulting your remarks are to people who have devoted most of their intellectual energy to the study of mathematics. So you've studied a bit of mathematics and a bit of philosophy? Good start, keep working at it. Thanks, I intend to. You think that every mathematician should be preoccupied with what axioms to adopt, and why? Of course I dont. If you wish to restrict your attention to the exploration of the consequences of axioms others throw at you, that is a perfectly fine specialization. Most mathematicians do exactly that, and thats fine. But that puts them in about as ill a position to judged what is, or shouldnt be defined, as the average plumber. You are completely mistaken. Whatever the axiomatisation of the mathematics that we do, we can still do the same mathematics. We don't even need an axiomatic basis to do mathematics. In fact, the formalisation of mathematics has always come after the mathematics were well established.Euclid, Dedekind, Peano, Zermelo, Frankael, didn't create axiomatic systems out of nothing. They axiomatised pre-existing theories. Axiomatising a theory is just one way of exploring it. Compounding the problem is not just that they do not wish to concern themselves with the inductive aspect of mathematics, they would like to pretend it does not exist at all. For instance, if you point out to them a 19th century mathematician used very different axioms than a 20th century one, (and point out they were both fine mathematicians that attained results universally celebrated), they will typically respond emotionally; get angry or at least annoyed. According to their pseudo-Platonist philosophy, mathematics should not have an inductive side, axioms are set in stone and not a human affair, and the way they answer the question as to where knowledge about the 'correct' mathematical axioms comes from is by an implicit or explicit appeal to authority. They dont explain how it is that they can see 'beyond the platonic cave' to find the 'real underlying truth', they quietly assume somebody else has figured it out in the past, and leave it at that. Again, you are completely mis-representing the situation. In my experience, most mathematicians (I'm not talking about undergraduate students here) do not see the axioms are the root of the mathematics that they do. Formal systems are just one way to explore mathematics. Of course they can in some cases be very useful and enlightening. As for inductive reasoning, I really can't understand your point. Of course mathematicians use inductive reasoning all the time. Where do you think the Riemann Hypothesis comes from? Or Fermat's last theorem? Do you think that mathematicians prove results before they even think about them? On the other hand, a result needs to be proved to be accepted by the mathematical community, and inductive reasoning is not valid in proofs. That's in the nature of mathematics. You say that mathematicians defer to authority, but do you really think that thousands of years of evolution and refinement in mathematics are to be discarded lightly? I think not. It's good to have original ideas, to pursue them and to believe in them, but it would be foolish to think that they are superior to knowledge which has been accumulated over so many generations. For what its worth; insofar as my views can be
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
'Kindof' off-topic, but what the hell :). On Dec 14, 5:13 pm, Arnaud Delobelle arno...@gmail.com wrote: On 14 December 2011 12:33, Eelco hoogendoorn.ee...@gmail.com wrote: On 14 dec, 12:55, Arnaud Delobelle arno...@gmail.com wrote: On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com wrote: On Dec 14, 4:18 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: They might not be willing to define it, but as soon as we programmers do, well, we did. Having studied the contemporary philosophy of mathematics, their concern is probably that in their minds, mathematics is whatever some dead guy said it was, and they dont know of any dead guy ever talking about a modulus operation, so therefore it 'does not exist'. You've studied the contemporary philosophy of mathematics huh? How about studying some actual mathematics before making such absurd pronouncements on the psychology of mathematicians? The philosophy was just a sidehobby to the study of actual mathematics; and you are right, studying their works is the best way to get to know them. Speaking from that vantage point, I can say with certainty that the vast majority of mathematicians do not have a coherent philosophy, and they adhere to some loosely defined form of platonism. Indeed that is absurd in a way. Even though you may trust these people to be perfectly functioning deduction machines, you really shouldnt expect them to give sensible answers to the question of which are sensible axioms to adopt. They dont have a reasoned answer to this, they will by and large defer to authority. Please come down from your vantage point for a few moments and consider how insulting your remarks are to people who have devoted most of their intellectual energy to the study of mathematics. So you've studied a bit of mathematics and a bit of philosophy? Good start, keep working at it. Thanks, I intend to. You think that every mathematician should be preoccupied with what axioms to adopt, and why? Of course I dont. If you wish to restrict your attention to the exploration of the consequences of axioms others throw at you, that is a perfectly fine specialization. Most mathematicians do exactly that, and thats fine. But that puts them in about as ill a position to judged what is, or shouldnt be defined, as the average plumber. You are completely mistaken. Whatever the axiomatisation of the mathematics that we do, we can still do the same mathematics. We don't even need an axiomatic basis to do mathematics. In fact, the formalisation of mathematics has always come after the mathematics were well established. Euclid, Dedekind, Peano, Zermelo, Frankael, didn't create axiomatic systems out of nothing. They axiomatised pre-existing theories. Axiomatising a theory is just one way of exploring it. Yes, axiomization is to some extent a side-show. We know what it is that we want mathematics to be, and we try to find the axioms that lead to those conclusions. Not qualitatively different from any other form of induction (of the epistemological rather than mathematical kind). Still, different axioms or meta-mathematics give subtly different results, not to mention are as different to work with as assembler and haskell. There are no alephs if you start from a constructive basis, for instance. Im not sure what 'Axiomatising a theory is just one way of exploring it' means. One does not axiomatize a single theory; that would be trivial (A is true because thats what I define A to be). One constructs a single set of axioms from which a nontrivial set of theorems follow. The way id put it, is that axiomazation is about being explicit in what it is that you assume, trying to minimalize that, and being systematic about what conclusions that forces you to embrace. Could you be more precise as to how I am 'completely mistaken'? I acknowledge that my views are outside the mainstream, so its no news to me many would think so, but it would be nice to know what im arguing against in this thread precisely. Compounding the problem is not just that they do not wish to concern themselves with the inductive aspect of mathematics, they would like to pretend it does not exist at all. For instance, if you point out to them a 19th century mathematician used very different axioms than a 20th century one, (and point out they were both fine mathematicians that attained results universally celebrated), they will typically respond emotionally; get angry or at least annoyed. According to their pseudo-Platonist philosophy, mathematics should not have an inductive side, axioms are set in stone and not a human affair, and the way they answer the question as to where knowledge about the 'correct' mathematical axioms comes from is by an implicit or explicit appeal to authority. They dont explain how it is that they can see 'beyond the platonic
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On 12/14/2011 5:09 AM, Eelco wrote: Arguably, the most elegant thing to do is to define integer division and remainder as a single operation; It actually is, as quotient and remainder are calculated together. The microprocessors I know of expose this (as does Python). 'a divmod b' puts the quotient in one register and the remainder in another. If you ask for just one of the two values, both are calculated and one is grabbed while the other is returned. which is not only the logical thing to do mathematically, but might work really well programmatically too. The semantics of python dont really allow for this though. One could have: d, r = a // b a,b = divmod(10,3) a,b (3, 1) With CPython, int.__divmod__ lightly wraps and exposes the processor operation. But it wouldnt work that well in composite expressions; selecting the right tuple index would be messy and a more verbose form would be preferred. That is why we have a == 10 // 3 True b == 10 % 3 True In both cases, I believe CPython calls int.__divmod__ (or the lower level equivalent) to calculate both values, and one is returned while the other is ignored. It it the same when one does long division by hand. However, performance-wise its also clearly the best solution, as one often needs both output arguments and computing them simultaniously is most efficient. As indicated above, there is really no choice but to calculate both at once. If one needs both a//b and a%b, one should explicitly call divmod once and save (name) both values, instead of calling it implicitly twice and tossing half the answer each time. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Dec 14, 10:15 pm, Eelco hoogendoorn.ee...@gmail.com wrote: 'Kindof' off-topic, but what the hell :). deja-vu We keep having these debates -- so I wonder how off-topic it is... And so do famous CSists: http://research.microsoft.com/en-us/um/people/gurevich/opera/123.pdf /deja-vu : : Again, you are completely mis-representing the situation. In my experience, most mathematicians (I'm not talking about undergraduate students here) do not see the axioms are the root of the mathematics that they do. Formal systems are just one way to explore mathematics. Of course they can in some cases be very useful and enlightening. Its your word versus mine I suppose. Some older discussions: http://groups.google.com/group/comp.lang.python/browse_thread/thread/46435c36f3a13621/896579b757126243?lnk=gstq=rusi+steven+platonism#896579b757126243 http://groups.google.com/group/comp.lang.python/browse_thread/thread/d36dcd2e2e175d1e/45dd596bc050ac2d?lnk=gstq=rusi+steven+platonism#45dd596bc050ac2d -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Dec 13, 1:27 am, alex23 wuwe...@gmail.com wrote: On Dec 13, 3:12 am, Eelco hoogendoorn.ee...@gmail.com wrote: But to relate it to the topic of this thread: no, the syntax does not allow one to select the type of the resulting sequence. It always constructs a list. So by this argument, _every_ function that returns a list should take an optional argument to specify an alternative form of sequence. What, exactly, is so onerous about coercing your list to _whatever_ type you want? You know, like everybody else has been. What does this _gain_ you other than one less line of code? 1) Turning two lines of code into a single more readable one is nothing to scoff at 2) After-the-fact conversion is O(n), getting the view you want right away is O(1) Not every function needs this flexibility; many specialized functions could not care less. But collection unpacking is quite a general thing, and for the record; slicing a tuple returns a tuple. Would you rather have that return a list too? -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Dec 13, 1:34 am, Ian Kelly ian.g.ke...@gmail.com wrote: On Mon, Dec 12, 2011 at 11:51 AM, Eelco hoogendoorn.ee...@gmail.com wrote: Either way, its not hard to add some detail to the semantics to allow all this. Even this function definition: def func(Foo(args), Foo(kwargs)) ...could even be defined unambigiously by overloading first on base type, and if that does not uniquely determine the args and kwargs, fall back on positionality, so that: def func(Foo(args), dict(kwargs)) def func(list(args), Foo(kwargs)) would be uniquely defined as well. That solves some of the problems, but if I just have: def func(SequenceOrMappingType(args)): That's going to unpack positionally. If I want it to unpack keywords instead, how would I change the definition to indicate that? That should raise an ambiguity error. But honestly, how often have you worked with SequenceOrMappingType's? I think this is a rather palatable constraint. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Dec 13, 2:41 am, Ian Kelly ian.g.ke...@gmail.com wrote:
On Mon, Dec 12, 2011 at 4:40 PM, Eelco hoogendoorn.ee...@gmail.com wrote:
For a linked list, no *target and no copying is needed:
head, tail = llist
I have no idea what this means.
Each node of a linked list consists of a data member and a next
member, that holds the next node in the list. The natural container
for this and the way it is usually implemented in Python is a
2-element tuple. For example:
llist = ('one', ('two', ('three', ('four', None
would be a linked list as typically constructed in Python, and it can
be used in pretty much the same way that lists are used in Lisp. The
result of the operation:
head, tail = llist
is:
head = 'one'
tail = ('two', ('three', ('four', None)))
and as Terry pointed out, no copying is required to do this. I
believe deque is also implemented as a doubly-linked list, which is
probably why you keep referring to it as such, but that is an
implementation detail. When you say linked list in relation to
Python, the preceding is what comes to mind.
'for i in llist' is not quite going to fly is it? Thats probably the
reason noone ever uses that construct; its not a proper sequence type.
head, deque(tail) = somedeque
Is better in every way I can think of (readability, consistence,
performance) than:
head, *tail = somedeque
tail = deque(tail)
But your suggestion is much worse in each way than
head = somedeque.popleft()
No its not. First of all, its not semantically equivalent; popleft
mutates a collection type, and collection unpacking does not; it
creates a set of disjoint views of the collection's data. Whether its
worse in terms of readability is debatable, but in terms of the other
two stated metrics, your claim of it being any kind of worse is
objectively false.
I definitely disagree on readability. Skimming this thread as I have
been, it took me a while to get that your proposed syntax would create
a second deque sharing internal state with the original, rather than
creating a simple copy of the deque, which is what it looks like it
should do.
Thats a matter of reading up on the semantics of collection unpacking.
To be honest I dont even know what they are for lists, since I dont
use python 3. But whatever is the case, the important thing is that
the semantics should be uniform regardless of the type to be unpacked.
Incidentally, while that change is not really central to your syntax
proposal, I think it would be very messy. For example, how do you
propose keeping the length elements in sync? Inserting an item in one
may or may not affect the length of the other. If I append an item to
the end of one deque, should the other automatically be extended as
well? What if the tail node of the second deque occurs after the tail
node of the deque being appended? Does the appended element then get
inserted into the middle of the second deque (I think it would have to
be)? If I insert an element into the longer (second) deque that just
happens to be immediately after the tail of the shorter deque, does
*that* cause the shorter deque to be automatically extended? And
likewise for operations at the head of the deque.
None of these questions have obvious answers as to the right way to
it, and for that reason I think this is probably best left to the user
to implement a custom deque view class with whatever semantics they
prefer.
Good point. Copy-on-write semantics could be used, but really one
should have several linked list types reflecting the underlying
implementations. I would like to have an immutable singly linked list
builtin of the standard functional type, which you can only unpack
from one end and renders these issues moot, plus a builtin doubly
linked list with copy-on-write or copy-on-unpacking semantics.
Furthermore, this brings us back again to the point I raised several
times before. Yes, obviously you can already DO these things, but NOT
within the same uniform collection unpacking syntactic construct.
Again, you have failed to point out what is wrong with supplying a
type constrain to python and let it do the right thing based on that;
to reiterate:
head, tail::deque = deque
Python users generally follow the rule explicit is better than
implicit. Setting a general constraint and letting the language do
the right thing is a kind of black magic that feels off because it
tends to break that rule. But that's not to say that black magic
never wins -- just look at super() and the MRO.
We are not talking black magic here; we are talking about an EXPLICIT
type constraint provided on the very same line.
If you dont like the extra characters you have to type; there is of
course such a thing as defaults. You can choose:
head, tail:: = deque; if the type constraint is omitted, we could make
tail a list by default, or my preferred solution, infer it from the
right hand side
Re: Verbose and flexible args and kwargs syntax
On Dec 13, 3:43 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote: No more, or less, explicit than the difference between == and is. == may be taken to mean identity comparison; 'equals' can only mean one thing. Nonsense. Equals can be taken to mean anything the language designer chooses, same as ==. There is no language police that enforces The One True Meaning Of Equals. In fact, there is no one true meaning of equals. Even my tiny Pocket Oxford dictionary lists five definitions. It is ironic that the example you give, that of identity, is the standard definition of equals in mathematics. 2*2 = 4 does not merely say that there is a thing, 2*2, which has the same value as a different thing, 4, but that both sides are the same thing. Two times two *is* four. All numbers are, in some sense, singletons and equality implies identity. We are not talking mathemathics, we are talking programming languages. Identity versus value equality is a well established concept within its jargon. Within this context, 'equals' and 'is' have clearly defined meanings. Indeed within broader use, including everyday language, the distinction is more subtle and therefore less useful, but obeying a linguistic rule that holds within computer science is better than making something up just for python, even though its not the yet better rule that any five year old might grasp. Of course 'formally' these symbols are well defined, but so is brainf*ck I don't understand your point here. Hence the above. Modulo is hardly an obscure operation. What's the remainder...? is a simple question that people learn about in primary school. So is 'how much wood would a woodchucker chuck if a woodchucker could chuck wood?'. But how often does that concept turn up in your code? You didn't make a statement about how often modulo turns up in code (which is actually quite frequently, and possibly more frequently than regular division), but about the obscurity of the operation. Taking the remainder is not an obscure operation. The names modulo and modulus may be obscure to those who haven't done a lot of mathematics, but the concept of remainder is not. How many pieces are left over after dividing into equal portions is something which even small children get. So 'frequency of use' is no valid interpretation of 'obscurity'? Im not a native speaker, but im pretty sure it is. And you can blame C for the use of % instead of mod or modulo. I didnt know one of Python's design goals was backwards compatibility with C. Don't be silly. You know full well Python is not backwards compatible with C, even if they do share some syntactical features. Of course I was being silly; I know this use is following a historical precedent; but id rather see it rectified in the previous version of python rather than the next. My sillyness was prompted by the percieved pointlessness of your remark. Of course python is not trying to be backwards compatible with C; so why bring it up then? If you can supply any function at all, what happens if I write this: You cannot; only constructors modelling a sequence or a dict, and only in that order. Is that rule clear enough? But why limit yourself to those restrictive rules? If I want to collect a sequence of arguments into a string, why shouldn't I be allowed to write this? def func(parg, str(args)): ... If I want to sum a collection of arguments, why not write this? def func(pargs, sum(args)): ... Isn't that better than this? def func(pargs, *args): args = sum(args) ... But no. I don't mean those examples to be taken seriously: when you answer to your own satisfaction why they are bad ideas, you may be closer to understanding why I believe your idea is also a bad idea. They are bad ideas because they truely do not lead to the execution of different code, but are merely a reordering, mixing statements in with a function declaration. I am proposing no such thing; again, the type(arg) notation I have dropped, and never was meant to have anything to do with function calling; it is a way of supplying an optional type constraint, so in analogy with function annotations, I changed that to arg::type. Again, this has nothing to do with calling functions on arguments. First off, type constraints must have some use; all those languages cant be wrong. Ofcourse, no type constraints also can not be wrong; see all those other languages. And I obviously dont mean to make type constraits mandatory in python, all im saying is that optionally allowing them can open some doors in the right places. The * and ** syntax are also in effect type constraints, saying 'this is a dict to collect the remaining kwargs in', but in a rather cryptic and needlessly ungeneral method. #define a function with args-list and kwargs-attrdict def func(args::list, kwargs::attrdict) #unpack the
Re: Verbose and flexible args and kwargs syntax
Python users generally follow the rule explicit is better than implicit. Setting a general constraint and letting the language do the right thing is a kind of black magic that feels off because it tends to break that rule. But that's not to say that black magic never wins -- just look at super() and the MRO. We are not talking black magic here; we are talking about an EXPLICIT type constraint provided on the very same line. To hammer that point home: would you say the following C# code performs 'black magic'? float x = 3; After all, exactly the same thing is going on; C# will 'do the right thing'; convert the integer literal 3 to a floating point value, based on the type constraint placed on x. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
To answer that question: for the same reasons. The conversion is wasteful; allowing python to do the right thing based on a typeconstraint is not. Plus, it is less code, and more readable code; the only rule you have to learn is quite general, which is that :: is a type constraint annotation; no need to remember specifics, like 'unpacking always returns lists for some arbitrary reason'. Oh my bad; actually, that should be: 'collecting the remainder of an unpacked iterable using * will always yield a list. That is, unless the construct appears inside a function definition; then somehow a tuple is always the right choice' -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 13 December 2011 09:50, Eelco hoogendoorn.ee...@gmail.com wrote: To answer that question: for the same reasons. The conversion is wasteful; allowing python to do the right thing based on a typeconstraint is not. Plus, it is less code, and more readable code; the only rule you have to learn is quite general, which is that :: is a type constraint annotation; no need to remember specifics, like 'unpacking always returns lists for some arbitrary reason'. Oh my bad; actually, that should be: 'collecting the remainder of an unpacked iterable using * will always yield a list. That is, unless the construct appears inside a function definition; then somehow a tuple is always the right choice' When you quote somebody (even yourself), it would be helpful if you attributed your quote. -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 13 dec, 11:15, Arnaud Delobelle arno...@gmail.com wrote: On 13 December 2011 09:50, Eelco hoogendoorn.ee...@gmail.com wrote: To answer that question: for the same reasons. The conversion is wasteful; allowing python to do the right thing based on a typeconstraint is not. Plus, it is less code, and more readable code; the only rule you have to learn is quite general, which is that :: is a type constraint annotation; no need to remember specifics, like 'unpacking always returns lists for some arbitrary reason'. Oh my bad; actually, that should be: 'collecting the remainder of an unpacked iterable using * will always yield a list. That is, unless the construct appears inside a function definition; then somehow a tuple is always the right choice' When you quote somebody (even yourself), it would be helpful if you attributed your quote. -- Arnaud Ah yes; im more used to proper forums, still getting used to these mailing-list things. But point taken. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
With all this being said, I must say that the notion of indtroducing type constraints into Python is quite a radical one*, and one that should not be taken lightly, so I understand the general conservative vibe the notion is getting. It probably has implications beyond just collection types, and if youd introduce such a feature, you would like to introduce it only once, and correctly the first time around. Ill probably start a new thread soon, recapping the accumulated insight, and capping all the OT threads that have spawned. *even though the asteriks syntax is infact a limited form of exactly that -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote: On Dec 13, 3:43 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote: No more, or less, explicit than the difference between == and is. == may be taken to mean identity comparison; 'equals' can only mean one thing. [...] We are not talking mathemathics, we are talking programming languages. What *I* am talking about is your assertion that there is only one possible meaning for equals in the context of a programing language. This is *simply not correct*. You don't have to believe me, just look at the facts. It's hard to find languages that use the word equals (or very close to it) rather than equals signs, but here are four languages which do: (1) OpenXION: Equals in OpenXION is weakly typed, like Perl: 1 + 1.0 equals 2 true (2) C# uses method notation: a.Equals(b) can be overridden, but for many types it defaults to value equality, that is, the equivalent to Python's a == b. (3) Ruby uses a.equal?(b) for reference equality, that is, the equivalent of Python's is operator: irb(main):001:0 a = abc = abc irb(main):002:0 b = abc = abc irb(main):003:0 a.equal?(b) = false irb(main):004:0 a == b = true (4) Mathematica's Equal[x, y] can test values and expressions for equality. It may return true, false, or unevaluated (i.e. itself). Four languages that use Equals (or close to it) with four different behaviours. Identity versus value equality is a well established concept within its jargon. Within this context, 'equals' and 'is' have clearly defined meanings. Incorrect. Most programming languages do not even have a concept of identity: identity is only(?) relevant to reference languages, like Python, where variables are references to objects. Even for languages that have a concept of identity, most don't don't call it is. Objective-C calls it ==, PHP calls it ===, C# calls it object.ReferenceEquals. (Python, Algol 68, and VB .NET are three which do call it is.) For stack-based languages like Forth, it doesn't even make sense to talk about identity, since values aren't variables: they're just values on a stack, not values in a fixed location, or bound to a known name. Again, all this goes to demonstrate that the language designer is free to choose any behaviour they like, and give it any name they like. [...] So 'frequency of use' is no valid interpretation of 'obscurity'? Im not a native speaker, but im pretty sure it is. No. Things which are obscure are used in language infrequently, because if they were common they would not be obscure. But things which are used infrequently are not necessarily obscure. An example in common language: Napoleon Bonaparte does not come up in conversation very frequently, but he is not an obscure historical figure. An example from programming: very few people need to use the trigonometric functions sin, cos, tan in their code. But they are not obscure functions: most people remember them from school. People who have forgotten almost everything about mathematics except basic arithmetic probably remember sin, cos and tan. But they never use them. And you can blame C for the use of % instead of mod or modulo. I didnt know one of Python's design goals was backwards compatibility with C. Don't be silly. You know full well Python is not backwards compatible with C, even if they do share some syntactical features. Of course I was being silly; I know this use is following a historical precedent; but id rather see it rectified in the previous version of python rather than the next. My sillyness was prompted by the percieved pointlessness of your remark. Of course python is not trying to be backwards compatible with C; so why bring it up then? Because you asked why Python uses the % operator for remainder. [...] They are bad ideas because they truely do not lead to the execution of different code, but are merely a reordering, mixing statements in with a function declaration. I am proposing no such thing; again, the type(arg) notation I have dropped, and never was meant to have anything to do with function calling; it is a way of supplying an optional type constraint, so in analogy with function annotations, I changed that to arg::type. Again, this has nothing to do with calling functions on arguments. You have not thought about this carefully enough. Consider what happens when this code gets called: def f(*args): pass f(a, b, c) The Python virtual machine (interpreter, if you prefer) must take three arguments a, b, c and create a tuple from them. This must happen at runtime, because the value of the objects is not known at compile time. So at some point between f(a, b, c) being called and the body of f being entered, a tuple must be created, and the values of a, b, c must be collated into a single tuple. Now extend this reasoning to your proposal: def f(args:FOO): pass At
Re: Verbose and flexible args and kwargs syntax
On Tue, 13 Dec 2011 02:46:13 -0800, Eelco wrote: With all this being said, I must say that the notion of indtroducing type constraints into Python is quite a radical one*, Not that radical. Here's the creator of Python musing about adding optional type checks to Python: http://www.artima.com/weblogs/viewpost.jsp?thread=85551 http://www.artima.com/weblogs/viewpost.jsp?thread=86641 http://www.artima.com/weblogs/viewpost.jsp?thread=87182 [...] *even though the asteriks syntax is infact a limited form of exactly that It absolutely is not. def f(*args, **kwargs) constructs a tuple and a dict, it does not type-check that the function is passed a tuple and a dict as arguments. These are completely different things. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 13 dec, 12:28, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Tue, 13 Dec 2011 02:46:13 -0800, Eelco wrote: With all this being said, I must say that the notion of indtroducing type constraints into Python is quite a radical one*, Not that radical. Here's the creator of Python musing about adding optional type checks to Python: http://www.artima.com/weblogs/viewpost.jsp?thread=85551http://www.artima.com/weblogs/viewpost.jsp?thread=86641http://www.artima.com/weblogs/viewpost.jsp?thread=87182 Good find; but still radical enough that it hasnt been implemented. Note that these musing are trying to adress a yet far more general problem of specifying arbitrary types constraints on anything; I am primarily interested in specifying container types in the special case of collection packing/unpacking syntax, with further extensions nothing but a welcome addon. The fact that the former was judged infeasible does not mean the more modest goal of the latter might not be attainable. *even though the asteriks syntax is infact a limited form of exactly that It absolutely is not. def f(*args, **kwargs) constructs a tuple and a dict, it does not type-check that the function is passed a tuple and a dict as arguments. These are completely different things. Which is of course not something I ever proposed; I never said anything about checking types of existing data; im talking about coercing types of newly created data, like the target of a collection packing. That is exactly what *args and **kwargs also do. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 13 dec, 12:13, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote: On Dec 13, 3:43 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote: No more, or less, explicit than the difference between == and is. == may be taken to mean identity comparison; 'equals' can only mean one thing. [...] We are not talking mathemathics, we are talking programming languages. What *I* am talking about is your assertion that there is only one possible meaning for equals in the context of a programing language. This is *simply not correct*. You don't have to believe me, just look at the facts. It's hard to find languages that use the word equals (or very close to it) rather than equals signs, but here are four languages which do: That python is not the only language to not get this quite as right as could be is known to me. But within computer science as a discipline, equality and identity comparisons have a clear enough meaning. 'is' has a narrower meaning than 'equals'. '==' has no meaning whatsoever in computer science. Again, all this goes to demonstrate that the language designer is free to choose any behaviour they like, and give it any name they like. Certainly you demonstrated as much. Programming languages are created by people, and they have a tendency to make mistakes, and to have to compromise (backwards compatibility, and so on). Thats a seperate matter from 'what ought to be done', when discussing optimal language design. So 'frequency of use' is no valid interpretation of 'obscurity'? Im not a native speaker, but im pretty sure it is. No. Things which are obscure are used in language infrequently, because if they were common they would not be obscure. But things which are used infrequently are not necessarily obscure. An example in common language: Napoleon Bonaparte does not come up in conversation very frequently, but he is not an obscure historical figure. An example from programming: very few people need to use the trigonometric functions sin, cos, tan in their code. But they are not obscure functions: most people remember them from school. People who have forgotten almost everything about mathematics except basic arithmetic probably remember sin, cos and tan. But they never use them. I dont think its terribly interesting to debate whether the term obscure applies to trigonometric functions or not: the important matter is that they are where they should be; under math.cos, etc. They dont have their own special character, and I hope you agree that is as it should be. I use trig far more often than modulus, so that argues in favor of modulus being under math too; infact I used modulus quite recently, but naturally it was in a piece of code that should be done in C eventually anyway (evaluating subdivision surfaces) Because you asked why Python uses the % operator for remainder. So you ARE implying python has backwards compatibility with C as a design goal? Otherwise the given answer to this question is nonsensical. [...] They are bad ideas because they truely do not lead to the execution of different code, but are merely a reordering, mixing statements in with a function declaration. I am proposing no such thing; again, the type(arg) notation I have dropped, and never was meant to have anything to do with function calling; it is a way of supplying an optional type constraint, so in analogy with function annotations, I changed that to arg::type. Again, this has nothing to do with calling functions on arguments. You have not thought about this carefully enough. Consider what happens when this code gets called: def f(*args): pass f(a, b, c) The Python virtual machine (interpreter, if you prefer) must take three arguments a, b, c and create a tuple from them. This must happen at runtime, because the value of the objects is not known at compile time. So at some point between f(a, b, c) being called and the body of f being entered, a tuple must be created, and the values of a, b, c must be collated into a single tuple. Now extend this reasoning to your proposal: def f(args:FOO): pass At runtime, the supplied arguments must be collated into a FOO, whatever FOO happens to be. Hence, the function that creates FOO objects must be called before the body of f can be entered. This doesn't happen for free. Whether you do it manually, or have the Python interpreter do it, it still needs to be done. Of course the python interpreted needs to do this; and in case non- builtin types are allowed, the mechanism is going to be through their constructor. But thats a detail; the syntax doesnt say: 'please call this constructor for me', any more than **kwargs says 'please call a dict constructor for me', even though equivalent operations are obviously going on under the hood as part of the process. Yes, whatever
Re: Verbose and flexible args and kwargs syntax
On Tue, Dec 13, 2011 at 11:47 PM, Eelco hoogendoorn.ee...@gmail.com wrote: def f(*args) *constructs* a tuple, it doesn't perform a type-check. I am talking about type constraints... A type-check is something along the lines of type(args)==list, a runtime thing and something completely different. I havnt mentioned the latter at all, explicitly or implicitly, as far as im aware. I'm not sure what you mean by a type constraint. Here's how I understand such: float|int foobar; //Declare that the variable 'foobar' is allowed to hold a float or an int foobar = 3.2; //Legal. foobar = 1200; //Also legal (a rather large integer value) foobar = hello; //Not legal Python doesn't have any such thing (at least, not in-built). Any name may be bound to any value - or if you like, any variable can contain any type. Same applies to argument passing - you can even take an unbound method and call it with some completely different type of object as its first parameter. (I can't think of ANY situation in which this would not be insanely confusing, tbh.) When you gather a function's arguments into a tuple, list, or any other such container object, what you're doing is constructing another object and stuffing it with references to the original arguments. That involves building a new object, where otherwise you simply bind the arguments' names to the original objects directly. Now, it is perfectly conceivable to have designed Python to _always_ pass tuples around. Instead of a set of arguments, you just always pass exactly one tuple to a function, and that function figures out what to do with the args internally. If that's the way the language is built, then it is the _caller_, not the callee, who builds that tuple; and we still have the same consideration if we want a list instead. So suppose you can have a user-defined object type instead of list/dict. How are you going to write that type's __init__ function? Somewhere along the way, you need to take a variable number of arguments and bundle them up into a single one... so somewhere, you need the interpreter to build it for you. This is going to end up exactly the same as just accepting the tuple and then passing that to a constructor, like the list example. Keep things transparent and you make debugging a LOT easier. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 13 dec, 14:14, Chris Angelico ros...@gmail.com wrote: On Tue, Dec 13, 2011 at 11:47 PM, Eelco hoogendoorn.ee...@gmail.com wrote: def f(*args) *constructs* a tuple, it doesn't perform a type-check. I am talking about type constraints... A type-check is something along the lines of type(args)==list, a runtime thing and something completely different. I havnt mentioned the latter at all, explicitly or implicitly, as far as im aware. I'm not sure what you mean by a type constraint. Here's how I understand such: float|int foobar; //Declare that the variable 'foobar' is allowed to hold a float or an int foobar = 3.2; //Legal. foobar = 1200; //Also legal (a rather large integer value) foobar = hello; //Not legal Python doesn't have any such thing (at least, not in-built). Agreed on what a type constraint is, and that python does not really have any, unless one counts the current use of asterikses, which are infact a limited form of type constrait (*tail is not just any object, but one holding a list, which modifies the semantics of the assignment statement 'head,*tail=sequence' from a regular tuple unpacking to a specific form of the more general collection unpacking syntax); The idea is to enrich this syntax; to add optional and limited type constraints to python, specifically to enrich collection packing/ unpacking syntax, but perhaps the concept can be further generalized. So suppose you can have a user-defined object type instead of list/dict. How are you going to write that type's __init__ function? Somewhere along the way, you need to take a variable number of arguments and bundle them up into a single one... so somewhere, you need the interpreter to build it for you. This is going to end up exactly the same as just accepting the tuple and then passing that to a constructor, like the list example. Keep things transparent and you make debugging a LOT easier. Agreed; for user defined collection types there would not be a performance benefit over converting a tuple, since this is exactly what will happen anyway, but for collection types derived from any of the builtins, python could optimize away the intermediate and construct the desired collection type directly from the available information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Tue, Dec 13, 2011 at 1:44 AM, Eelco hoogendoorn.ee...@gmail.com wrote: 'for i in llist' is not quite going to fly is it? Thats probably the reason noone ever uses that construct; its not a proper sequence type. Not really a problem, because fortunately Python makes it super-easy to create custom iterators. def listiter(llist): while llist: head, llist = llist yield head And you're done. If you like, you could also wrap this up in a class with all the sequence-related magic methods you want, although you lose the simplicity of the literal syntax by doing so. If this is rarely used, it is more likely because custom containers are going to be less efficient than built-ins, but if you want to do functional programming and are not overly concerned with the speed of iteration, this is not a bad way to do it. Good point. Copy-on-write semantics could be used, but really one should have several linked list types reflecting the underlying implementations. I would like to have an immutable singly linked list builtin of the standard functional type, which you can only unpack from one end and renders these issues moot, plus a builtin doubly linked list with copy-on-write or copy-on-unpacking semantics. Copy-on-write could be implemented with any type. You don't need a doubly linked list for that. We are not talking black magic here; we are talking about an EXPLICIT type constraint provided on the very same line. An explicit type constraint with very different semantics depending on what particular type you specify and what particular type you're unpacking from, as I had understood it before. Now you seem to be saying that it would always be a copy, but sharing state with copy-on-write possible, which is a different situation. Well perhaps, but not always knowing the type of your objects at write- time is inherent to weakly typed languages; this happens all the time. Not knowing the type of the sequence to be unpacked is in a sense an asset; I can use this construct in a function, and unpack any sequence type in a manner appropriate for it. About the result of the unpacking I will know just as much as about the input to it; that they are the same type. Just because the issue is inherent doesn't mean we should contribute to it. Knowing that an object is an arbitrary sequence is fine if all you want to do is iterate and index it. If you want to do anything else, then it's important to know the type. The copy-on-write suggestion does make the type-matching approach a bit more attractive. On the other hand, it's also more fragile (what if the type being unpacked can't be constructed from an iterable? For example, a database cursor), so that approach potentially needs additional error-handling. Anyway, the more I think about it, that concern is really more of an issue for straight copying. One of my pet peeves is that I prefer list(x) for copying sequences rather than the more common x[::]. The latter is fine if all I need is an immutable sequence of uncertain type to iterate and index over -- but then why did I need to make a copy? Unpacking implies different use cases, though, and maybe a good argument can be made for it to match type. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 13Dec2011 00:30, Eelco hoogendoorn.ee...@gmail.com wrote: | On Dec 13, 1:27 am, alex23 wuwe...@gmail.com wrote: | On Dec 13, 3:12 am, Eelco hoogendoorn.ee...@gmail.com wrote: | But to relate it to the topic of this thread: no, the syntax does not | allow one to select the type of the resulting sequence. It always | constructs a list. | | So by this argument, _every_ function that returns a list should take | an optional argument to specify an alternative form of sequence. | | What, exactly, is so onerous about coercing your list to _whatever_ | type you want? You know, like everybody else has been. | | What does this _gain_ you other than one less line of code? | | 1) Turning two lines of code into a single more readable one is | nothing to scoff at | 2) After-the-fact conversion is O(n), getting the view you want right | away is O(1) Regarding (2), it has already cost you O(n) to get there. So your O(1) is a little ingenuous. -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ I'm a volunteer EMT-I on our local ambulance service; one of our Paramedics calls squid style motorcycle accidents ZoomSplats, as in we had a good ZoomSplat the other night. ;-) - Scott trau...@rapnet.sanders.lockheed.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Dec 13, 8:11 pm, Cameron Simpson c...@zip.com.au wrote: On 13Dec2011 00:30, Eelco hoogendoorn.ee...@gmail.com wrote: | On Dec 13, 1:27 am, alex23 wuwe...@gmail.com wrote: | On Dec 13, 3:12 am, Eelco hoogendoorn.ee...@gmail.com wrote: | But to relate it to the topic of this thread: no, the syntax does not | allow one to select the type of the resulting sequence. It always | constructs a list. | | So by this argument, _every_ function that returns a list should take | an optional argument to specify an alternative form of sequence. | | What, exactly, is so onerous about coercing your list to _whatever_ | type you want? You know, like everybody else has been. | | What does this _gain_ you other than one less line of code? | | 1) Turning two lines of code into a single more readable one is | nothing to scoff at | 2) After-the-fact conversion is O(n), getting the view you want right | away is O(1) Regarding (2), it has already cost you O(n) to get there. So your O(1) is a little ingenuous. Well, yes, but if one takes a given sequence as input (at least O(n) complexity to obtain it in the first place, indeed), and then wants to, say, recursively unwind it, the cost of the total operation is O(n) versus O(n^2) And besides, O(n) 2*O(n); perhaps of lesser concern than different orders, but still. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Dec 13, 7:15 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Tue, Dec 13, 2011 at 1:44 AM, Eelco hoogendoorn.ee...@gmail.com wrote: 'for i in llist' is not quite going to fly is it? Thats probably the reason noone ever uses that construct; its not a proper sequence type. Not really a problem, because fortunately Python makes it super-easy to create custom iterators. def listiter(llist): while llist: head, llist = llist yield head And you're done. If you like, you could also wrap this up in a class with all the sequence-related magic methods you want, although you lose the simplicity of the literal syntax by doing so. If this is rarely used, it is more likely because custom containers are going to be less efficient than built-ins, but if you want to do functional programming and are not overly concerned with the speed of iteration, this is not a bad way to do it. Fair enough. Still, I dont readily see myself using the construct, and I do feel myself longing for something like that to be included as a builtin collection type. Im not sure why python is so stingy with the collections it provides. Good point. Copy-on-write semantics could be used, but really one should have several linked list types reflecting the underlying implementations. I would like to have an immutable singly linked list builtin of the standard functional type, which you can only unpack from one end and renders these issues moot, plus a builtin doubly linked list with copy-on-write or copy-on-unpacking semantics. Copy-on-write could be implemented with any type. You don't need a doubly linked list for that. True We are not talking black magic here; we are talking about an EXPLICIT type constraint provided on the very same line. An explicit type constraint with very different semantics depending on what particular type you specify and what particular type you're unpacking from, as I had understood it before. Now you seem to be saying that it would always be a copy, but sharing state with copy-on-write possible, which is a different situation. Yes, I think consistent semantics over all sequence types is very important. Although, returning a view for immutable collections like tuples and 'functional lists' (for lack of a better term), and always returning a copy for mutable container types (lists and doubly-linked- lists / deques) is not so bad either, imo. Just one extra simple rule that is clear and obvious enough. Well perhaps, but not always knowing the type of your objects at write- time is inherent to weakly typed languages; this happens all the time. Not knowing the type of the sequence to be unpacked is in a sense an asset; I can use this construct in a function, and unpack any sequence type in a manner appropriate for it. About the result of the unpacking I will know just as much as about the input to it; that they are the same type. Just because the issue is inherent doesn't mean we should contribute to it. How are we contributing to it? If we dont know the type of the RHS, we dont know the type of the LHS either, but its not like we lost any information. If we do know the type of the RHS, then we do know the type of the LHS as well; its conserved. Anyway, the more I think about it, that concern is really more of an issue for straight copying. One of my pet peeves is that I prefer list(x) for copying sequences rather than the more common x[::]. The latter is fine if all I need is an immutable sequence of uncertain type to iterate and index over -- but then why did I need to make a copy? Unpacking implies different use cases, though, and maybe a good argument can be made for it to match type. Thanks for the constructive feedback; something to think about. -- http://mail.python.org/mailman/listinfo/python-list
% is not an operator [was Re: Verbose and flexible args and kwargs syntax]
On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote: [quoting Jussi Piitulainen jpiit...@ling.helsinki.fi] They recognize modular arithmetic but for some reason insist that there is no such _binary operation_. But as I said, I don't understand their concern. (Except the related concern about some programming languages, not Python, where the remainder does not behave well with respect to division.) I've never come across this, and frankly I find it implausible that *actual* mathematicians would say that. Likely you are misunderstanding a technical argument about remainder being a relation rather than a bijunction. The argument would go something like this: Remainder is not uniquely defined. For example, the division of -42 by -5 can be written as either: 9*-5 + 3 = -42 8*-5 + -2 = -42 so the remainder is either 3 or -2. Hence remainder is not a bijection (1:1 function). The existence of two potential answers for the remainder is certainly correct, but the conclusion that remainder is not a binary operation doesn't follow. It is a binary relation. Mathematicians are well able to deal with little inconveniences like this, e.g. consider the square root: 10**2 = 100 (-10)**2 = 100 therefore the square root of 100 is ±10 Mathematicians get around this by defining the square root operator √ as *only* the principle value of the square root relation, that is, the positive root. Hence: √100 = 10 only If you want both roots, you have to explicitly ask for them both: ±√100 Similarly, we can sensibly define the remainder or modulus operator to consistently return a non-negative remainder, or to do what Python does, which is to return a remainder with the same sign as the divisor: 42 % 5 2 -42 % 5 3 42 % -5 -3 -42 % -5 -2 There may be practical or logical reasons for preferring one over the other, but either choice would make remainder a bijection. One might even define two separate functions/operators, one for each behaviour. They might not be willing to define it, but as soon as we programmers do, well, we did. Having studied the contemporary philosophy of mathematics, their concern is probably that in their minds, mathematics is whatever some dead guy said it was, and they dont know of any dead guy ever talking about a modulus operation, so therefore it 'does not exist'. You've studied the contemporary philosophy of mathematics huh? How about studying some actual mathematics before making such absurd pronouncements on the psychology of mathematicians? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
Steven D'Aprano wrote:
Modulo is hardly an obscure operation. What's the remainder...? is a
simple question that people learn about in primary school.
Well, sort of. The way I remember it, the remainder was just
something that fell out as a side effect of division -- the
annoying bit left over that you didn't know what to do with.
We weren't taught to think of finding the remainder as
a distinct operation that's useful in its own right. Once
we were taught to do proper division with decimal points
and everything, the concept of a remainder seemed to get
discarded and was never mentioned again.
A couple of years later we were briefly introduced to the
concept of modulo arithmetic, but as far as I remember, the
connection with division and remainders wasn't pointed out.
Also, it was presented in a very abstract way, and I couldn't
see any practical application for it at the time. (At that
age, it hadn't occurred to me that some of the stuff we
were being shown might be just pure mathematics for its own
sake, and I was often thinking to myself, Why am I being
taught this?)
It wasn't until much later when I got into programming that
I began to see all the connections and applications. For
people who don't become programmers, I suspect they never
have much use for remainders in everyday life.
Now, in a desperate attempt to stop rambling and get back
on topic...
Eelco Hoogendoorn wrote:
The dot is clearly quantitatively in another realm here.
Also it has almost unchallenged supremacy as the attribute
access operator in just about every language having some
form of struct concept, going back to around Algol 68.
Spelling of the mod operator is much more variable.
{'COMMENT': 24, 'DEDENT': 29, 'NL': 46, 'NAME': 256, ':': 30,
'NEWLINE': 83, '-': 1, 'NUMBER': 1, '[': 1, ',': 17, ')': 37,
'(': 37, '%': 2, '.': 48, '==': 1, '*': 1, 'INDENT': 29, ']':
1, '=': 28, 'ENDMARKER': 1, 'STRING': 19}
That gives attribute access being a little less than 7% of the source
code.
However, it's clearly the most commonly used *operator* by
a large margin.
The dot can be easily mistaken for a comma,
Not in my code, because I always put a space after a comma,
and never after an attribute-access dot. (And if you can't
tell whether there's a space there or not, you need a
bigger font or better glasses. :-)
Also, dots sit nicely under my little finger where they're
easy to type. I like dots. Dots are a great goodness.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
For what it's worth, googling for python asterisk gives this as the very first result: http://www.technovelty.org/code/python/asterisk.html which tells you exactly what you're probably wanting to know if you ask that. To check that this phenomemon isn't restricted to asterisks in particular, I also tried python plus equals and got http://stackoverflow.com/questions/2347265/what-does-plus-equals-do-in-python which is also a pretty good result. So the rule of thumb seems to be: if you're trying to google for punctuation, try spelling it out. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 12/11/2011 6:53 PM, Eelco Hoogendoorn wrote: There are other means of finding information than Google. Really. This is really only a very minor point in my argument, so I dont want to put the focus on this. On the contrary, it is a major point. You want us to change the language so you can program by Google. Sorry, aint't gonna happen. Googling 'myprogramminglanguage conceptimtryingtofigureout' is my first, second and third line of defence. Yes, I could read the reference manual from top to bottom, and if I already knew about the existence of your article then im sure that would be a great help too. You left out skimming the table of contents and using the index. On the Windows version of the docs, one can just type the entry wanted in the entry box on the Index tab and the lookup is done for you. Two chars to type for '**'. But the situation one finds oneself in is seeing two asterikses and not even being aware they are particular to function definitions/invocations. If you find a symbol in a particular context, the entry for the context seems a reasonable place to start. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 12/11/2011 6:44 PM, Eelco Hoogendoorn wrote: Can you come up with some terse symbols that will be able to express all of the below and dont make you wish you hadnt rather typed out the names? head, tuple(tail) = iterable head, list(tail) = iterable head, str(tail) = somestring head, generator(tail) = mygenerator The above examples are seldom needed in Python because we have one general method to repeatedly split a sequence into head and tail. it = iter(iterable) # 'it' now represents the sequenced iterable head = next(it) # 'it' now represents the tail after removing the head In other words, next(it) encompasses all of your examples and many more. Because 'it' is mutated to represent the tail, it does not need to be rebound and therefore is not. Iterable unpacking with a *target for leftovers is an entirely different use case. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Verbose and flexible args and kwargs syntax
The above examples are seldom needed in Python because we have one general method to repeatedly split a sequence into head and tail. it = iter(iterable) # 'it' now represents the sequenced iterable head = next(it) # 'it' now represents the tail after removing the head In other words, next(it) encompasses all of your examples and many more. Because 'it' is mutated to represent the tail, it does not need to be rebound and therefore is not. The question in language design is never 'could we do these things before'. The answer is obvious: yes our CPUs are turing complete; we can do anything. The question is; how would we like to do them? So do you think the new head/tail unpacking features in python 3 are entirely uncalled for? I personally quite like them, but I would like them to be more general. -- http://mail.python.org/mailman/listinfo/python-list
Verbose and flexible args and kwargs syntax
No more, or less, explicit than the difference between == and is. == may be taken to mean identity comparison; 'equals' can only mean one thing. Of course 'formally' these symbols are well defined, but so is brainf*ck Modulo is hardly an obscure operation. What's the remainder...? is a simple question that people learn about in primary school. So is 'how much wood would a woodchucker chuck if a woodchucker could chuck wood?'. But how often does that concept turn up in your code? And you can blame C for the use of % instead of mod or modulo. I didnt know one of Python's design goals was backwards compatibility with C. I can't imagine what sort of Python code you have seen that you consider 90% attribute access typical. I've just run the Python tokenizer over my startup.py file, and I get these results: Yes, that was a hyperbole; but quite an often used construct, is it not? If you can supply any function at all, what happens if I write this: You cannot; only constructors modelling a sequence or a dict, and only in that order. Is that rule clear enough? I believe that your proposal leads to an over-generalisation call arbitrary functions when handling parameter lists. I hope the above clears that up. It is as much about calling functions as ** is about raising kwargs to the power of. I don't believe you need this added complication. If you want to your var args as a list, call list(args) inside your function. We dont strictly 'need' any language construct. Real men use assembler, right? / head, tuple(tail) = iterable / In Python 3, that is spelled: head, *tail = iterable tail = tuple(tail) Yes, I know. How is that not a lot more verbose and worse than what I have proposed in all possible ways? head, tail = somestring[0], somestring[1:] Well yes, splendid; we can do that with lists too since the dawn of Python. What you are saying here in effect is that you think the head/tail syntax is superfluous; that youd rather see it eliminated than generalized. head, tail = next(mygenerator), mygenerator Which again of course works, but is yet again of entirely different form than any of the above solutions, while conceptually doing the same thing. Certainly, there is room for improved elegance here? -- http://mail.python.org/mailman/listinfo/python-list
Verbose and flexible args and kwargs syntax
On the contrary, it is a major point. You want us to change the language so you can program by Google. Sorry, aint't gonna happen. On the contrary; I believe I get to decide which points I consider important. This one, I do not. Sorry for putting it in the first paragraph. -- http://mail.python.org/mailman/listinfo/python-list
Verbose and flexible args and kwargs syntax
On the contrary, it is a major point. Sorry, but im affraid it is up to ME to decide which point I feel are important. No, this is a minor point to me, and one that has been admirably put to rest by pointing out that spelling out the name of the symbol in google directly leads you to the information you are looking for. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
Eelco Hoogendoorn writes: As for %; it is entirely unclear to me why that obscure operation ever got its own one-character symbol. Ill take 'mod', or even better, 'modulus' any day of the week. The modulus is not the result but one of the arguments: when numbers x and y are congruent modulo n (stated in terms of the modulo operation: x mod n = y mod n), the modulus is n. A word for x mod n is remainder. I agree about the obscurity of using the percent sign as the operator. A quick google suggests that your use of 'modulus' is now popular among programmers. Past experience in mathematics newsgroups tells me that some mathematicians do not accept the existence of any remainder operator at all. Honest. (I see them but I cannot understand them.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
The modulus is not the result but one of the arguments: when numbers x and y are congruent modulo n (stated in terms of the modulo operation: x mod n = y mod n), the modulus is n. A word for x mod n is remainder. I agree about the obscurity of using the percent sign as the operator. A quick google suggests that your use of 'modulus' is now popular among programmers. Past experience in mathematics newsgroups tells me that some mathematicians do not accept the existence of any remainder operator at all. Honest. (I see them but I cannot understand them.) You are correct; the thing it computes is the remainder, not the modulus. Nonetheless, 'x modulus y' is how it is put in natural language, but I suppose math.remainder would be my preferred place to put this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
By the way... Is there any particular reason why some of my replies do not show up on groups.google, and some of them do not show up on mail.python.org? Sorry to annoy people with reposting, but im going to be forced to do some of that until this is cleared up -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
Eelco writes: The modulus is not the result but one of the arguments: when numbers x and y are congruent modulo n (stated in terms of the modulo operation: x mod n = y mod n), the modulus is n. A word for x mod n is remainder. I agree about the obscurity of using the percent sign as the operator. A quick google suggests that your use of 'modulus' is now popular among programmers. Past experience in mathematics newsgroups tells me that some mathematicians do not accept the existence of any remainder operator at all. Honest. (I see them but I cannot understand them.) You are correct; the thing it computes is the remainder, not the modulus. Nonetheless, 'x modulus y' is how it is put in natural language, but I suppose math.remainder would be my preferred place to put this. I think it's 'x modulo y', which matches 'x and y are congruent modulo z', but now I fear that programming people have been developing a different habit. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
No more, or less, explicit than the difference between == and is. == may be taken to mean identity comparison; 'equals' can only mean one thing. Of course 'formally' these symbols are well defined, but so is brainf*ck Modulo is hardly an obscure operation. What's the remainder...? is a simple question that people learn about in primary school. So is 'how much wood would a woodchucker chuck if a woodchucker could chuck wood?'. But how often does that concept turn up in your code? And you can blame C for the use of % instead of mod or modulo. I didnt know one of Python's design goals was backwards compatibility with C. I can't imagine what sort of Python code you have seen that you consider 90% attribute access typical. I've just run the Python tokenizer over my startup.py file, and I get these results: Yes, that was a hyperbole; but quite an often used construct, is it not? If you can supply any function at all, what happens if I write this: You cannot; only constructors modelling a sequence or a dict, and only in that order. Is that rule clear enough? I believe that your proposal leads to an over-generalisation call arbitrary functions when handling parameter lists. I hope the above clears that up. It is as much about calling functions as ** is about raising kwargs to the power of. I don't believe you need this added complication. If you want to your var args as a list, call list(args) inside your function. We dont strictly 'need' any language construct. Real men use assembler, right? head, tuple(tail) = iterable In Python 3, that is spelled: head, *tail = iterable tail = tuple(tail) Yes, I know. How is that not a lot more verbose and worse than what I have proposed in all possible ways? head, tail = somestring[0], somestring[1:] Well yes, splendid; we can do that with lists too since the dawn of Python. What you are saying here in effect is that you think the head/tail syntax is superfluous; that youd rather see it eliminated than generalized. head, tail = next(mygenerator), mygenerator Which again of course works, but is yet again of entirely different form than any of the above solutions, while conceptually doing the same thing. Certainly, there is room for improved elegance here? -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 12/12/2011 3:09 AM, Gregory Ewing wrote: people who don't become programmers, I suspect they never have much use for remainders in everyday life. Huh? Funny you should say 'everyday'. It is now 10 o'clock. In 20 hours, it will be (10+20) % 12 == 6 o'clock. It is now day 1 of the week. In 9 days it will be day (1+9) % 7 == 3 of the week. Mental calculations are helped by the fact that (a+b) % c == a%c + b%c, so that would actually be 1+2==3. Timekeeping is mostly remaindering, slightly obscured by using 12 instead of 0. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 12/12/2011 5:59 AM, Jussi Piitulainen wrote: Past experience in mathematics newsgroups tells me that some mathematicians do not accept the existence of any remainder operator at all. Even though they carry hour/minute/second remindering devices on their bodies and put year/month/day remaindering devices on their wall? 'Twould be strange indeed! -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 12/12/2011 4:12 AM, Eelco Hoogendoorn wrote: The above examples are seldom needed in Python because we have one general method to repeatedly split a sequence into head and tail. it = iter(iterable) # 'it' now represents the sequenced iterable head = next(it) # 'it' now represents the tail after removing the head In other words, next(it) encompasses all of your examples and many more. Because 'it' is mutated to represent the tail, it does not need to be rebound and therefore is not. The question in language design is never 'could we do these things before'. The answer is obvious: yes our CPUs are turing complete; we can do anything. The question is; how would we like to do them? So do you think the new head/tail unpacking features in python 3 are entirely uncalled for? No, *target unpacking (singular) is quite useful in specialized cases. But it is not specifically head/tail unpacking. a,*b,c = 1,2,3,4,5,6 a,b,c (1, [2, 3, 4, 5], 6) *a,b,c = 1,2,3,4,5 a,b,c ([1, 2, 3], 4, 5) I personally quite like them, but I would like them to be more general. It already is. The *target can be anywhere in the sequence. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
Terry Reedy tjre...@udel.edu wrote: calculations are helped by the fact that (a+b) % c == a%c + b%c, so As long as we understand that == here does not mean equal, only congruent modulo c, e.g try a = 13, b = 12, c = 7. Nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 12 December 2011 15:52, Terry Reedy tjre...@udel.edu wrote: No, *target unpacking (singular) is quite useful in specialized cases. But it is not specifically head/tail unpacking. a,*b,c = 1,2,3,4,5,6 a,b,c (1, [2, 3, 4, 5], 6) *a,b,c = 1,2,3,4,5 a,b,c ([1, 2, 3], 4, 5) I personally quite like them, but I would like them to be more general. It already is. The *target can be anywhere in the sequence. -- Terry Jan Reedy You can even have nested sequences! a, (b, *c), *d = 1, two, 3, 4 -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 12 December 2011 15:36, Terry Reedy tjre...@udel.edu wrote: Huh? Funny you should say 'everyday'. It is now 10 o'clock. In 20 hours, it will be (10+20) % 12 == 6 o'clock. It is now day 1 of the week. In 9 days it will be day (1+9) % 7 == 3 of the week. Mental calculations are helped by the fact that (a+b) % c == a%c + b%c You mean (a + b) % c == (a%c + b%c) % c :) -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Tue, Dec 13, 2011 at 2:55 AM, Nick Dokos nicholas.do...@hp.com wrote: Terry Reedy tjre...@udel.edu wrote: calculations are helped by the fact that (a+b) % c == a%c + b%c, so As long as we understand that == here does not mean equal, only congruent modulo c, e.g try a = 13, b = 12, c = 7. This is the basis of the grade-school casting out nines method of checking arithmetic. Set c=9 and you can calculate N%c fairly readily (digit sum - I'm assuming here that the arithmetic is being done in decimal); the sum of the remainders should equal the remainder of the sum, but there's the inherent assumption that if the remainders sum to something greater than nine, you digit-sum it to get the true remainder. (Technically the sum of the digits of a base-10 number is not the same as that number mod 9, but if you accept that 0 == 9, it works fine.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Tue, Dec 13, 2011 at 3:15 AM, Arnaud Delobelle arno...@gmail.com wrote: You mean (a + b) % c == (a%c + b%c) % c :) It's just integer wraparound. Modulo 9 is the same as render this number in base 9 and take the last digit (and printing a number in base 9 would normally be done with mod 9 division), and most people can wrap their heads around the way an odometer wraps around. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
Terry Reedy writes: On 12/12/2011 5:59 AM, Jussi Piitulainen wrote: Past experience in mathematics newsgroups tells me that some mathematicians do not accept the existence of any remainder operator at all. Even though they carry hour/minute/second remindering devices on their bodies and put year/month/day remaindering devices on their wall? 'Twould be strange indeed! They recognize modular arithmetic but for some reason insist that there is no such _binary operation_. But as I said, I don't understand their concern. (Except the related concern about some programming languages, not Python, where the remainder does not behave well with respect to division.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
I personally quite like them, but I would like them to be more general. It already is. The *target can be anywhere in the sequence. Im not sure if this is a genuine understanding, or trollish obtuseness. Yes, the target can be anywhere in the sequence. And yes, the resulting list can contain objects of any type, so its very flexible in that regard too. But to relate it to the topic of this thread: no, the syntax does not allow one to select the type of the resulting sequence. It always constructs a list. Yes, we can cast the list to be whatever we want on the next line, but the question is whether this language design can be improved upon. The choice of a list feels arbitrary, adding another line to cast it to something else would be even more verbose, and whats more, there would be serious performance implications if one should seek to apply this pattern to a deque/linkedlist; it would make taking off the head/tail of the list from a constant to a linear operation. That is: head, deque(tail) = somedeque Is better in every way I can think of (readability, consistence, performance) than: head, *tail = somedeque tail = deque(tail) -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
They recognize modular arithmetic but for some reason insist that there is no such _binary operation_. But as I said, I don't understand their concern. (Except the related concern about some programming languages, not Python, where the remainder does not behave well with respect to division.) They might not be willing to define it, but as soon as we programmers do, well, we did. Having studied the contemporary philosophy of mathematics, their concern is probably that in their minds, mathematics is whatever some dead guy said it was, and they dont know of any dead guy ever talking about a modulus operation, so therefore it 'does not exist'. Whatever you want to call the concept we are talking about, or whether you care to talk about it at all, it is most certainly a binary operation, since there are two arguments involved. There is no way around that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Monday, December 12, 2011 12:44:27 PM Chris Angelico did opine: On Tue, Dec 13, 2011 at 2:55 AM, Nick Dokos nicholas.do...@hp.com wrote: Terry Reedy tjre...@udel.edu wrote: calculations are helped by the fact that (a+b) % c == a%c + b%c, so As long as we understand that == here does not mean equal, only congruent modulo c, e.g try a = 13, b = 12, c = 7. This is the basis of the grade-school casting out nines method of checking arithmetic. Set c=9 and you can calculate N%c fairly readily (digit sum - I'm assuming here that the arithmetic is being done in decimal); the sum of the remainders should equal the remainder of the sum, but there's the inherent assumption that if the remainders sum to something greater than nine, you digit-sum it to get the true remainder. (Technically the sum of the digits of a base-10 number is not the same as that number mod 9, but if you accept that 0 == 9, it works fine.) ChrisA And that is precisely the reason I have failed to understand why the 1-10 decimal system seems to have hung on for several hundred years when it is clearly broken. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene Grub first, then ethics. -- Bertolt Brecht -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: Terry Reedy writes: On 12/12/2011 5:59 AM, Jussi Piitulainen wrote: Past experience in mathematics newsgroups tells me that some mathematicians do not accept the existence of any remainder operator at all. Even though they carry hour/minute/second remindering devices on their bodies and put year/month/day remaindering devices on their wall? 'Twould be strange indeed! They recognize modular arithmetic but for some reason insist that there is no such _binary operation_. But as I said, I don't understand their concern. (Except the related concern about some programming languages, not Python, where the remainder does not behave well with respect to division.) They are probably arguing that it's uniquely defined only on ZxN and that there are different conventions to extend it to ZxZ (the programming languages problem that you allude to above - although I don't know what you mean by does not behave well wrt division). See http://en.wikipedia.org/wiki/Remainder If you choose one convention and stick to it, it becomes a well-defined binary operation. C99 goes one way, python goes a different way (and mathematics textbooks generally go a third way) and they are all happy, as long as they don't try to talk to each other (e.g., porting C99 programs to python unthinkingly leads to trouble - duh). It was implementation dependent in old C (whatever the hardware would give you), which predictably - with 20-20 hindsight - turned out to be a Very Bad Idea. Nick PS Z = integers, N = non-negative integers -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On 12/12/2011 12:46 PM, gene heskett wrote: On Monday, December 12, 2011 12:44:27 PM Chris Angelico did opine: snip This is the basis of the grade-school casting out nines method of checking arithmetic. Set c=9 and you can calculate N%c fairly readily (digit sum - I'm assuming here that the arithmetic is being done in decimal); the sum of the remainders should equal the remainder of the sum, but there's the inherent assumption that if the remainders sum to something greater than nine, you digit-sum it to get the true remainder. (Technically the sum of the digits of a base-10 number is not the same as that number mod 9, but if you accept that 0 == 9, it works fine.) ChrisA And that is precisely the reason I have failed to understand why the 1-10 decimal system seems to have hung on for several hundred years when it is clearly broken. I assume this was facetious, but in case not, I'd point out that any other number base will have similar modulo characteristics, except for base 2, where all numbers are congruent modulo 1, so it doesn't do much for checking values. For example, if you were using a number system of base 8, you could do casting out sevens by adding the digits together. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Mon, Dec 12, 2011 at 5:21 AM, Eelco hoogendoorn.ee...@gmail.com wrote: You cannot; only constructors modelling a sequence or a dict, and only in that order. Is that rule clear enough? The dict constructor can receive either a sequence or a mapping, so if I write this: def func(a, b, dict(c)): what will I get? Probably I would want the equivalent of: def func(a, b, **c): but you seem to be saying that I would actually get the equivalent of this: def func(a, b, *c): c = dict(c) Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
Eelco writes: They recognize modular arithmetic but for some reason insist that there is no such _binary operation_. But as I said, I don't understand their concern. (Except the related concern about some programming languages, not Python, where the remainder does not behave well with respect to division.) They might not be willing to define it, but as soon as we programmers do, well, we did. Having studied the contemporary philosophy of mathematics, their concern is probably that in their minds, mathematics is whatever some dead guy said it was, and they dont know of any dead guy ever talking about a modulus operation, so therefore it 'does not exist'. Whatever you want to call the concept we are talking about, or whether you care to talk about it at all, it is most certainly a binary operation, since there are two arguments involved. There is no way around that. Yes, I think you nailed it. But I guess I'll still be confused the next time I meet one of them. Happens to me. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
gene heskett ghesk...@wdtv.com wrote: On Monday, December 12, 2011 12:44:27 PM Chris Angelico did opine: On Tue, Dec 13, 2011 at 2:55 AM, Nick Dokos nicholas.do...@hp.com wrote: Terry Reedy tjre...@udel.edu wrote: calculations are helped by the fact that (a+b) % c == a%c + b%c, so As long as we understand that == here does not mean equal, only congruent modulo c, e.g try a = 13, b = 12, c = 7. This is the basis of the grade-school casting out nines method of checking arithmetic. Set c=9 and you can calculate N%c fairly readily (digit sum - I'm assuming here that the arithmetic is being done in decimal); the sum of the remainders should equal the remainder of the sum, but there's the inherent assumption that if the remainders sum to something greater than nine, you digit-sum it to get the true remainder. (Technically the sum of the digits of a base-10 number is not the same as that number mod 9, but if you accept that 0 == 9, it works fine.) ChrisA And that is precisely the reason I have failed to understand why the 1-10 It's not clear from the above what you mean by that is presicely the reason: what is that? decimal system seems to have hung on for several hundred years when it is clearly broken. broken how? Thanks, Nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Dec 12, 7:09 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Mon, Dec 12, 2011 at 5:21 AM, Eelco hoogendoorn.ee...@gmail.com wrote: You cannot; only constructors modelling a sequence or a dict, and only in that order. Is that rule clear enough? The dict constructor can receive either a sequence or a mapping, so if I write this: def func(a, b, dict(c)): what will I get? Probably I would want the equivalent of: def func(a, b, **c): but you seem to be saying that I would actually get the equivalent of this: def func(a, b, *c): c = dict(c) Cheers, Ian Im not sure if I was clear on that, but I dont care what the constructors accept; I meant to overload on the concept the underlying type models. Dicts model a mapping, lists/tuples model a sequence. MI deriving from both these models is illegal anyway, so one can unambigiously overload on that trait. The syntax only superficially resembles 'call the dict constructor with the object passed into kwargs'. What its supposed to mean is exactly the same as **kwargs, but with added flexibility. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Mon, Dec 12, 2011 at 11:17 AM, Eelco hoogendoorn.ee...@gmail.com wrote:
Im not sure if I was clear on that, but I dont care what the
constructors accept; I meant to overload on the concept the underlying
type models. Dicts model a mapping, lists/tuples model a sequence. MI
deriving from both these models is illegal anyway, so one can
unambigiously overload on that trait.
False.
from collections import *
class Foo(Sequence, Mapping):
... def __init__(self, items):
... self._items = items
... def __getitem__(self, item):
... return self._items[item]
... def __len__(self):
... return len(self._items)
...
foo1 = Foo(range(5, 10))
foo2 = Foo({'one': 1, 'two': 2})
foo1[3]
8
foo2['one']
1
Or are you saying that only classes specifically derived from list,
tuple, or dict should be considered, and custom containers that are
not derived from any of those but implement the correct protocols
should be excluded? If so, that sounds less than ideal.
Cheers,
Ian
--
http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
False. I stand corrected. Or are you saying that only classes specifically derived from list, tuple, or dict should be considered, and custom containers that are not derived from any of those but implement the correct protocols should be excluded? If so, that sounds less than ideal. That might be a desirable constraint from an implementational/ performance aspect anyway, but I agree, less than ideal. Either way, its not hard to add some detail to the semantics to allow all this. Even this function definition: def func(Foo(args), Foo(kwargs)) ...could even be defined unambigiously by overloading first on base type, and if that does not uniquely determine the args and kwargs, fall back on positionality, so that: def func(Foo(args), dict(kwargs)) def func(list(args), Foo(kwargs)) would be uniquely defined as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
To get back on topic a little bit, lets get back to the syntax of all this: I think we all agree that recycling the function call syntax is less than ideal, since while it works in special contexts like a function signature, its symmetric counterpart inside a function call already has the meaning of a function call. In general, we face the problem of specifying metadata about a variable, or a limited form of type constraint. What we want is similar to function annotations in python 3; in line with that, we could have more general variable annotations. With an important conceptual distinction; function annotations are meaningless to python, but the annotations I have in mind should modify semantics directly. However, its still conceptually close enough that we might want to use the colon syntax here too. To distinguish it from function annotations, we could use a double colon (double colon is an annotation with non-void semantics; quite a simple rule); or to maintain an historic link with the existing packing/unpacking syntax, we could look at an augmented form of the asteriks notation. For instance: def func(list*args, dict*kwargs) - list-of-args, dict-of-kwargs def func(args::list, kwargs::dict) - I like the readability of this one even better; args-list and kwargs-dict And: head, deque*tail = somedeque head, tail::deque = somedeque Or some variants thereof -- http://mail.python.org/mailman/listinfo/python-list
Re: Verbose and flexible args and kwargs syntax
On Dec 12, 8:05 pm, Eelco hoogendoorn.ee...@gmail.com wrote: To get back on topic a little bit, lets get back to the syntax of all this: I think we all agree that recycling the function call syntax is less than ideal, since while it works in special contexts like a function signature, its symmetric counterpart inside a function call already has the meaning of a function call. In general, we face the problem of specifying metadata about a variable, or a limited form of type constraint. What we want is similar to function annotations in python 3; in line with that, we could have more general variable annotations. With an important conceptual distinction; function annotations are meaningless to python, but the annotations I have in mind should modify semantics directly. However, its still conceptually close enough that we might want to use the colon syntax here too. To distinguish it from function annotations, we could use a double colon (double colon is an annotation with non-void semantics; quite a simple rule); or to maintain an historic link with the existing packing/unpacking syntax, we could look at an augmented form of the asteriks notation. For instance: def func(list*args, dict*kwargs) - list-of-args, dict-of-kwargs def func(args::list, kwargs::dict) - I like the readability of this one even better; args-list and kwargs-dict And: head, deque*tail = somedeque head, tail::deque = somedeque Or some variants thereof As for calling functions; calling a function with the content of a collection type rather than the collection as an object itself is a rather weird special case operation I suppose, but we can cover it with the same syntax: def func(args::tuple, kwargs::dict): funccall(args::, kwargs::) - void type constraint means unpacking, for symmetry with args/kwargs aggregation funccall(::args, ::kwargs) - I like this better, to emphasize it being 'the other side' of the same coin, and quite close to ** syntax Sequence and Mapping unpacking dont need their own symbols, if things are done like this, since in the function declaration the meaning is clear from the type of the annotations used, plus their position, and in the call the meaning is clear from the type of the object undergoing to unpacking operation. -- http://mail.python.org/mailman/listinfo/python-list
