Excerpts from Jeremy Dunck's message of Mon Dec 01 15:13:15 +0100 2008:
> Please put a module-level attribute in for the version number, e.g.
>
> __version__ = (0,1,0)
Thanks, will do.
> > 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.
beanstalkc.py includes a __main__ that runs the doctests from TUTORIAL,
so simply run `python beanstalkc.py`. The test runner starts a
beanstalkd used for the tests, so you'll need beanstalkd on your path
for this to work.
> What happens if we try to connect with bad parameters? (I see the
> socket would fail, but demonstrating it would be good.)
beanstalkc.Connection will simply pass along the error from the socket,
i.e. error 111 'Connection refused'. Do you mean that adding an example
to the tutorial would be worthwhile?
> 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.
Thanks. I added the causing command to the CommandFailed and
UnexpectedResponse exceptions (commit 0c3462a).
> 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?
Yes, that was exactly the rationale behind it.
Earlier, I had `using` and `watching` properties that where read/write
and mapped to USE/USING/WATCH/IGNORE/LIST-WATCHES. I changed that to
methods directly mapping to the beanstalkd protocol to make it
absolutely transparent when something is sent over the wire. 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')`.
> In general, more discussion about what happens to the parameter of
> .put and .reserve would be useful.
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)?
Hm, yes, that might be a good start.
> 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.)
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 :)
> 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.
beanstalkc is currently tracking the git version of beanstalkd,
protocol-wise. Once this becomes a stable, versioned beanstalkd release
again, I'll add such a link, thanks.
> 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.
Yes, thanks.
> I think .interact_*'s have some bugs-- should be ['NOT_FOUND'], etc.
Thanks, fixed it (commit 2758972).
> Anyway, looks like a nice start, and thanks for sharing.
Thanks for the extensive feedback!
--
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
-~----------~----~----~----~------~----~------~--~---
