On Mon, Dec 1, 2008 at 12:48 PM, Andreas Bolka <[EMAIL PROTECTED]> wrote: ... >> > The other major current feat of beanstalkc is the extensive tutorial, >> > which documents almost all of beanstalkc/d's capabilites and also >> > provides automatically executable tests via Python's doctest module.
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? 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. The common solution is to create a dictionary with the expected results and then have a line like: >>> expected == actual True 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. ... > I'm > thinking about adding convenient properties (`used`, `watched`) again, > in addition to the protocol methods. `con.watched = ['foo', 'bar']` is > just so much more convenient than `con.watch('foo'); con.watch('bar'); > con.ignore('default')`. Eh, I think the rationale is fine, and the .used() vs. .used is a small matter-- probably better to keep one way to do it. 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? > 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(). > Yeah, I know, but I'm not a big fan of those _-methods (they're kinda > ugly), and "proper" private methods would be those name-mangling > __-prefixed things (even more ugly). I'd rather leave it as it is for > now, but I guess I would give in to pressure and/or good reason :) It's not a huge deal to me-- it just seems like having some indication of protocol vs. client choices would be good. .<tab> being the list of methods you're likely to use often seems like a win. ... > Thanks for the extensive feedback! And thanks for the quick response. :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
