Hacker News Reader

Comment by nemetroid | Hacker News Reader

From the article:

  (lambda x, y: x ^ y)(7, 10)
  
  from operator import xor
  xor(7, 10)

> Clearly the second option is more readable.

Clearly, the readable option here is ”7 ^ 10”. The examples are a bit contrived, so readability can’t really be gauged from them.

View on HN

Can't say I agree with you. Off the top of my head, I couldn't remember what the symbol for xor was (since it hasn't come up once in many years of my programming), but I certainly do know what the word xor stands for.

Yes, articles that explain features with simple examples are almost always full of contrived examples. It's unfortunate that people nitpick them, because the alternative is long and complicated examples that can't be understood at a glance.

If you want to do a parity check on a string:

  parity = reduce(xor, map(ord, str))%2

Except Python3 took reduce away in favor of more boilerplate. And yes, there are multiple alternative implementations of the above.

> parity = reduce(xor, map(ord, str))%2

"% 2" will not calculate the parity of the reduced value; it just extracts the least significant bit.

Can you show me an integer whose parity differs from its least significant bit?

Maybe a stupid question but I've never learned much about parity and this sounds like a good opportunity. Can you give some definitions? Are you talking about error checking parity or 'evenness' parity?

I'm guessing the last one since that's what fits your LSB comment(when using 'evenness' not 'oddness'). But in that case I'm not sure your example is doing, my python might be too rusty but is it something like: get the unicode representation(int) of each character in a string, xor the results and get the LSB?

What I meant by parity was 'evenness' -- but the ultimate purpose was to explain the utility of the xor function provided by the operator module.

But, the more useful concept is parity for error detection, which my example clearly fails at.

Note that these two are different:

https://en.wikipedia.org/wiki/Parity_bit

https://en.wikipedia.org/wiki/Parity_(mathematics)

"parity check on a string" tends toward the former interpretation of "parity". You don't do parity checks by looking at only the least significant bit of every code word.

Ah, I understand now. You're right, an actual parity check should reduce the bits of the final result.

> It's unfortunate that people nitpick them, because the alternative is long and complicated examples that can't be understood at a glance.

If the examples don’t show cases where the feature even arguably is the best option, they’re bad examples of the feature. I don’t think that’s nitpicking.

The operator module is not something most python developers will ever need. It's a collection of very low-level tools that will rarely, if ever, be the right choice in a small code snippet. Can we even talk about the existence of these functions in an easy-to-read blog post, if the only 'right way' to use them is a full-blown DSL parser or whatever? Or, can we trust the reader to not run home and refactor their arithmetic to

  #this used to be y = 2 * x + 1 until I read a sweet blog
  y = operator.add(1, operator.mul(2, x))

I really don't see any danger of that, myself.

I honestly think reduce is way more confusing to read than comprehensions or even just a plain for loop, even as someone who has done a lot of functional programming.

If reduce is the outermost function, I might agree. I do prefer the explicitness of foldl and foldr, personally. But, this is the problem with simple examples. Folks just can't help but nitpick every damned thing. Are we adding value to the conversation about the operator module?

> parity = reduce(xor, map(ord, str))%2 Except Python3 took reduce away in favor of more boilerplate. And yes, there are multiple alternative implementations of the above.

You can import functools.reduce to get it back but maybe thats what you meant with more boilerplate

Reply on news.ycombinator.com