The program starts up, prompts twice for input, then the never completes. Have to do a CTRL-C to stop the program. Tried the code both in Visual Studio and using python in the Command window on Windows 10. Have spent hours putting in debug statements. Appears the consumer processes and the producer process have different in_queue objects, because their memory addresses differ when I print them out using print(f'{in_queue=}') in the producer method and the consumer method. Basically what I have observed with the debug statements is that the producer is loading up what it thinks is in_queue, and when the consumer method checks its version of in_queue, it is always empty. Again, each method has a different address for in_queue.

Consumer reports: in_queue=<multiprocessing.queues.Queue object at 0x0000012EC466BC50>
Producer reports: in_queue=<multiprocessing.queues.Queue object at 0x000002542A32BC50>

If I call bitwise_and() with these values, I get a Python exception:

bits = b'\xf1\x22\x33\x44'
bitfilter = b'\xff\xff\xff\xff'
result = bitwise_and(bits, bitfilter, byteorder='big')

Traceback (most recent call last):
File "/cygdrive/c/TechResources/Python/Practice/./c.py", line 21, in
result = bitwise_and(bits, bitfilter, byteorder='big')
File "/cygdrive/c/TechResources/Python/Practice/./c.py", line 11, in bitwise_and
return result.to_bytes(size, byteorder, signed=True)
OverflowError: int too big to convert

If I drop the signed=True argument in listing 12-38, then I get the expected result of 0xf1223344

def bitwise_and(left, right, *, byteorder):
size = max(len(left), len(right))
left = int.from_bytes(left, byteorder=byteorder)
right = int.from_bytes(right, byteorder=byteorder)
result = left & right
return result.to_bytes(size, byteorder, signed=True)

I am greatly enjoying the book. It's one of the few reference books sitting on my shelf.

Hi Jason,

Thank you for the book!

I believe there are a couple of possible errors in the following code sample: https://github.com/CodeMouse92/DeadSimplePython/blob/main/Ch15/element_generic.py

1. if 'C' in formula.keys(): and if 1 in formula.keys(): in lines 93 and 96 appear incorrect:
   • The first condition with C works because __hash__(self) is implemented as __hash__(element.symbol) which accidentally is the same value as hash("C") changing def __hash__(self) to return hash(self.symbol) + 1 will break this implementation. I don't think such a brittle implementation was intended?
   • The second condition will fail to find any "H" in the compound.

It seems that is both cases, we want to rely on __eq__ instead of __hash__. Then we need to convert formula.keys() into a list, e.g. if 'C' in list(formula.keys()):.

2. @overload doesn't seem to work as intended – comparison with float falls back to the default implementation of eq. For example, print(hydrogen == 1.0) produces the following error:

Traceback (most recent call last):
  File "/Users/kirill/Programming/toy_python/DeadSimplePython/Ch15/element_generic.py", line 120, in <module>
    print(hydrogen == 1.0)
  File "/Users/kirill/.pyenv/versions/3.10.0/lib/python3.10/functools.py", line 915, in _method
    return method.__get__(obj, cls)(*args, **kwargs)
  File "/Users/kirill/Programming/toy_python/DeadSimplePython/Ch15/element_generic.py", line 31, in __eq__
    return self.symbol == other.symbol
AttributeError: 'float' object has no attribute 'symbol'

Best,
Kirill

I'm really enjoying the book so far, trying to write out by hand as many of the exercises as I can.

When I attempt to escape the curly braces in a formatted string, though, it does not recognize the variable I'm passing in. Screenshot attached. This is with Python 3.11. Is there something I'm doing wrong or is this a recent change to Python behavior?

P 224 I don't think that Counter is the equivalent of multiset. In general multisets are containers that can have more than one element per key rather than a count per key.

P 47 first block example the code says "foo %= 51" but the comment says "144.0 % 15" - the comment should contain "% 51" as well

P 47 again I don't see anything saying whether right shift is arithmetic (preserves sign) or logical (shifts in 0s) - this does get a fair amount of coverage later

P 51 does 'and' short-circuit?

P 52 I was a bit suprised reading "print(not score == high_score)" - coming from C++ I expected 'not' to have higher precedence than == but that isn't the case in Python

P52 Walrus operator again I found this a bit surprising. Ordinary = can be chained which I'm used to meaning that '=' returns a result that can be read or written to. But it seems Python assignment chaining isn't really chaining which is why the walrus operator is needed.

P 68 what is the difference between literal patterns and REs?

P 151 init - there can only be one

P 153 new as an constructor. Very confusing from a C++ where 'new' is an allocator and the class constructor is the constructor.

P 318 Fig 11-1 the labelling in the image looks wrong to me (and is right in the text). 'Parent' is c:\windows\system and name is python37.dll

P 326 does path.touch() not update the target filestamp?

P 345 some languages do have separate logical and arithmetic shift operators, like >>> and >>

I enjoyed your interview on the TalkPython podcast so I bought the book. Listing 3-24 contains the code

if (eggs := 7 + 5) == 12:
    print("We have one dozen eggs")
print(eggs)  # prints 12

followed by the statement "The assignment expression is enclosed in parentheses for readability, although I technically could have omitted them." If you omit the parentheses then print(eggs) will print True (from 7 + 5 == 12) instead of 12. Tested with python 3.9.16 and 3.11.3. I've caused bugs in my code by omitting parenthesis around the walrus operator.

Thanks for writing the book.