On Sun, Nov 30, 2008 at 6:00 PM, Andreas Bolka <[EMAIL PROTECTED]> wrote:
>
> I've released version 0.1.0 of beanstalkc, a simple beanstalkd client
> library for Python.
FWIW, I just started following beanstalk a bit, and my primary
production language is Python. I am happy to see some activity on a
client; I was just about to start whacking on pybeanstalk, and this
muddies the water a bit. Are pybeanstalk users active here? Are
people (other than the original authors) using pybeanstalk in
production?
Please put a module-level attribute in for the version number, e.g.
__version__ = (0,1,0)
> 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.
What's the command-line for running the tutorial source? I'm used to
doctests being embedded as docstrings. I understand the utility of
the tutorial also being a test.
> In the future, additional interfaces might be layered atop beanstalkc to
> more conveniently accommodate various usage patterns.
Feedback:
What happens if we try to connect with bad parameters? (I see the
socket would fail, but demonstrating it would be good.)
I think it'd be useful to have exceptions which represent the various
modes of failure be subclasses of CommandFailed. For example,
StatsCommandFailed. I bring this up because I expect there to be
places where multiple beanstalkc API calls are made with one wrapping
try/except-- in this case, the cause of CommandFailed would be
ambiguous.
Also, I notice that pretty much everything is a function, including
things like "using". "using" shouldn't have a side-effect, so I'm not
sure why you'd make it a method. It would be good to mention your
rationale-- maybe anything that hits the wire is a method, anything
local is a property?
In general, more discussion about what happens to the parameter of
.put and .reserve would be useful. I see .put expects len(body) and
str(body) to usefully serialize-- but I think this needs to be
explicitly stated. In general, eval(str(obj)) != obj, and certainly
str(obj) != obj. (What if I call
beanstalk.put({'weapon':'grenade'})-- what do I get when I call
beanstalk.reserve()-- len({'weapon':'grenade}) == 1.)
So maybe assert isinstance(body, str)? I'd be for doing something
more generally applicable like yaml.dump, but I understand your
minimalist goals here.
I see you have "# -- public interface --". OK, all the non-public
methods should be renamed from cheese to _cheese. (A reasonable
person might be tempted to call .interact, but no reasonable person
would call ._interact.)
I think Connection's docstring should link to the protocol document,
and it'd be useful to have a table of beanstalkc version to server
protocol version.
It'd be good to mention that Connection is not thread-safe, since a
single socket is shared with no locking. This is an important point
for something useful in concurrency.
In general, I like the factoring of .interact and .interact_*.
I think .interact_*'s have some bugs-- should be ['NOT_FOUND'], etc.
in the call to .interact_job. 'test' in 'test' is True, but so is
'test' in 'notatest', so doing in-string is dangerously different than
in-list. (I have forked your repo on github, but want to verify that
you'll be accepting patches before I spend much time on it, and of
course, knowing how to run the tests would help.)
Anyway, looks like a nice start, and thanks for sharing.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
