Re: [Python-ideas] PEP: Dict addition and subtraction
On Fri, Mar 15, 2019 at 12:25:22PM +0100, Antoine Pitrou wrote: > Yeah, well I do think "+=" for lists was a mistake. I *still* have > trouble remembering the exact difference between "list +=" and > "list.extend" (yes, there is one: one accepts more types than the > other... which one it is, and why, I never remember; Both accept arbitrary iterables, and the documentation suggests that they are the same: https://docs.python.org/3/library/stdtypes.html#mutable-sequence-types Perhaps you are thinking of the difference between list + list versus list += iterable? [...] > There is a virtue to > > """There should be one-- and preferably only one --obvious way to do > it""" "It" here refers to two different things: "I want to update a dict in place": The Obvious Way is to use the update method; the fact that += works as well is just a side-effect of the way augmented assignments are defined. "I want a new dict that merges two existing dicts": The Obvious Way is to use the merge operator (possibly spelled + but that's not written in stone yet). -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano wrote: > [snip] > > I still remember being told in no uncertain terms by the core devs that > adding a clear() method to lists was a waste of time because there was > already a perfectly good way to spell it with slicing. And then ABCs > came along and now lists have a clear method. So opinions change too. > > I agree with the opinions expressed in the (partially) quoted message but I don't think that this is how this particular change happened. https://mail.python.org/pipermail/python-ideas/2009-April/003897.html ;-) ;-) André Roberge ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Fri, Mar 15, 2019 at 11:54:51AM -0300, Andre Roberge wrote: > On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano > wrote: > > > [snip] > > > > I still remember being told in no uncertain terms by the core devs that > > adding a clear() method to lists was a waste of time because there was > > already a perfectly good way to spell it with slicing. And then ABCs > > came along and now lists have a clear method. So opinions change too. > > > > I agree with the opinions expressed in the (partially) quoted message > but I don't think that this is how this particular change happened. > > https://mail.python.org/pipermail/python-ideas/2009-April/003897.html You proposed that in April 2009, but there was nothing added to the bug tracker for 18 months until it was finally added by Terry Reedy in November 2010, based on discussion in a completely different thread (one about sets!): https://mail.python.org/pipermail/python-ideas/2010-November/008722.html Contrary-wise, a few years earlier the same request had been roundly dismissed by core-devs and Python luminaries as "inane", "redundant" and "trivial". https://mail.python.org/pipermail/python-list/2006-April/356236.html People can change their mind -- something that is dismissed one year may be accepted some years later on. -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Fri, Mar 15, 2019 at 12:34:45PM +0100, Antoine Pitrou wrote: > On Thu, 7 Mar 2019 10:58:02 +1100 > Chris Angelico wrote: > > > > Lots of words that basically say: Stuff wouldn't be perfectly pure. > > Chris, please learn to think twice before contributing what is > essentially a trivialization of someone else's arguments. You're not > doing anything useful here, and are just sounding like an asshole who > wants to shut people up. I don't think you are being fair here, and I'd rather avoid getting into unhelpful arguments about tone and whether Chris is "trivializing" (a perjorative term) or "simplifying" (a more neutral term) Josh's position. But if you feel that Chris (and I) have missed parts of Josh's argument, then by all means point out what we missed. Josh, the same applies to you: I do want to give your objections a fair hearing in the updated PEP, so if you think I've missed something, please point it out. In context, I think Chris' response was valid: he was responding to a post by Josh whose entire argument was that using + for dict merging is an abuse of the + symbol because it isn't like numeric addition. If there is more to Josh's argument, can you point out to me what I have missed please? That's a genuine request, not a rhetorical question. Here's Josh's argument: https://mail.python.org/pipermail/python-ideas/2019-March/055733.html and for context, here is Chris' dismissal of Josh's argument: https://mail.python.org/pipermail/python-ideas/2019-March/055734.html and his explanation of why he is dismissing it. Chris is well within his right to dismiss an argument that doesn't impress him, which he did by summarizing it as "Stuff wouldn't be perfectly pure". (Pure in the sense of being like numeric addition.) I think that's pretty much an accurate summary: Josh apparently doesn't like using + for anything that isn't purely like + for real numbers. He calls using + for concatentation a "minor abuse" of the operator and argues that it would be bad for dict meging to use + because merging has different properties to numeric addition. (He has also criticised the use of + for concatenation in at least one other post.) He even gives qualified support for a dict merge operator: "there's nothing wrong with making dict merges easier" but just doesn't like the choice of + as the operator. He's entitled to his opinion, and Chris is entitled to dismiss it. (Aside: your email appears to have broken threading. I'm not sure why, your other emails seem to be threaded okay.) -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Fri, Mar 15, 2019 at 11:15 AM Steven D'Aprano wrote: > On Fri, Mar 15, 2019 at 10:34:45AM -0700, Brett Cannon wrote: > > > Watch the tone please. > > Brett, you might have missed my comment about wanting to avoid unhelpful > arguments about tone, but if you are going to complain about people's > tone, the considerate thing to do is to say what it is that you're > objecting to. > The phrasing of "just sounding like an asshole who wants to shut people up" is unnecessary. > > Otherwise we're left guessing as to what it is and whether or not you > are making an implied threat to apply the CoC. > No implied "threat". If it was an official warning then I would have said so. > > I responded to Antoine's post earlier, but thought that it was a > respectful disagreement. Do you think that's not the case? > I think it skirts the edge of being disrespectful, hence the request to please be aware of how one comes across. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Code version evolver
On 3/14/19 9:47 PM, Chris Angelico wrote: > What happens when someone wants to support multiple Python versions? > "Requires Python 3.5 or newer" is easy. Forcing people to install the > correct one for each version isn't. What are the reasons why people want to support multiple Python versions, on the 3 series? do they really want? or they need to (may be)? and for how many versions, "from 3.5 or newer" ... forever? will be reasonable possible? IMHO more versions to support, the harder to support. Regards, --francis ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Code version evolver
Le 15 mars 2019 à 19:44:15, francismb (franci...@email.de(mailto:franci...@email.de)) a écrit: > > > On 3/14/19 9:47 PM, Chris Angelico wrote: > > What happens when someone wants to support multiple Python versions? > > "Requires Python 3.5 or newer" is easy. Forcing people to install the > > correct one for each version isn't. > What are the reasons why people want to support multiple Python > versions, on the 3 series? do they really want? or they need to (may > be)? and for how many versions, "from 3.5 or newer" ... forever? will be > reasonable possible? IMHO more versions to support, the harder to support. I think it’s pretty much a requirement for any respectable library, when a library drop support for a Python version, its usefulness drop significantly. > Regards, > --francis > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Left arrow and right arrow operators
On 3/13/19 7:44 PM, David Teresi wrote: > `->` would not be ambiguous in the proposed cases, but it does already > mean something elsewhere in the language as of 3.5: > > def concat(a: str, b: str) -> str: > return a + b > > This could potentially cause confusion (as with the % operator being > used for modulo as well as string formatting). IMHO in that context the asymmetry is still there: (a: str, b: str) -> str And the operator is the function. Regards, --francis ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Code version evolver
Thanks! On 3/15/19 8:56 PM, Chris Angelico wrote: > The same is true of books that discuss the language, blog posts giving > tips and tricks, Stack Overflow answers, and everything else that > incorporates code that people might want to copy and paste. What > version of Python do you need? What's the oldest that it still works > on, and what's the newest before something breaks it? > Backward-incompatible changes make that EXTREMELY hard. > Backward-compatible changes make it only a little bit harder, as they > set a minimum but not a maximum. >... that seems to be a use case for a function like, e.g. "is-python-code(version-to-ask-for, code-snipped)" ;-) (Wanna search the min. and max. python working points/ranges ? loop over e.g. 3.0 .. 3.X) Regards, --francis ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Fri, Mar 15, 2019 at 10:34:45AM -0700, Brett Cannon wrote: > Watch the tone please. Brett, you might have missed my comment about wanting to avoid unhelpful arguments about tone, but if you are going to complain about people's tone, the considerate thing to do is to say what it is that you're objecting to. Otherwise we're left guessing as to what it is and whether or not you are making an implied threat to apply the CoC. I responded to Antoine's post earlier, but thought that it was a respectful disagreement. Do you think that's not the case? -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Raymond Hettinger wrote:
> Frequency of usage: Math provides ∑ and ∏ because they are common. It
> doesn't provide a special operator for sqrt(c**2 - b**2) because the latter
> is less fundamental and less common.
Here's some more information. Below is an example of an area, where
sqrt(c**2 - b**2) is both fundamental and common. And that it might be
helpful for Python to provide a (named) function for this operation.
Whether or not, or how, a symbolic expression should be provided is
another question.
This one example by itself does not refute Raymond's argument. I
certainly think caution is required, in promoting the needs of one
group of users at the expense of another. Best avoided, if possible.
GORY DETAILS
Don Knuth, in METAFONT, implemented special '++' and '+-+' operators,
that he called Pythagorean addition and subtraction. The latter is
precisely Raymond's sqrt(c**2 - b**2), but calculated more efficiently
and accurately.
This is described on page 66 of Don Knuth's METAFONT Book.
https://ctan.org/tex-archive/systems/knuth/dist/mf/mfbook.tex
The `^|++|' operation is called {\sl^{Pythagorean addition}\/}; $a\pyth+b$
is the same thing as $\sqrt{\stt a^2+b^2}$. Most of the ^{square root}
operations in computer programs could probably be avoided if $++$ were
more widely available, because people seem to want square roots primarily
when they are computing distances. Notice that $a\pyth+b\pyth+c=
\sqrt{\stt a^2+b^2+c^2}$; we have the identity $(a\pyth+b)\pyth+c=a\pyth+(
b\pyth+c)$ as well as $a\pyth+b=b\pyth+a$. It is better to use Pythagorean
addition than to calculate $\sqrt{\stt a^2+b^2}$, because the computation
of $a^2$ and $b^2$ might produce numbers that are too large even when
$a\pyth+b$ is rather small. There's also an inverse operation,
^{Pythagorean subtraction}, which is denoted by `^|+-+|'; the quantity
$a\mathbin{+{-}+}b$ is equal to $\sqrt{\stt a^2-b^2}$.
ASIDE - wikipedia
In https://en.wikipedia.org/wiki/Pythagorean_addition, wikipedia using
the symbol \oplus for Pythagorean addition, and does not mention
Pythagorean subtraction.
ASIDE- \pyth and Python
Don Knuth uses \pyth as a macro (shorthand) for Pythagorean. It's got
nothing to do with Python. The METAFONT book goes back to 1986, which
predates Pyth-on by about 5 years. That said, Pythagoras was the
founder of a new way of life, and Python is a new way of programming.
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On 3/15/2019 11:21 AM, Steven D'Aprano wrote: On Fri, Mar 15, 2019 at 11:54:51AM -0300, Andre Roberge wrote: On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano wrote: [snip] I still remember being told in no uncertain terms by the core devs that adding a clear() method to lists was a waste of time because there was already a perfectly good way to spell it with slicing. And then ABCs came along and now lists have a clear method. So opinions change too. I agree with the opinions expressed in the (partially) quoted message but I don't think that this is how this particular change happened. https://mail.python.org/pipermail/python-ideas/2009-April/003897.html You proposed that in April 2009, but there was nothing added to the bug tracker for 18 months until it was finally added by Terry Reedy in Actually, I opened the tracker issue with a succinct message, after the discussion and Guido's approval changed my mind. https://bugs.python.org/issue10516 However, Eli Bendersky wrote the patch with help from others and then merged it. November 2010, based on discussion in a completely different thread (one about sets!): https://mail.python.org/pipermail/python-ideas/2010-November/008722.html -- Terry Jan Reedy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Fri, Mar 15, 2019 at 4:36 AM Antoine Pitrou wrote: > On Thu, 7 Mar 2019 10:58:02 +1100 > Chris Angelico wrote: > > > > Lots of words that basically say: Stuff wouldn't be perfectly pure. > > Chris, please learn to think twice before contributing what is > essentially a trivialization of someone else's arguments. You're not > doing anything useful here, and are just sounding like an asshole who > wants to shut people up. > Watch the tone please. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Why operators are useful
There's been a lot of discussion about an operator to merge two dicts. I participated in the beginning but quickly felt overwhelmed by the endless repetition, so I muted most of the threads. But I have been thinking about the reason (some) people like operators, and a discussion I had with my mentor Lambert Meertens over 30 years ago came to mind. For mathematicians, operators are essential to how they think. Take a simple operation like adding two numbers, and try exploring some of its behavior. add(x, y) == add(y, x)(1) Equation (1) expresses the law that addition is commutative. It's usually written using an operator, which makes it more concise: x + y == y + x(1a) That feels like a minor gain. Now consider the associative law: add(x, add(y, z)) == add(add(x, y), z)(2) Equation (2) can be rewritten using operators: x + (y + z) == (x + y) + z(2a) This is much less confusing than (2), and leads to the observation that the parentheses are redundant, so now we can write x + y + z(3) without ambiguity (it doesn't matter whether the + operator binds tighter to the left or to the right). Many other laws are also written more easily using operators. Here's one more example, about the identity element of addition: add(x, 0) == add(0, x) == x(4) compare to x + 0 == 0 + x == x(4a) The general idea here is that once you've learned this simple notation, equations written using them are easier to *manipulate* than equations written using functional notation -- it is as if our brains grasp the operators using different brain machinery, and this is more efficient. I think that the fact that formulas written using operators are more easily processed *visually* has something to do with it: they engage the brain's visual processing machinery, which operates largely subconsciously, and tells the conscious part what it sees (e.g. "chair" rather than "pieces of wood joined together"). The functional notation must take a different path through our brain, which is less subconscious (it's related to reading and understanding what you read, which is learned/trained at a much later age than visual processing). The power of visual processing really becomes apparent when you combine multiple operators. For example, consider the distributive law: mul(n, add(x, y)) == add(mul(n, x), mul(n, y)) (5) That was painful to write, and I believe that at first you won't see the pattern (or at least you wouldn't have immediately seen it if I hadn't mentioned this was the distributive law). Compare to: n * (x + y) == n * x + n * y(5a) Notice how this also uses relative operator priorities. Often mathematicians write this even more compact: n(x+y) == nx + ny(5b) but alas, that currently goes beyond the capacities of Python's parser. Another very powerful aspect of operator notation is that it is convenient to apply them to objects of different types. For example, laws (1) through (5) also work when n, x, y and z are same-size vectors (substituting a vector of zeros for the literal "0"), and also if x, y and z are matrices (note that n has to be a scalar). And you can do this with objects in many different domains. For example, the above laws (1) through (5) apply to functions too (n being a scalar again). By choosing the operators wisely, mathematicians can employ their visual brain to help them do math better: they'll discover new interesting laws sooner because sometimes the symbols on the blackboard just jump at you and suggest a path to an elusive proof. Now, programming isn't exactly the same activity as math, but we all know that Readability Counts, and this is where operator overloading in Python comes in. Once you've internalized the simple properties which operators tend to have, using + for string or list concatenation becomes more readable than a pure OO notation, and (2) and (3) above explain (in part) why that is. Of course, it's definitely possible to overdo this -- then you get Perl. But I think that the folks who point out "there is already a way to do this" are missing the point that it really is easier to grasp the meaning of this: d = d1 + d2 compared to this: d = d1.copy() d = d1.update(d2) and it is not just a matter of fewer lines of code: the first form allows us to use our visual processing to help us see the meaning quicker -- and without distracting other parts of our brain (which might already be occupied by keeping track of the meaning of d1 and d2, for example). Of course, everything comes at a price. You have to learn the operators, and you have to learn their properties when applied to different object types. (This is true in math too -- for numbers, x*y == y*x, but this property does not apply to functions or matrices; OTOH x+y == y+x applies to all, as does the associative law.) "But what about performance?" I hear you ask. Good question. IMO, readability comes first, performance
Re: [Python-ideas] Code version evolver
On Sat, Mar 16, 2019 at 5:43 AM francismb wrote: > > On 3/14/19 9:47 PM, Chris Angelico wrote: > > What happens when someone wants to support multiple Python versions? > > "Requires Python 3.5 or newer" is easy. Forcing people to install the > > correct one for each version isn't. > What are the reasons why people want to support multiple Python > versions, on the 3 series? do they really want? or they need to (may > be)? and for how many versions, "from 3.5 or newer" ... forever? will be > reasonable possible? IMHO more versions to support, the harder to support. > People who care about backward compatibility will usually have some definition of what they support, such as "this app will run on any Python version shipped by a currently-supported Debian release" (which at the moment means supporting Python 3.4, shipped by Debian Jessie), or "we support back as far as isn't too much of a pain" (which usually means committing to support everything starting from the version that introduced some crucial feature). Either way, there's not usually a "forever", but potentially quite a few versions' worth of support. The same is true of books that discuss the language, blog posts giving tips and tricks, Stack Overflow answers, and everything else that incorporates code that people might want to copy and paste. What version of Python do you need? What's the oldest that it still works on, and what's the newest before something breaks it? Backward-incompatible changes make that EXTREMELY hard. Backward-compatible changes make it only a little bit harder, as they set a minimum but not a maximum. You want to see how bad it can be? Go try to find out how to do something slightly unusual with React.js. Stack Overflow answers sometimes have three, four, or even more different code blocks, saying "this if you're on this version, that for some other version". ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
> On Mar 15, 2019, at 10:51 AM, Guido van Rossum wrote: > > The general idea here is that once you've learned this simple notation, > equations written using them are easier to *manipulate* than equations > written using functional notation -- it is as if our brains grasp the > operators using different brain machinery, and this is more efficient. There is no question that sometimes operators can be easier to manipulate and reason about than equivalent methods. The use of "+" and "*" are a major win for numeric and sequence types. There is also no question that sometimes method names are better than operators (otherwise, we wouldn't use method names at all). APL is an extreme example of a rich set of operators being both powerful and opaque. So, we have to ask whether we're stretching too far from "operators are good" to "we need this operator". Here are some considerations: Frequency of usage: Math provides ∑ and ∏ because they are common. It doesn't provide a special operator for sqrt(c**2 - b**2) because the latter is less fundamental and less common. To me, f=d.copy() followed by f.update(e) arises so rarely that an operator isn't warranted. The existing code is already concise, clear, and rare. Familiarity: We know about + because we use it a lot in addition and concatenation contexts. However, a symbol like ⊗ is more opaque unless we're using it every day for a particular purpose. To me, the "+" operator implies "add/extend" semantics rather than "replace" semantics. Successive applications of "+" are never idempotent unless one operand is an identity element. So for me, "+" isn't familiar for dict merges. Loosely put, it isn't "plus-like". I think this is why so many other languages decided not use "+" for dict merges even when that would have been a trivially easy implementation choice. Obviousness: When working with "+" on numeric types, it is obvious it should be commutative. When using "+" when sequence types, it is obvious that concatenation is non-commutative. When using "+" for mapping types, it is not obvious that it isn't commutative. Likewise, it isn't obvious that "+" is a destructive operation for mappings (consider that adding to a log file never destroys existing log entries, while updating a dict will overwrite existing values). Harmony: The operators on dict views use "|" but regular dicts would use "+". That doesn't seem harmonious. Impact: When a class in the standard library adds a method or operator, the reverberations are felt only locally. In contrast, the dict API is fundamental. Changing it will reverberate for years. It will be felt in the ABCs, typeshed, and every mapping-like object. IMO such an impactful change should only be made if it adds significant new functionality rather than providing a slightly shorter spelling of something we already have. Raymond ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Guido wrote: > There's been a lot of discussion about an operator to merge two dicts. I > participated in the beginning but quickly felt overwhelmed by the endless > repetition, so I muted most of the threads. > But I have been thinking about the reason (some) people like operators, and a > discussion I had with my mentor Lambert Meertens over 30 years ago came to > mind. > For mathematicians, operators are essential to how they think. I agree about the endless repetition. I hope Steven D'A is making good progress with the revised PEP. I think that could help us focus discussion. A few days ago, I drafted but did not send a post on binary operators. Prompted by Guido's helpful post, I'm appending it below. My approach and opinions are not the same as Guido's, but have much in common. Perhaps later, I'll clarify where I agree with Guido, and where my opinions differ. Certainly, I think we have in common an emphasis on usability and in particular readability of code. SUBJECT: Naming things: would having more binary operators help? SUMMARY I'm refocusing our earlier discussion on binary operators. I suggest we discuss the question: Providing more binary operators. When would this make naming things this easier? And when harder? THE PROBLEM Naming things is hard. For example https://hilton.org.uk/blog/why-naming-things-is-hard "Naming is communication. Bad names prevent code from clearly communicating its intent, which is why code with obfuscated names is spectacularly hard to understand. The compiler might not care, but the humans benefit from naming that communicates effectively." AN EXAMPLE One person wrote: using + to merge dicts is simple, non-disruptive, and unlikely to really confuse anyone - so why not? Another person proposed: d1 << d2 merges d2 into a copy of d1 and returns it, with keys from d2 overriding keys from d2. A third person wrote: "|" (especially "|=") *is* suitable for "update" [So] reserve "+" for some alternative future commutative extension A fourth person provided a '+' operator on a subclass of dict, that merged items using a special addition on numeric values. A fifth person suggested adding arrow operators, with symbols '->' and '<-'. A six person said that '<-' would break code valid such as '-2<-1'. A seventh person noted that annotations already use '->' as a symbol. An eighth person said the infix module allows you to write a @cup@ b An nineth person (me) will soon suggest that we add dict.gapfill current.update(changes) # If conflict, prefer value in changes. options.gapfill(defaults) # If conflict, prefer value in options. (and so '+' or '|' for update not so clear). BENEFITS OF BINARY OPERATORS Binary operators, such as '+' allow us to write: c = a + b # Infix notation a += x # mutation or augmented assignment a[key] += x # as above, but 'in place' At school, when we learn arithmetic, we learn it using infix notation. Two plus two is four. Seven times eight is fifty-six. I think the above indicates the benefits of binary operators. Particular when binary operation does not mutate the operands. DIFFICULTIES Sometimes, having few names to choose makes naming things easier. That's obvious. Sometimes, having a wider choose makes naming things easier. Think Unicode's visually similar characters. At present, Python has 20 operators, the majority being binary evaluation operators. https://docs.python.org/3/reference/lexical_analysis.html#operators + - * ** / // % @ << >> & | ^ ~ < > <= >= == != The last row gives the (binary) comparison operators. The symbols '^' and '~' are unary operators. For clarity, I'm thinking of the binary evaluation operators, or in other words '+' through to '|'. Aside: '+' and '-' can be used as binary and unary operators. >>> 5 + -- +++ + -- - 4 1 ONE SUGGESTION The twelve binary evaluation operators sounds a lot, but perhaps some users will need more. Even it might be nice if the same symbol didn't have too many different meanings. Python2 used '/' for both float and integer division. To reduce cognitive overload, Python3 introduced '//' for integer division. >>> 4.3 // 2.1 2.0 For example https://oeis.org/wiki/List_of_LaTeX_mathematical_symbols#Arrows lists 10 types of horizontal arrow, and 6 types of vertical arrow. Providing more binary operators is the motivation for my proposal # https://en.wikipedia.org/wiki/Inclusion%E2%80%93exclusion_principle len( A @cup B) == len( A ) + len( B ) - len( A @cap B ) (By the way, we might prefer 'union' and 'intersection' to 'cup' and 'cap'. Also there are alternatives, such as using $ instead of @, or using Unicode Math Characters.) If there is a shared wish to have more binary operators, it might then be useful to discuss how. DISCUSSION QUESTION Please
Re: [Python-ideas] Code version evolver
Hi Greg, On 3/15/19 5:33 AM, Greg Ewing wrote: > Not really. Having to translate all your source every time a > minor version update occurs would be a huge hassle. PythonUAAS: upload the sources (zipped or packaged) and get them updated back ;-) Regards, --francis ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Code version evolver
On 3/15/19 4:54 AM, Stephen J. Turnbull wrote: > Not really. For example, addition of syntax like "async" and "yield" > fundamentally changes the meaning of "def", in ways that *could not* > be fully emulated in earlier Pythons. The semantics simply were > impossible to produce -- that's why syntax extensions were necessary. But here, the code for versions before that change (e.g. aync) also worked on the new versions? there was not need to translate anything to the new version as it was a backward compatible change. To use the new feature you have to explicitly use that feature. If that so far correct? Thanks, --francis ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Le 15 mars 2019 à 18:52:51, Guido van Rossum (gu...@python.org(mailto:gu...@python.org)) a écrit: … > The power of visual processing really becomes apparent when you combine > multiple operators. For example, consider the distributive law: > > mul(n, add(x, y)) == add(mul(n, x), mul(n, y)) (5) > > That was painful to write, and I believe that at first you won't see the > pattern (or at least you wouldn't have immediately seen it if I hadn't > mentioned this was the distributive law). > > Compare to: > > n * (x + y) == n * x + n * y (5a) Thanks for the insight. I think this omit a very important property of mathematic equations thought, maths is a very strongly typed language which can be a significant improvement for readability. For example, a mathematician working within the space of linear maps over a vector space will easily recognize the meaning of every symbol in: f(a * x + y) = a * f(x) + f(y) And know that the + in the above expression is very different from the meaning of + in: x = a * y + z when he is working over the C complex field. For example, he instinctively knows what 1 / z means in the second case but that 1 / f in the first is completely bogus. In Python there is not that much contextual information, but we can use explicit names to overcome this, for example if I wrote: o = d1 + d2 + d3 you would have no idea what this is but: options = defaults + environment_variables + command_line_arguments is meaningful. ... > Of course, it's definitely possible to overdo this -- then you get Perl. But > I think that the folks who point out "there is already a way to do this" are > missing the point that it really is easier to grasp the meaning of this: > > d = d1 + d2 > > compared to this: > > d = d1.copy() > d = d1.update(d2) Of course. I may have missed something but I don’t understand why INADA Naoki proposal does not get more attention. It is not binary, and we could use names to convey the meaning of the operation: options = dict.merge(defaults, environment_variables, command_line_arguments) His alternative options = defaults.merge(environment_variables, command_line_arguments) could also be used if preferred. Is there really something wrong with this? It would do exactly what most proponent of + want but could be more readable. I agree that the argument of performance may not be very strong as most of the time, the updated dict might be smalls, but it would also solved this elegantly. I’m sorry if what I’m saying is not clear or I’m not able to convey my thoughts clearly as English is not my mother tongue, many others are better suited then me to discuss this proposal on this list but I don’t understand why this possibility is not more discussed. Rémi ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Code version evolver
On 3/15/19 4:54 AM, Stephen J. Turnbull wrote: > The thing about "within 3" upgrades is that that kind of project-wide > annoyance is going to be minimal, because the language is mostly > growing in power, not changing the semantics of existing syntax. Such > changes are very rare, and considered extremely carefully for > implications for existing code. I understand that no one really wants to annoy the language users by breaking the code and that's why those changes are considered carefully. Is that may be because there is no easy way to write a translator? or there is no translator to help transition? > In a very few cases it's possible to > warn about dangerous use of obsolete syntax whose meaning has changed, > but that's very rare too. Ok, it's a starting point. --francis ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Code version evolver
On 3/15/19 2:34 PM, francismb wrote: I understand that no one really wants to annoy the language users by breaking the code and that's why those changes are considered carefully. Is that may be because there is no easy way to write a translator? or there is no translator to help transition? Translating existing code is a small problem when the language changes backwards-incompatibly. The larger problem is unlearning what I used to know and learning a new language. If that happens enough, I'll stop using a language. One of Python's strengths is that it evolves very slowly, and knowledge I work hard to accumulate now remains useful for a long time. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
On 15/03/2019 18:54, Raymond Hettinger wrote: So, we have to ask whether we're stretching too far from "operators are good" to "we need this operator". Here are some considerations: Frequency of usage: Math provides ∑ and ∏ because they are common. It doesn't provide a special operator for sqrt(c**2 - b**2) because the latter is less fundamental and less common. To me, f=d.copy() followed by f.update(e) arises so rarely that an operator isn't warranted. The existing code is already concise, clear, and rare. I think the "less fundamental" in your argument is more relevant than the "less common". Mathematicians will cheerfully invent operators for whatever is fundamental to their field and then use them twice in a paper, but still write out fully common combinations. I would suggest that merging is merging is a fairly fundamental operation for dictionaries, so is a good candidate for an operator. The combination "f=d.copy(); f.update(e)" is rare in my code. I suspect that's partly because it doesn't occur to me that I can do it. Guido's argument about recognisability is strong here. I know that dict.update() exists, and that I can destructively merge dictionaries. The extra step of doing the copy first for a non-destructive merge makes for a much less memorable pattern, to the point where I just don't think of it unless it would be more than usually useful. "f = d | e" (however it gets spelled) is much easier to remember the existence of. Familiarity: We know about + because we use it a lot in addition and concatenation contexts. However, a symbol like ⊗ is more opaque unless we're using it every day for a particular purpose. To me, the "+" operator implies "add/extend" semantics rather than "replace" semantics. Successive applications of "+" are never idempotent unless one operand is an identity element. So for me, "+" isn't familiar for dict merges. Loosely put, it isn't "plus-like". I think this is why so many other languages decided not use "+" for dict merges even when that would have been a trivially easy implementation choice. I'm beginning to be swayed by the arguments that merging is more "or-like" and the right analogy is with set union. Personally I don't find "|" for set union at all obvious, but that argument was lost long ago, and like I said it's just personal. I don't have the same problem you have with the semantics of "+", but when I was a maths student I was used to using "+" as an entirely generic operator not necessarily meaning addition, so it's probably just me. Obviousness: When working with "+" on numeric types, it is obvious it should be commutative. When using "+" when sequence types, it is obvious that concatenation is non-commutative. When using "+" for mapping types, it is not obvious that it isn't commutative. Likewise, it isn't obvious that "+" is a destructive operation for mappings (consider that adding to a log file never destroys existing log entries, while updating a dict will overwrite existing values). I suspect this is a bit personal; I had sufficiently evil lecturers in my university Algebra course that I still don't automatically take the commutativity of "+" over a particular group as a given :-) Nothing is obvious unless you already know it. (There is a probably apocryphal tale of a lecturer in full flow saying "It is obvious that..." and pausing. He then turned to the blackboard and scribbled furiously in one corner for five minutes. "I was right," he said triumphantly, "it is obvious!") Harmony: The operators on dict views use "|" but regular dicts would use "+". That doesn't seem harmonious. Yes, that's probably the killer argument against "+", damn it. Impact: When a class in the standard library adds a method or operator, the reverberations are felt only locally. In contrast, the dict API is fundamental. Changing it will reverberate for years. It will be felt in the ABCs, typeshed, and every mapping-like object. IMO such an impactful change should only be made if it adds significant new functionality rather than providing a slightly shorter spelling of something we already have. I am inclined that adding significant new utility (which this does) is also a good enough reason to make such an impactful change. -- Rhodri James *-* Kynesim Ltd ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] HTML Wrapper
Hello, Steven, This wasn't a question asking for support. The answers I found when searching were different from what I needed, that's why I'm using my own. But I understand the point. Regards, Vlad Le jeu. 14 mars 2019 à 23:43, Steven D'Aprano a écrit : > Hi Vlad, and welcome! > > On Thu, Mar 14, 2019 at 10:00:03PM +0100, Vlad Tudorache wrote: > > Hello, > > > > I'd like to know if there is a basic HTML wrapper for Python, like > > TextWrapper but allowing the generation of HTML from strings or iterables > > of strings. > > This list is for proposing and discussing ideas for new syntax or > functionality for the Python language, not for asking basic support > questions. > > Are you are proposing that Python gets a HTML wrapper? > > If so, it is up to you to do your research first, so that you know the > answer to your question before you propose the idea. You should be able > to tell us what options are available as language features or > third-party libraries. > > If you don't know the answer, there are many places you can ask, > starting with Google and other search engines: > > https://duckduckgo.com/?q=python+html+generator > > and others such as Reddit's /r/learnpython subreddit, Stackoverflow, the > Python-List mailing list, the Python IRC channel, and more. > > https://mail.python.org/mailman/listinfo/python-list > news:comp.lang.python > https://www.reddit.com/r/learnpython/ > https://www.python.org/community/irc/ > > If you still have a proposal after doing your research, we're happy to > hear it. > > > Regards, > > > > Steven > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Code version evolver
On Fri, Mar 15, 2019 at 08:10:58PM +0100, francismb wrote: > On 3/15/19 4:54 AM, Stephen J. Turnbull wrote: > > Not really. For example, addition of syntax like "async" and "yield" > > fundamentally changes the meaning of "def", in ways that *could not* > > be fully emulated in earlier Pythons. The semantics simply were > > impossible to produce -- that's why syntax extensions were necessary. > But here, the code for versions before that change (e.g. aync) also > worked on the new versions? there was not need to translate anything to > the new version as it was a backward compatible change. To use the new > feature you have to explicitly use that feature. If that so far correct? No, it is not a backwards compatible change. Any code using async as a name will fail. py> sys.version '3.8.0a2+ (heads/pr_12089:5fcd3b8, Mar 11 2019, 12:39:33) \n[GCC 4.1.2 20080704 (Red Hat 4.1.2-55)]' py> async = 1 File "", line 1 async = 1 ^ SyntaxError: invalid syntax -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
> On Mar 15, 2019, at 12:28 PM, Rhodri James wrote: > > I suspect this is a bit personal; I had sufficiently evil lecturers in my > university Algebra course that I still don't automatically take the > commutativity of "+" over a particular group as a given :-) Nothing is > obvious unless you already know it. We don't design Python for ourselves. We design it for everyday users. Telling them that they can assume nothing is an anti-pattern. People do rely quite a bit on their intuitions. They also rely on implicit patterns already present in the language (i.e. in no other place is + idempotent, in no other place is + a destructive rather than concatenative or accumulative operator). As for commutativity, + would be obviously commutative for numeric types and obviously noncommutative for sequence concatenation, but for dicts the non-commutativity isn't obvious at all. And since the "|" operator is already used for mapping views, the + operator for merging would be unexpected. What is missing from the discussion is that we flat out don't need an operator for this. Use of explicit method names, update() or merge(), is already clear and already brief. Also, if we're honest with ourselves, most of us would use this less than once a year. So why make a pervasive change for this? Today, at least one PEP was rejected that had a stronger case than this proposal. We should consider asking why other major languages haven't gone down this path. The most likely reasons are 1) insufficient need, 2) the "+" operator doesn't make sense, and 3) there are already clean ways to do it. Also, it seems like the efficiency concerns were dismissed with hand-waving. But usually, coping and updating aren't the desired behavior. When teaching Python, I like to talk about how the design of the language nudges you towards fast, clear, correct code. The principle is that things that are good for you are put within easy reach. Things that require more thought are placed a little further away. That is the usual justification for copy() and deepcopy() having to be imported rather than being builtins. Copying is an obvious thing to do; it is also not usually good for you; so, we have you do one extra step to get to it. Raymond ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
On Sat, Mar 16, 2019 at 12:40 PM Raymond Hettinger wrote: > Also, it seems like the efficiency concerns were dismissed with hand-waving. > But usually, coping and updating aren't the desired behavior. When teaching > Python, I like to talk about how the design of the language nudges you > towards fast, clear, correct code. The principle is that things that are > good for you are put within easy reach. Things that require more thought are > placed a little further away. That is the usual justification for copy() and > deepcopy() having to be imported rather than being builtins. Copying is an > obvious thing to do; it is also not usually good for you; so, we have you do > one extra step to get to it. > I'm not sure I understand this argument. Are you saying that d1+d2 is bad code because it will copy the dictionary, and therefore it shouldn't be done? Because the exact same considerations apply to the addition of two lists, which already exists in the language. Is it bad to add lists together instead of using extend()? ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Code version evolver
On Sat, Mar 16, 2019 at 12:28 PM Steven D'Aprano wrote: > > On Fri, Mar 15, 2019 at 08:10:58PM +0100, francismb wrote: > > On 3/15/19 4:54 AM, Stephen J. Turnbull wrote: > > > Not really. For example, addition of syntax like "async" and "yield" > > > fundamentally changes the meaning of "def", in ways that *could not* > > > be fully emulated in earlier Pythons. The semantics simply were > > > impossible to produce -- that's why syntax extensions were necessary. > > But here, the code for versions before that change (e.g. aync) also > > worked on the new versions? there was not need to translate anything to > > the new version as it was a backward compatible change. To use the new > > feature you have to explicitly use that feature. If that so far correct? > > No, it is not a backwards compatible change. Any code using async as a > name will fail. > > py> sys.version > '3.8.0a2+ (heads/pr_12089:5fcd3b8, Mar 11 2019, 12:39:33) \n[GCC 4.1.2 > 20080704 (Red Hat 4.1.2-55)]' > py> async = 1 > File "", line 1 > async = 1 > ^ > SyntaxError: invalid syntax Though that particular case is a little complicated. Python 3.4.4 (default, Apr 17 2016, 16:02:33) >>> async def foo(): File "", line 1 async def foo(): ^ SyntaxError: invalid syntax Python 3.5.3 (default, Sep 27 2018, 17:25:39) and Python 3.6.5 (default, Apr 1 2018, 05:46:30) >>> async def foo(): ... pass ... >>> async = 1 >>> Python 3.7.0a4+ (heads/master:95e4d58913, Jan 27 2018, 06:21:05) >>> async = 1 File "", line 1 async = 1 ^ SyntaxError: invalid syntax So at what point do you call it a backward-incompatible change? And if you have some sort of automated translation tool to "fix" this, when should it rename something that was called "async"? ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
> On Mar 15, 2019, at 6:49 PM, Chris Angelico wrote: > > On Sat, Mar 16, 2019 at 12:40 PM Raymond Hettinger > wrote: >> Also, it seems like the efficiency concerns were dismissed with hand-waving. >> But usually, coping and updating aren't the desired behavior. When teaching >> Python, I like to talk about how the design of the language nudges you >> towards fast, clear, correct code. The principle is that things that are >> good for you are put within easy reach. Things that require more thought are >> placed a little further away. That is the usual justification for copy() >> and deepcopy() having to be imported rather than being builtins. Copying is >> an obvious thing to do; it is also not usually good for you; so, we have you >> do one extra step to get to it. >> > > I'm not sure I understand this argument. Are you saying that d1+d2 is > bad code because it will copy the dictionary, and therefore it > shouldn't be done? Because the exact same considerations apply to the > addition of two lists, which already exists in the language. Is it bad > to add lists together instead of using extend()? Yes, that exactly. Consider a table in a database. Usually what people want/need/ought-to-do is an SQL UPDATE rather than copy and update which would double the memory requirement and be potentially many times slower. The same applies to Python lists. Unless you actually have a requirement for three distinct lists (c = a + b), it is almost always better to extend in place. Adding lists rather than extending them is a recipe for poor performance (especially if it occurs in a loop): Raymond Performant version s = socket.socket() try: s.connect((host, port)) s.send(request) blocks = [] while True: block = s.recv(4096) if not block: break blocks += [block] # Normally done with append() page = b''.join(blocks) print(page.replace(b'\r\n', b'\n').decode()) finally: s.close() Catastrophic version s = socket.socket() try: s.connect((host, port)) s.send(request) blocks = [] while True: block = s.recv(4096) if not block: break blocks = blocks + [block] # Not good for you. page = b''.join(blocks) print(page.replace(b'\r\n', b'\n').decode()) finally: s.close() ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
On Sat, Mar 16, 2019 at 1:27 PM Raymond Hettinger wrote: > > > On Mar 15, 2019, at 6:49 PM, Chris Angelico wrote: > > > > On Sat, Mar 16, 2019 at 12:40 PM Raymond Hettinger > > wrote: > >> Also, it seems like the efficiency concerns were dismissed with > >> hand-waving. But usually, coping and updating aren't the desired behavior. > >> When teaching Python, I like to talk about how the design of the language > >> nudges you towards fast, clear, correct code. The principle is that > >> things that are good for you are put within easy reach. Things that > >> require more thought are placed a little further away. That is the usual > >> justification for copy() and deepcopy() having to be imported rather than > >> being builtins. Copying is an obvious thing to do; it is also not usually > >> good for you; so, we have you do one extra step to get to it. > >> > > > > I'm not sure I understand this argument. Are you saying that d1+d2 is > > bad code because it will copy the dictionary, and therefore it > > shouldn't be done? Because the exact same considerations apply to the > > addition of two lists, which already exists in the language. Is it bad > > to add lists together instead of using extend()? > > Yes, that exactly. > Okay, fair. Though that doesn't necessarily push people towards operators. Your example from below: > blocks += [block] # Normally done with append() > blocks = blocks + [block] # Not good for you. contrasts two different ways of using operators, not operators vs methods (and as you say, the "good" example is more usually spelled with a method anyway). So I'm not sure what this means in terms of dictionary merging. I'm in favour of having both "merge to new" and "merge into this" operations (spelled as either + and +=, or | and |=, and I'm not fussed which of those is picked). As with everything else, "x += y" can be assumed to be the better option over "x = x + y", but the difference between copy/update and in-place update is the job of augmented assignment, not an operator/method distinction. > Consider a table in a database. Usually what people want/need/ought-to-do is > an SQL UPDATE rather than copy and update which would double the memory > requirement and be potentially many times slower. > (Heh. Funny you mention that example, because PostgreSQL actually implements updates by copying a row and then marking the old one as "will be deleted by transaction X". But that's unrelated to this, as it's a design decision for concurrency.) So in terms of "design pushing people to the performant option", the main takeaway is that, if dict addition is implemented, augmented addition should also be implemented. I don't think that's really under dispute. The question is, should addition (or bitwise-or, same diff) be implemented at all? Performance shouldn't kill that. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
On 2019-03-15 19:05, Jonathan Fine wrote:> Guido wrote: > >> There's been a lot of discussion about an operator to merge two dicts. I participated in the beginning but quickly felt overwhelmed by the endless repetition, so I muted most of the threads. > >> But I have been thinking about the reason (some) people like operators, and a discussion I had with my mentor Lambert Meertens over 30 years ago came to mind. > >> For mathematicians, operators are essential to how they think. > > I agree about the endless repetition. I hope Steven D'A is making good > progress with the revised PEP. I think that could help us focus > discussion. > > A few days ago, I drafted but did not send a post on binary operators. > Prompted by Guido's helpful post, I'm appending it below. My approach > and opinions are not the same as Guido's, but have much in common. > Perhaps later, I'll clarify where I agree with Guido, and where my > opinions differ. > > Certainly, I think we have in common an emphasis on usability and in > particular readability of code. > > > SUBJECT: Naming things: would having more binary operators help? > > SUMMARY > I'm refocusing our earlier discussion on binary operators. I suggest > we discuss the question: > Providing more binary operators. When would this make naming things > this easier? And when harder? > > THE PROBLEM > Naming things is hard. > > For example https://hilton.org.uk/blog/why-naming-things-is-hard > "Naming is communication. Bad names prevent code from clearly > communicating its intent, which is why code with obfuscated names is > spectacularly hard to understand. The compiler might not care, but the > humans benefit from naming that communicates effectively." > > AN EXAMPLE > One person wrote: > using + to merge dicts is simple, non-disruptive, and unlikely to > really confuse anyone - so why not? > > Another person proposed: > d1 << d2 merges d2 into a copy of d1 and returns it, with keys from d2 > overriding keys from d2. > > A third person wrote: > "|" (especially "|=") *is* suitable for "update" > [So] reserve "+" for some alternative future commutative extension > [snip] There was also the suggestion of having both << and >>. Actually, now that dicts are ordered, that would provide a use-case, because you would then be able to choose which values were overwritten whilst maintaining the order of the dict on the LHS. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Code version evolver
On Sat, Mar 16, 2019 at 7:35 AM francismb wrote: > > Thanks! > On 3/15/19 8:56 PM, Chris Angelico wrote: > > The same is true of books that discuss the language, blog posts giving > > tips and tricks, Stack Overflow answers, and everything else that > > incorporates code that people might want to copy and paste. What > > version of Python do you need? What's the oldest that it still works > > on, and what's the newest before something breaks it? > > Backward-incompatible changes make that EXTREMELY hard. > > Backward-compatible changes make it only a little bit harder, as they > > set a minimum but not a maximum. > >... that seems to be a use case for a function like, e.g. > "is-python-code(version-to-ask-for, code-snipped)" ;-) (Wanna search the > min. and max. python working points/ranges ? loop over e.g. 3.0 .. 3.X) > Python 3.5 introduced the modulo operator for bytes objects. How are you going to write a function that determines whether or not a piece of code depends on this? And, are you going to run this function on every single code snippet before you try it? I don't think this is possible, AND it's most definitely not a substitute for backward compatibility. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Despite my poor python skills, i don't think i'd ever use this one. blocks = blocks + [block] # Not good for you. > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
On Sat, Mar 16, 2019 at 2:51 AM Guido van Rossum wrote: > > But I think that the folks who point out "there is already a way to do this" > are missing the point that it really is easier to grasp the meaning of this: > > d = d1 + d2 > > compared to this: > > d = d1.copy() > d = d1.update(d2) > > and it is not just a matter of fewer lines of code: the first form allows us > to use our visual processing to help us see the meaning quicker -- and > without distracting other parts of our brain (which might already be occupied > by keeping track of the meaning of d1 and d2, for example). It seems this example is bit unfair. It is not just method vs operator, because dict doesn't provide outer place version of update() method. In case of set, `s = s1 | s2` can be compared to `s = s1.union(s2)`. So dict example doesn't explain "why add operator instead of method?" > Of course, everything comes at a price. You have to learn the operators, and > you have to learn their properties when applied to different object types. > (This is true in math too -- for numbers, x*y == y*x, but this property does > not apply to functions or matrices; OTOH x+y == y+x applies to all, as does > the associative law.) I think behavior is more important than properties. When we learn operator's behavior, its property is obvious. So main point of using operator or not is consistency. Same operator should be used for same thing as possible. I prefer | to + because the behavior of dict.update() looks similar set.union() rather than list.extend(). Another option I like is add + operator to not only dict, but also set. In this case, + is used to join containers by the way most natural to the container's type. That's what Kotlin and Scala does. (Although Scala used ++ instead of +). ref: https://discuss.python.org/t/pep-584-survey-of-other-languages-operator-overload/977 Regards, -- Inada Naoki ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
On Fri, Mar 15, 2019 at 9:19 PM Inada Naoki wrote: > On Sat, Mar 16, 2019 at 2:51 AM Guido van Rossum wrote: > > > > But I think that the folks who point out "there is already a way to do > this" are missing the point that it really is easier to grasp the meaning > of this: > > > > d = d1 + d2 > > > > compared to this: > > > > d = d1.copy() > > d = d1.update(d2) > [Note that I made a typo in the last line. It should be `d.update(d2)`, no assignment.] > > and it is not just a matter of fewer lines of code: the first form > allows us to use our visual processing to help us see the meaning quicker > -- and without distracting other parts of our brain (which might already be > occupied by keeping track of the meaning of d1 and d2, for example). > > It seems this example is bit unfair. It is not just method vs operator, > because dict doesn't provide outer place version of update() method. > Actually most of my post was exactly about why operators can in some cases be better than functions (which includes methods). > In case of set, `s = s1 | s2` can be compared to `s = s1.union(s2)`. > > So dict example doesn't explain "why add operator instead of method?" > Correct, since most of the post was already explaining it. :-) > > Of course, everything comes at a price. You have to learn the operators, > and you have to learn their properties when applied to different object > types. (This is true in math too -- for numbers, x*y == y*x, but this > property does not apply to functions or matrices; OTOH x+y == y+x applies > to all, as does the associative law.) > > I think behavior is more important than properties. > When we learn operator's behavior, its property is obvious. > So main point of using operator or not is consistency. Same operator > should be used for same thing as possible. > > I prefer | to + because the behavior of dict.update() looks similar > set.union() > rather than list.extend(). > That's a separate topic and I did not mean to express an opinion on it in this post. I simply used + because it's the simplest of all operators, and it makes it easier for everyone to follow the visual argument. > Another option I like is add + operator to not only dict, but also set. > In this case, + is used to join containers by the way most natural to the > container's type. > > That's what Kotlin and Scala does. (Although Scala used ++ instead of +). > ref: > https://discuss.python.org/t/pep-584-survey-of-other-languages-operator-overload/977 This probably belongs in another thread (though IIRC it has been argued to death already). -- --Guido van Rossum (python.org/~guido) ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Wed, 6 Mar 2019 00:46:57 +
Josh Rosenberg
wrote:
>
> Overloading + lacks the clear descriptive aspect of update that describes
> the goal of the operation, and contradicts conventions (in Python and
> elsewhere) about how + works (addition or concatenation, and a lot of
> people don't even like it doing the latter, though I'm not that pedantic).
>
> A couple "rules" from C++ on overloading are "*Whenever the meaning of an
> operator is not obviously clear and undisputed, it should not be
> overloaded.* *Instead, provide a function with a well-chosen name.*"
> and "*Always
> stick to the operator’s well-known semantics".* (Source:
> https://stackoverflow.com/a/4421708/364696 , though the principle is
> restated in many other places).
Agreed with this. What is so useful exactly in this new dict operator
that it hasn't been implemented, say, 20 years ago? I rarely find
myself merging dicts and, when I do, calling dict.update() is entirely
acceptable (I think the "{**d}" notation was already a mistake, making
a perfectly readable operation more cryptic simply for the sake of
saving a few keystrokes).
Built-in operations should be added with regard to actual user needs
(such as: a first-class notation for matrix multiplication, making
formulas easier to read and understand), not a mere "hmm this might
sometimes be useful".
Besides, if I have two dicts with e.g. lists as values, I *really*
dislike the fact that the + operator will clobber the values rather than
concatenate them. It's a recipe for confusion.
Regards
Antoine.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Mon, 4 Mar 2019 16:02:06 +0100 Stefan Behnel wrote: > INADA Naoki schrieb am 04.03.19 um 11:15: > > Why statement is not enough? > > I'm not sure I understand why you're asking this, but a statement is "not > enough" because it's a statement and not an expression. This is an argument for Perl 6, not for Python. Regards Antoine. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Mon, 4 Mar 2019 15:57:38 -0800 Guido van Rossum wrote: > > > Those two points make me uncomfortable with "+=" strictly behaving > > like ".update()". > > And yet that's how it works for lists. (Note that dict.update() still has > capabilities beyond +=, since you can also invoke it with keyword args.) Yeah, well I do think "+=" for lists was a mistake. I *still* have trouble remembering the exact difference between "list +=" and "list.extend" (yes, there is one: one accepts more types than the other... which one it is, and why, I never remember; and, of course, there might be the obscure performance difference because of CPython's execution details). I should not have to remember whether I want to use "list +=" or "list.extend" every time I need to extend a list. There is a virtue to """There should be one-- and preferably only one --obvious way to do it""" and we shouldn't break it more than we already did. Regards Antoine. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Thu, 7 Mar 2019 10:58:02 +1100 Chris Angelico wrote: > > Lots of words that basically say: Stuff wouldn't be perfectly pure. Chris, please learn to think twice before contributing what is essentially a trivialization of someone else's arguments. You're not doing anything useful here, and are just sounding like an asshole who wants to shut people up. Regards Antoine. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Fri, Mar 15, 2019 at 12:20:21PM +0100, Antoine Pitrou wrote:
> Agreed with this. What is so useful exactly in this new dict operator
> that it hasn't been implemented, say, 20 years ago?
One could say the same thing about every new feature. Since Python 1.5
was so perfect, why add Unicode, decorators, matrix multiplication,
async, descriptors, Decimal, iterators, ...
Matrix multiplication is a perfect example: adding the @ operator could
have been done in Python 0.1 if anyone had thought of it, but it took 15
years of numerical folk "whinging" about the lack until it happened:
https://mail.python.org/pipermail/python-ideas/2014-March/027053.html
In some ways, it is often easier to get community buy-in for *big*
changes, provided they are backwards compatible. With a big change,
people often either want it, or don't care one way or another.
(Sometimes because the big change is too big or complicated or difficult
for them to understand -- I feel that way about async. Some day I'll
deal with it, but right now it's so far down my list of priorities that
I have no opinion on anything to do with async.)
But *little* changes are easy enough for everyone to understand, and so
they trigger the impulse to bike-shed. Everyone has an opinion on
whether or not dicts should support an update operator, and whether to
spell it + or | or <- or << or something else.
Or the infamous := operator, which ultimately is a useful but minor
syntactic and semantic change but generated a huge amount of debate,
argument and negativity. A far smaller change to the language than
adding type hinting, but it generated far more argument.
I still remember being told in no uncertain terms by the core devs that
adding a clear() method to lists was a waste of time because there was
already a perfectly good way to spell it with slicing. And then ABCs
came along and now lists have a clear method. So opinions change too.
Things happen when they happen, because if they had happened earlier we
wouldn't still be arguing about them.
> I rarely find
> myself merging dicts and, when I do, calling dict.update() is entirely
> acceptable
The code we write is shaped by the operators and methods that
exist. You use dict.update() because *it exists* so when you want a new
dict merged with another, you write the code that is possible today:
new = spam.copy()
new.update(eggs)
process(new)
and you are content because you "rarely find myself merging dicts".
But perhaps those who *frequently* merge dicts have a different option,
and would prefer to write one line rather than three and avoid naming
something that doesn't need a name:
process(spam + eggs) # or spam|eggs if you prefer
> (I think the "{**d}" notation was already a mistake, making
> a perfectly readable operation more cryptic simply for the sake of
> saving a few keystrokes).
I don't know if it was a mistake, but disatisfaction with its lack of
readability and discoverability is one of the motivations of this PEP.
[...]
> Besides, if I have two dicts with e.g. lists as values, I *really*
> dislike the fact that the + operator will clobber the values rather than
> concatenate them. It's a recipe for confusion.
Are you confused that the update method clobbers list values rather than
concatenate them? I doubt that you are.
So why would it be confusing to say that + does a copy-and-update?
(In any case, popular opinion may be shifting towards preferring the |
operator over + so perhaps confusion over concatenation may not be an
issue in the future.)
--
Steven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
