Excerpts from Jeremy Dunck's message of Tue Dec 02 02:08:50 +0100 2008: > OK, I have a test failure on deleting job 3-- in fact, the protocol > document here: http://xph.us/git/beanstalkd/tree/doc/protocol.txt > suggests that a job must be reserved to be deleted-- showing NOT_FOUND > if the job is not reserved by the client. > > In other words, I think the tutorial is wrong on this point. Perhaps > a prior version of beanstalkd allowed non-reserved delete?
Recent git versions of beanstalkd allow the deletion of ready jobs [1]. Seemingly the protocol.txt was not updated accordingly. [1] http://github.com/kr/beanstalkd/commit/6334c6 > Also, there is a smaller point that using doctest on dictionaries is > problematic-- the repr() of a dictionary is runtime-dependent because > the key order is undefined. That's why I use `pprint.pprint` which should print dictionaries sorted. > On my system (OS X 10.5 MacBook Pro), pri comes out 2147483648L rather > than 2147483648; this would compare fine if actual python object > comparison were used. Well, I'll use a doctest ellipsis here, then (commit 02e7f13). As the stats outputs are changing between differend beanstalkd versions, only showing a bit of sample output and leaving the details of what stats are available to be explored is the way to go anyway. > As for .watched, what about this: > >>> conn.watched() > ['default'] > >>> conn.watch('spam') > ['default', 'spam'] > >>> conn.watch(['eggs']) > ['eggs'] > > Which is to say, passing a list to .watch() is a reset, passing a > string is an addition? Yes, that's the alternate way I was pondering as well. > > My stance here is that all kinds of 8-bit data must be passed > > transparently, en/decoding on top of that is left to the user (or > > convience libs layered atop beanstalkc). So basically what I'd like to > > have would be Python 3's `bytes` type for job bodies. Any ideas on how > > to achieve that backwards compatibly? > > > > > So maybe assert isinstance(body, str)? > > Yeah, str is the closest we have to bytes in 2.x, so that's what I'd > recommend. As it is right now, without an assert, it's actively > dangerous, since an object may happen to serialize OK but have > unintended results from str() vs. len(). Ok, added the assert for now (commit 1983e46). We'll see how that goes :) -- Regards, Andreas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
