Anders Hovmöller writes: > Sure. And if library authors want to support older versions they'll > have to vendor this into their own code,
You (indirectly) argue below that they can't, as a reason for including the change. You can't have it both ways. > just like always. This seems totally irrelevant to the > discussion. And it's of course irrelevant to all the end users that > aren't writing libraries but are using python directly. No, it's not "irrelevant". I wish we all would stop using that word, and trying to exclude others' arguments in this way. We are balancing equities here. We have a plethora of changes, on the one side taken by itself each of which is an improvement, but on the other taken as a group they greatly increase the difficulty of learning to read Python programs fluently. So we set a bar that the change must clear, and the ability of the change to clear it depends on the balance of equities. In this case, where it requires C support and is not possible to "from __future__", the fact that library maintainers can't use it until they drop support for past versions of Python weakens the argument for the change by excluding important bodies of code from using it. > Putting it in a library virtually guarantees it will never become > popular. Factually, you're wrong. Many libraries have moved from PyPI to the stdlib, often very quickly as they prove their worth in a deliberate test. Also, here "popular" has a special meaning. It doesn't mean millions of downloads. It means people say they like it in blogs, recommend it to others, and start to post to Python development channels saying how much it improves their code and posting examples of how it does so. > And because we are talking about new methods on str, a > library that monkey patches on two new method on str won't become > popular for obvious reasons [specifically, it's impossible]. This is a valid point. But it doesn't need to be a monkey patch. Note that decimal was introduced with no literal syntax and is quite useful and used. If this change is going to prove it's tall enough to ride the stdlib ride, using a constructor for a derived class rather than str literal syntax shouldn't be too big a barrier to judging popularity (accounting for the annoyance of a constructor). Alternatively, the features could be introduced using functions. Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
