The problem is that the data is arbitrary. While everything you suggest is absolutely correct, this ain’t the arena for it. This is meant simply as a quick and dirty tool to help parse logs on the spot to detect unusual activity, not long-term analysis. Most of the time, the red highlight is unnecessary anyway – you’ll be able to tell immediately which value occurs an unusual number of times, regardless of what the distribution is. I may do away with it entirely, since it is, as you pointed out, not entirely correct.

Richard’s syntax is fine if all you’re interested in is the type. However, he is interested in the capabilities. So the part that didn’t make it into his post is that you’d have to define an interface-like structure somewhere to say what “iterable” means – what methods it has to support in order to satisfy the requirement. Then you get to the part where you also have to define the signatures for all those methods. If those methods have turkey type requirements, you have to define all of those subtypes somewhere too. To me, it seems easier to just do (pseudo)

if (foo.iter):
    for bar in foo:
        if isinstance(bar, SomeClass):
            bar.DoEeeeet()

I’ll concede that I’ve presented another weak example after pointing out weaknesses in Richards. Your point is well taken.

The more I think about it, the more I don’t see why this has to be a syntax change at all. I believe what Richard wants can be accomplished using some pretty generic helpers. Maybe I’ll talk to him about that possibility.

Where python really fails is that if you want this strictness, it makes it a horrible pain to achieve, if not impossible. And while I consider Richard’s syntax examples ugly, they’re far prettier than what someone has to do in python.

Your Photo/Video example is semi-silly. You know that even in these “generic” actions, the first time they were coded, they likely have Photo-specific code in them. So, you need to go through them and fix that when you decide you’re going to do video. That’s just a given. And if it truly generic, Richard’s Turkey-typing does not require superclasses, just you to specify [Photo,Video] instead of Photo, once you verify the method is not Photo-specific.

I tend to fall on Richard’s side on this one, but maybe that’s because I live in a world where sometimes the people you write code with weren’t hired for their coding, but instead for their knowledge of chemistry, and it just so happens that they need to write some code to try out some ideas, and you want it to be in an easy dynamic language, but you find them running into things like what Richard discusses in his posts. And C has different problems. I feel like Richard’s ideas would result in a better Python ecosystem, where there are clearer error messages instead of some deep backtrace of an uncaught exception (often from a C extension when you’re in the world of scientific computing, which means the deepest levels of the backtrace are not in Python and not your standard ValueError type problems).

Of course I’ve never actually tried this in production anywhere, and I can’t remember where I heard about this tactic, but aside from the join it seems just clever enough to work.

Plot yourself a histogram where you are counting how many people make 1 request, 2 requests, etc (bins may need to be wider, depending on how much data you have, but I feel like you can get a lot). If you actually get a Gaussian, then you’re okay using those, but you might get something else. In which case, hit the statistics books some more to try to decide what you have. (one hint, if it’s bimodal, you probably have the sum of two distributions, say one is normal users, one is power users, in which case, you may be able to split out power users, treat them as a gaussian, then look for outliers 2 or 3 std dev above that mean.)

The code for get_safe_settings is here: http://code.djangoproject.com/browser/django/trunk/django/views/debug.py#L13