Indexable get method. [1,2,3].get(4) # None

Ideas
22

:smiley:
most likely this: if k not in d or d[k] is default

I just meant to give any example of dict.get usage, doesn’t matter which one or the quality of it.

23

Well, I wouldn’t be able to use it until 2029, as I want my code to be backwards with the most supported versions (if it’s not too difficult to support it). But that doesn’t mean I’ll never use it. For example in 2027 I’ll finally be able to re-use quotation marks in f-strings.

Not everyone writes backwards compatible code, and for those people it would be useful. I do realise we need to find them though…

The only thing I can benefit from today are performance improvements or things that can be backported.

24

Sure, but if you’re trying to say that you wouldn’t use it, at LEAST try an example where you logically would :slight_smile:

This still doesn’t disprove Paul’s statement though. If you’re proposing things that you wouldn’t even use in your own library, it’s going to be VERY hard to convince other people that it should be added to the language. With dict.get, a lot of other people do use it, but the fact that you don’t use it doesn’t dispute that.

25

This is not what I was saying at all. What I meant is.

If:

  1. list.get is a bad construct and I shouldn’t use it.
  2. Because I don’t implement in in my own library
  3. list.get shouldn’t be in the standard library

Then:

  1. dict.get is in standard library and I use it.
  2. I would not implement it in my own library if it wasnt available
  3. dict.get is a bad construct and I shouldn’t use it.

It’s the same reasoning in reverse, nothing more.

3 Likes
26

You have the logic backwards, though. It’s more like this:

  1. Is list.get a good construct?
  2. Well, the person who proposed it isn’t even using it. Nor is anyone else. So, probably not.

Versus:

  1. Is dict.get a good construct?
  2. Lots of people use it. You might not, but lots of other people do. So, probably it is.

You can try to argue that something is a good construct despite you not using it, but you have to prove it in some other way. Whereas with dict.get, all you can show is that YOU aren’t using it - but with so many other people, we have sufficient evidence.

27

That is not what I am saying. You misinterpreting my reasoning and turning it into something ridiculous. I will try one last time.

  1. I want list.get in standard library.
  2. I would use it if it was in standard library.
  3. I would not use my own implementation.

Your argument: “Then it shouldn’t be in the standard library, because you don’t implement it for your own usage”

My contra-argument:

  1. I use dict.get, which is in the standard library
  2. I would not use my own implementation if it wasn’t in the standard library
  3. This doesn’t mean that dict.get should not be in the standard library.

Result: Your argument is invalid.

2 Likes
28

You have to convince people that it’s worth having in the standard library.

I’m not going to prove to you that it SHOULDN’T be in the standad library. You have to prove that it SHOULD.

29

Part of proving it is proving that your arguments against it are invalid.

This was NOT my argument why it should be in the standard library. This was sound reasoning why YOUR argument against is INVALID.

1 Like
30

No. Part of it is making stronger arguments in favour of the proposal.

State your arguments for why it should be in the standard library. At the moment I’ve heard “because I want it to be” and “I would use it if it was”. You’ve been asked whether you need the functionality enough to implement your own local version in the absence of a stdlib implementation, and you have said “no”. That’s fine - although the implication of the question is that the arguments you’ve made so far aren’t compelling (and I brought the issue up in a good-faith attempt to help you strengthen your proposal, by the way).

So do you have any other arguments, or are you going to leave it there (on the understanding that the response so far hasn’t been overwhelmingly positive…)?

2 Likes
31

I do want to point out that trying to argue with people providing invalid arguments is exceedingly annoying and is not going to make people want to provide arguments of their own.

If you are just going to shoot down arguments with nonsensical statements it’s not worth the effort to try. Ofcourse, you (@pf_moore) haven’t done that, but defending clearly invalid arguments like the one provided by @Rosuav is not going to result in good discussions.

I am personally weakly in favor of this proposal, but my primary point right now is that neither side should be using invalid arguments, especially not after it has been pointed out that they are invalid.

(and yes, it is an invalid argument, specifically of the hidden-assumption kind. It assumes that “any idea worth using when it’s builtin is also worth using as a custom function”, which isn’t true (at least not obviously). Syntax and performance difference can be big enough to make a difference)

3 Likes
32

Please don’t put words into my mouth. I did not say that.

33

