From b3d9def00d9f94cda6aa8eea061e8458cc4d33f2 Mon Sep 17 00:00:00 2001 From: Tim Gates Date: Wed, 24 Nov 2021 22:01:25 +1100 Subject: [PATCH] docs: Fix a few typos There are small typos in: - beanstalk/protohandler.py - tests/test_MultiServerConn.py - tests/test_ServerConn.py Fixes: - Should read `until` rather than `untill`. - Should read `yield` rather than `yeild`. - Should read `synchronous` rather than `syncronous`. - Should read `mapping` rather than `mappaing`. - Should read `guaranteed` rather than `garunteed`. - Should read `containing` rather than `conatining`. --- beanstalk/protohandler.py | 8 ++++---- tests/test_MultiServerConn.py | 2 +- tests/test_ServerConn.py | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/beanstalk/protohandler.py b/beanstalk/protohandler.py index 873ede1..7286e3f 100644 --- a/beanstalk/protohandler.py +++ b/beanstalk/protohandler.py @@ -14,15 +14,15 @@ The implementation is designed so that there is a function for each possible command line in the protocol. These functions return the command line, and a function for handling the response. The handler will return a ditcionary -conatining the response. The handler is a generator that when fed data will -yeild None when more input is expected, and the results dict when all the data +containing the response. The handler is a generator that when fed data will +yield None when more input is expected, and the results dict when all the data is provided. Further, it has an attribute, remaining, which is an integer that specifies how many bytes are still expected in the data portion of a reply. This may seem a bit round-about, but it allows for many different styles* of programming to use the same bit of code for implementing the protocol. -* e.g. the simple syncronous connection and the twisted client both use this :) +* e.g. the simple synchronous connection and the twisted client both use this :) NOTE: there are mre lines of documentation in this file than lines of code. It may be that I need to practice terseness in this form as much as i do with @@ -285,7 +285,7 @@ def process_reserve_with_timeout(timeout=0): DEADLINE_SOON Note: After much internal debate I chose to go this route, - with hte one-to-one mappaing of function to protocol command. Higher level + with hte one-to-one mapping of function to protocol command. Higher level objects, like the connection objects, can combine these if they see fit. ''' if int(timeout) < 0: diff --git a/tests/test_MultiServerConn.py b/tests/test_MultiServerConn.py index ad6cf07..525fe38 100644 --- a/tests/test_MultiServerConn.py +++ b/tests/test_MultiServerConn.py @@ -305,7 +305,7 @@ def test_tube_operations(): # because the protocol blocks when we try to reserve a job, theres not a # good way to test that it does not return when the watchlist doesn't - # include this job, untill threading/async is better anyway + # include this job, until threading/async is better anyway # out of orderness is a good test tho... :) job = newjob_.Server.reserve() diff --git a/tests/test_ServerConn.py b/tests/test_ServerConn.py index 2157b50..c617b17 100644 --- a/tests/test_ServerConn.py +++ b/tests/test_ServerConn.py @@ -176,7 +176,7 @@ def test_tube_operations(): testlist = ['foo','bar','baz'] conn.watchlist = testlist - # ordering may not be garunteed, sets dont care! + # ordering may not be guaranteed, sets dont care! assert set(conn.watchlist) == set(testlist) assert set(conn.list_tubes_watched()['data']) == set(testlist) @@ -194,7 +194,7 @@ def test_tube_operations(): assert conn.stats()['data']['current-jobs-ready'] == 2 # because the protocol blocks when we try to reserve a job, theres not a # good way to test that it does not return when the watchlist doesn't - # include this job, untill threading/async is better anyway + # include this job, until threading/async is better anyway # out of orderness is a good test tho... :) job = conn.reserve()