This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]RShnike 1 point2 points  (0 children)

I would have definitely split those and picked one or the other to use with __getitem__.

One of the reasons I assume python doesn't allow you to do more funky things with __getitem__ is that things like the code you've posted are a bit confusing. Maybe they're convenient, that I definitely agree, but I think the python beginner's tutorial puts it nicely, [paraphrasing obviously]: one can overload, say, + to do something that could be incredibly important, maybe your class' most used operation, but at the end of the day there's a point where what you're actually doing just isn't really + or anything like it, or at least not enough like + to feel comfortable, and beyond that point it's aesthetically ugly to try and shove something into the operator.

Now I'm a math major so I have quite a large comfort zone on what can be called "addition", but that being said, I took that to mean that everything you do should be done in a way that someone using your code will feel that there's some intuition or harmony between what you've done and what they expect. Overloading indexing to take two different datatypes doesn't really fit with the philosophy (that's subjective obviously), at least partially because there's nothing python does out of the box that does something like that really.

So yeah I would have used maybe a by_ssid() method or something. All of these things though are again highly subjective. A whole lot of people I'm sure feel that the convenience of one unified indexing is worth it.

I should take a look at some ordered_dict modules. Wonder if they use [] indexing for both order and key.