I think the most likely problem has already been isolated, but maybe the subtlety of the explanation got lost somewhere in the dialog.
Xmodem, AFAIK (it's been a while) requires an up-front negotiation before it will transfer data. Typically, you can't have two programs on the PC claiming access to the serial port, so if you have the serial monitor open to read your debug printlns, then the Python Xmodem receiver script is probably not also running. This would cause a negotiation failure, resulting in an error.
It's a little like two people trying to talk over the telephone, but instead of party A calling to talk to party B, A calls C to demonstrate how party B won't say "hello" back, so there must be something wrong with the line. The obvious fault being that party B isn't on the line to hear "hello" and say "how do you do" back. I'm not sure if that analogy helps or makes things worse.
At any rate, stop listening with the serial monitor and start your Python script before you assume your library isn't working. Use diagnostic LEDs to show script progress, or if you're crafty, set up a second serial link with NewSoftSerial and a MAX232, or use SPI to a second Arduino and have it echo your messages back via its serial port.
As to why you didn't see anything in the monitor, there are possible explanations for that. I don't remember what Xmodem's conversation starter looks like, but it may not be printable. OR it could be a string followed by backspace characters. Remember, Xmodem was used back in the BBS days, where the server would send control sequences to the terminal client, which would be echoing everything to the screen until some protocol signature was detected and the transfer code took over. Given that heritage, it's also likely the Xmodem receiver script won't be bothered in the least by text preceding and following the file transfer. That would assume a proper and robust implementation, of course...