[Python-ideas] get() method for list and tuples

[Kyle Lahnakoski]

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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/