I must mention a get() method for lists and tuples would be very useful for me too. It is so useful, that I spent too much time making my own module to handle this case, plus many of the other dealing-with-None subjects found on this list. Michel is correct to point out that this is domain specific problem; a domain where you deal with many varied, and schema-free, data formats. I deal with JSON emitted from multiple systems of often-changing schemas. In my experience, this is not a result of bad or buggy programming, rather, it is about representing facts and annotating them with a multitude of optional properties and descriptive structures.
Now, in the specific case of list.get(), I would be disappointed that it is used to extract parameters from an arg list: Parameters should be named; packing them into an ordered list looses that important information, but it happens[1], and list.get() would help. For the args scenario, I do like Ed's solution: dict(enumerate(args)). In conclusion, I may have talked myself out of liking list.get(): Python has a fundamentally different philosophy about None that conflicts with what I need for my domain [2] where I am transforming and interpreting data. Using a set of classes that make a different set of assumptions about None is not arduous, it keeps the definitions separate, and I still get all wonderfulness of Python. [1] also happens when reading csv files: Missing values indicate default, or variable number of columns indicate that the missing rightmost columns are all null. [2] For Python, None is a missing value, or a special case. For data transformation, None means "the operation you performed does not apply to this datatype" which avoids exceptions, which gives you an algebra over data (with [], dot and slice as operators), which allows you to build complex list comprehensions (data transformation queries) without the exception catching logic. Databases query languages do this. On 2017-02-28 21:02, 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. >> >> -- >> ~Ethan~ > The debate is not even over and you are already declaring a winner. > That's not really fair. Give the idea a chance and read until the end. > > D'Aprano's argument is mostly "I don't encounter IndexError really often > and when I do I have this twisted one liner to get away it". > > Well, that's 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. > > 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. > > > _______________________________________________ > 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/
