#kafka-python

already hit an issue in pykafka dealing with unicode thanks to python 2 :(

aeroevan: Yeah, I actually went through and tried porting pykafka to py3 the other day and the code base is much messier than kafka-python

lu

oops

luckily my issue was fairly small

having a rebalancing consumer is just so handy though

Yeah, we wrote our own on top of kafka python, we should release it

because I wouldn't feel comfortable recommending pykafka after working in the code base

sontek: curious, what's up with the code base?

Snaps: Its just very messy compared to kafka-python (and kafka-python *is not* a great example of good code :P)

They were doing things like using crc32(data) without & 0xffffffff on it which is very well documented as not compatible across platforms

so py26 would generate different data than py27 and same for py3

Its not horrible but if I had to put my weight behind one driver it'd be the kafka-python one for maintainability

but the parsley guys are much more active than the kafka-python people

But they don't even seem to be running their own tests. When I was porting to python3 I noticed one of the libs they depend on (and maintain) wasn't compatible, so I went and ported it to python3... but noticed it also didn't work in py26 which was defined as supported in the pykafka tox

So I ported it to py26 as well

and then went and ran the pykafka tests on py26 and they failed because pykafka isn't py26 compatible

but it was totally listed in tox, which means no one was actually running tox

looks like their default travis checks are only for 2.7.9

aeroevan: yeap, I fixed that in my py3 branch

but its just a bunch of tiny little bad practices all piled into something that ends up being a big mess

where as kafka-python seems to have developers who truly care about quality

Thanks for your thoughts, sontek.