On 02/28/2017 06:02 PM, Michel Desmoulin wrote:
Le 01/03/2017 à 02:23, Ethan Furman a écrit :
On 02/28/2017 05:18 PM, Michel Desmoulin wrote:
I love this proposal but Guido rejected it. Fighting for it right now
would probably be detrimental to the current proposed feature which
could potentially be more easily accepted.
PEP 463 has a better chance of being accepted than this one does, for
reasons that D'Aprano succinctly summarized.
[...] not really a good reason to reject things for Python
because it's a language with a very diverse user base. Some bankers,
some web dev, some geographers, some mathematicians, some students, some
3D graphists, etc. And the language value obvious, readable, predictable
code for all.
True, but this means that a feature needs to apply to more than one group of folks. While I sympathize (truly!) with
the nightmare you have to deal with, I don't think (and I certainly hope) that that quagmire is not common enough to
justify adding .get() to list/tuple.
An idea has to be useful for more than a small group of code bases to warrant inclusion in the stdlib, and even more so
for a built-in.
Most people on this list have a specialty, because their speciality
don't see a use for the feature doesn't mean there is not one.
So I provided on my last answer an explanation of what I would use it for.
On the bright side, if enough use-cases of this type come up (pesky try/except for a simple situation), we may be able
to get Guido to reconsider PEP 463. I certainly think PEP 463 makes a lot more sense that adding list.get().
--
~Ethan~
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