Exactly! That’s the point, that makes it an hidden assumption. You assumed it, but didn’t state it. Or you assumed something similar, which you also didn’t state. There is a gap in your argument structure which you are somehow bridging in a way that is probably obvious for you, but isn’t obvious to everyone else

3 Likes
34

Neither of you or Chris are following what I am saying. It is hard to prove anything when other party refuses to take time to understand.

For any problem to reach its most optimal conclusion it takes 2 interested parties patiently and respectfully following the course of conversation.

What happens now is that Chris liked your comment 5seconds after you wrote it. Either you two are married or Chris can read at the speed of light. You both treating it as a fight that you have to win, not an opportunity to discuss.

I just came to correct logical mistake on your side of argument. I am not even invested in this. And Chris started attacking me personally out of the blue. Using capital “YOU”, “YOU”, “YOU”, etc.

2 Likes
35

No, I didn’t. But, I don’t think there’s really any point trying this meta-meta-argument here. This thread is not benefiting from further posts from me, and I shall bow out.

I stand by my previous posts: it is not for others to prove that this does NOT belong in the core/stdlib, it is for those proposing it prove that it DOES. There are no hidden assumptions here, this is a simple fact.

36

I completly agree, and I never argued against that. And I still stand by my previous posts.

37

Nor did I.

For the people who think we’re “making bad arguments against the proposal” I’ll repeat what I said:

If you write your own version, and then find that you don’t use it (because it’s not worth the effort to import it, or because what you need isn’t quite the same as the version you wrote, or for some other reason) then maybe the idea wasn’t as good in practice as you hoped it would be.

I offered a reasonable way to validate the usefulness of the idea. @dg-pb chooses not to do that - that’s fine, it just means they’ve lost an opportunity to strengthen their argument (by demonstrating that writing their own version didn’t go the way I described). Going on from there to claim that Chris or I are somehow trying to say “if you don’t implement and use your own version, your proposal is clearly worthless” is a heck of a leap, and is not something I appreciate (and I imagine Chris doesn’t either).

I suggest all parties stop posting for a while and take a breather. At best we’re misunderstanding each other, at worst our frustration is leading people to arguing in bad faith.

1 Like
38
  1. I just came here to give my 2 cents
  2. On my way I spotted reasoning which is not sound
  3. I took liberty to point it out because it is in my interest that decisions regarding python are reached fairly ant to the most optimal outcome
  4. I have been attacked and put to the spot where I have to defend and prove something (as if I was OP or someone who is trying to push this brute force without consideration)

Finally, no I am not going to prove anything to you. I hope we all together can slowly decide what is best. But you aren’t helping it at all.

39

And all I did was kindly replied that “This can be a good test, but don’t think this is decisive factor for all cases (not even majority in my case).” and gave an example why not.

All what happened afterwards from my side was just defending against some nonsense.

1 Like
40

This idea would be really useful for me, but I haven’t implemented it even once. There are few reasons for why I think this happens:

  1. The alternative is not that bad, and people are used to it. It would be much nicer if I didn’t have to write an inline if-else, but that’s a pretty standard syntax, so I’m not going to go out of my way to implement it if this only happens once or twice in a project.

  2. I can’t just “import it once”. I work in a lot of different environments, projects, machines, and this is one of those ideas that probably won’t happen a lot of times in a single project, but happen once in most of them. I also use this a lot when writing very short scripts in which I don’t bother to write almost any function. This is especially useful to me when sanitizing messy data, which I often do in 1-time migration scripts.

  3. From my experience (and maybe this depends on who you’re working with), people aren’t that happy when you add general utilities to a projects, and the potential pushback usually just prevents me from implementing it. Usually this happens because these utilities don’t have a good place to put them in, and a lot of people are against util files. Another reason for pushback is that the inline if-else already happens in other places, so consistency wins.

I’m in favor of this idea. I do recognize the value of your test, but I don’t think it’s perfect, and at least for me, it doesn’t work here.

5 Likes
41

One argument against this proposal that I haven’t seen is the benefit of having small interfaces, which include:

  • errors when an object is passed as the wrong parameter,
  • ease to learn,
  • ease to reason about code, and
  • easier to combine with another disjoint interfaces.

Also, this idea is to add .get to list, but it is much harder to add it to collections.abc.Sequence, which means that either other sequences will have fewer methods than list (an unfortunate inconsistency), or you have to add it to Sequence, which is hard.

Also, I how often do you think you’ll really reach for this out of 100k lines of Python? Maybe 10?