4 ms·

Maybe it's just me, but I find: d = {} for k, v in request.items(): try: d[k] = int(v) except (TypeError, ValueError): d[k]

Maybe it's just me, but I find: d = {} for k, v in request.items(): try: d[k] = int(v) except (TypeError, ValueError): d[k] = None much easier to read and understand than: walk_values(silent(int), request) I need to find our what the "silent" attribute does and I'm not sure what type of errors are caught here. Although I'm all for hiding implementation when it's useful, I find it counter-intuitive to do it at this level in python, it makes things harder to read.

tel 12y ago
I feel like this is why types have such a benefit in Haskell. This would be typed walkValues :: (v -> a) -> Map k v -> Map k a silent :: (inp -> Either e a) -> (inp -> Maybe a) Here, `silent` is the contextualized version of a really standard error-ignoring combinator which simply throws away the additional error details conveyed in `Either`. silent' :: Either e a -> Maybe a `walkValues` is an extraordinarily common function usually called `fmap` and its existence tells us that `Map` is a `Functor` instance Functor (Map k) where fmap = walkValues Ultimately, this pattern is really common and would be written in Haskell as fmap (silent' . int) The types ensure it cannot be used incorrect. The notion of `Functor` happy compresses all ideas of "mapping" such as what walk_values is doing.
- tinco 12y ago
  I love Haskell, and I totally agree with you, but I don't think you're making much of a case to people who don't already know Haskell. I'm pretty sure everyone who doesn't grok Haskell reads your post and thinks "Ah there's another Haskell weirdo spouting some weird syntax incomprehensible code." So for them: What tel is saying is that in Haskell you annotate your functions with type information (and if you don't the compiler will generate the info for you), which gives you an immediate understanding of what moves into and out of a function, often making it easier to understand what a high level function does.
  - tel 12y ago
    Additionally, the reason why we have weird typeclasses is that they cut such a wide swath of abstraction that you usually can recognize common functions for various types and minimize the number of things you must memorize.
    - WaxProlix 12y ago
      It's so simple! Thanks, tel!
iv_08 12y ago
This! A 1000 times this!
gknoy 12y ago
If you only see it once, sure. But if you use it as an idiom, it will be clearer once you do know what it does. Similarly, flatten( my_list_of_lists ) is MUCH easier to read than the construct that you end up writing to flatten a list of lists.
couchand 12y ago
Often all you need is an explanatory variable. How about this version: clean_ints = silent(int) walk_values(clean_ints, request) Also it's useful to point out that almost any function call is non-obvious in isolation. If this is part of a larger application that is silently ignoring exceptions elsewhere, you've probably seen a call to `silent` once or twice already today.
bkirwi 12y ago
Oh, it's certainly not just you! I suspect most folks aren't used to writing and reading code in this kind of functional style. In fact, these two blocks probably aren't equivalent... my guess is that `silent` catches all exceptions, since it would be an odd name for a function that just catches `TypeError`. Relying on the reader to learn the name of a function that specific would be completely unreasonable. OTOH, transforming a collection is pretty common, and silencing all exceptions is fairly common as well. (And occasionally even correct!) General-purpose functions like that are often worth the time to learn, since the small dividends from each application soon outweigh the up-front learning cost. IMO, the biggest benefit of small abstractions like this is that they make bigger abstractions easier. The first form is easy for experienced programmers to understand because it's a common pattern, so you don't have to think too much about it. The functional style extracts that pattern and gives it a name, so it appears only as a single token. The resulting code is higher-level, but smaller; and once that extra machinery is out of the way, you have a chance to notice larger-scale patterns that was obscured by all that extra code. As programmers, we already learn to notice repeated calculations and factor those out to a method; the functional style does the same thing with control flow, with the same caveats in terms of extra abstractions and learning cost, and with the same significant benefits.
dustingetz 12y ago
I can see at a glance that the one liner is correct, where the explicit version I have to brainparse the whole thing to know if it is correct. (Once you are fluent in the expanded vocabulary)

tel 12y ago

I feel like this is why types have such a benefit in Haskell. This would be typed walkValues :: (v -> a) -> Map k v -> Map k a silent :: (inp -> Either e a) -> (inp -> Maybe a) Here, `silent` is the contextualized version of a really standard error-ignoring combinator which simply throws away the additional error details conveyed in `Either`. silent' :: Either e a -> Maybe a `walkValues` is an extraordinarily common function usually called `fmap` and its existence tells us that `Map` is a `Functor` instance Functor (Map k) where fmap = walkValues Ultimately, this pattern is really common and would be written in Haskell as fmap (silent' . int) The types ensure it cannot be used incorrect. The notion of `Functor` happy compresses all ideas of "mapping" such as what walk_values is doing.

tinco 12y ago
I love Haskell, and I totally agree with you, but I don't think you're making much of a case to people who don't already know Haskell. I'm pretty sure everyone who doesn't grok Haskell reads your post and thinks "Ah there's another Haskell weirdo spouting some weird syntax incomprehensible code." So for them: What tel is saying is that in Haskell you annotate your functions with type information (and if you don't the compiler will generate the info for you), which gives you an immediate understanding of what moves into and out of a function, often making it easier to understand what a high level function does.
- tel 12y ago
  Additionally, the reason why we have weird typeclasses is that they cut such a wide swath of abstraction that you usually can recognize common functions for various types and minimize the number of things you must memorize.
  - WaxProlix 12y ago
    It's so simple! Thanks, tel!

iv_08 12y ago

This! A 1000 times this!

gknoy 12y ago

If you only see it once, sure. But if you use it as an idiom, it will be clearer once you do know what it does. Similarly, flatten( my_list_of_lists ) is MUCH easier to read than the construct that you end up writing to flatten a list of lists.

couchand 12y ago

Often all you need is an explanatory variable. How about this version: clean_ints = silent(int) walk_values(clean_ints, request) Also it's useful to point out that almost any function call is non-obvious in isolation. If this is part of a larger application that is silently ignoring exceptions elsewhere, you've probably seen a call to `silent` once or twice already today.

bkirwi 12y ago

Oh, it's certainly not just you! I suspect most folks aren't used to writing and reading code in this kind of functional style. In fact, these two blocks probably aren't equivalent... my guess is that `silent` catches all exceptions, since it would be an odd name for a function that just catches `TypeError`. Relying on the reader to learn the name of a function that specific would be completely unreasonable. OTOH, transforming a collection is pretty common, and silencing all exceptions is fairly common as well. (And occasionally even correct!) General-purpose functions like that are often worth the time to learn, since the small dividends from each application soon outweigh the up-front learning cost. IMO, the biggest benefit of small abstractions like this is that they make bigger abstractions easier. The first form is easy for experienced programmers to understand because it's a common pattern, so you don't have to think too much about it. The functional style extracts that pattern and gives it a name, so it appears only as a single token. The resulting code is higher-level, but smaller; and once that extra machinery is out of the way, you have a chance to notice larger-scale patterns that was obscured by all that extra code. As programmers, we already learn to notice repeated calculations and factor those out to a method; the functional style does the same thing with control flow, with the same caveats in terms of extra abstractions and learning cost, and with the same significant benefits.

dustingetz 12y ago

I can see at a glance that the one liner is correct, where the explicit version I have to brainparse the whole thing to know if it is correct. (Once you are fluent in the expanded vocabulary)