
On Thu, Feb 12, 2015 at 12:15 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 12 February 2015 at 19:22, Thomas Kluyver <thomas@kluyver.me.uk> wrote:
On 12 February 2015 at 11:14, Paul Moore <p.f.moore@gmail.com> wrote:
(the "new dependency" then would be not supporting Python <3.5 (or whatever))
I've seen this argument a few times on python-ideas, and I don't understand it. By this rationale, there's little point ever adding any new feature to Python, because people who need to support older versions can't use it.
To me, it means that anything that gets added to Python should be significant enough to be worth waiting for.
By posting on python-ideas, you're implicitly prepared to take the long term view - these are ideas that we might be able to really use in a few years. One day, relying on Python 3.5 or above will be completely reasonable, and then we can take advantage of the things we're adding to it now. It's like an investment in code.
That's a fair point. You do make me think - when looking at new features, part of the long term view is to look at making sure a proposal is clean and well thought through, so that it's something people will be looking forward to, not merely something "good enough" to provide a feature.
Evaluating the various proposals we've seen on that basis (and I concede this is purely my personal feeling):
1. + and += on dictionaries. Looking far enough into the future, I can see a time when people will see these as obvious and natural analogues of list and string concatenation. There's a shorter-term problem with the transition, particularly the fact that a lot of people currently don't find the "last addition wins" behavior obvious, and the performance characteristics of repeated addition (with copying). I could see dict1 + dict2 being seen as a badly-performing anti-pattern, much like string +, perfectly OK for simple cases but don't use it if performance matters. And performance is more likely to matter with dicts than strings.
2. | and |=. I can't imagine ever liking these. I don't like them for sets, either. Personal opinion certainly.
3. A dict method. Not sure. It depends strongly on the name chosen. And although it's not a strict rule (sets in particular break it) I tend to think of methods as being mutating, not creating new copies.
4. An updated() builtin. Feels clean and has a nice parallel with sorted(). But it's a common word that is often used as a variable, and I don't think (long term view again!) that a pattern of proliferating builtins as non-mutating versions of methods is a good one to encourage.
A reminder about PEP 448: Additional Unpacking Generalizations ( https://www.python.org/dev/peps/pep-0448/), which claims that "it vastly simplifies types of 'addition' such as combining dictionaries, and does so in an unambiguous and well-defined way". The spelling for combining two dicts would be: {**d1, **d2} Cheers, Nathan
why not create a function, put it on PyPI and collect usage stats
Does anyone seriously believe that people will add a dependency which contains a single three line function?
I'm sorry, that was a snarky suggestion. (Actually my whole post was pretty snarky. Hopefully, this post is fairer.)
I do think this is a reasonable situation to invoke the principle that not every 3-line code snippet deserves to be a builtin. Steven posted a pretty simple updated() function that projects can use, and I don't really understand why people can sometimes be so reluctant to include such utilities in their code.
Anyway, overall I still remain unconvinced that this is worth adding, but hopefully the above explains my thinking better.
Sorry again for the tone of my previous response. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/