A common method I've seen to get around that is to first hash the password with something like SHA512 before applying bcrypt. This allows you to use longer passwords as well as setting them all to a constant length for bcrypt (which can potentially remove a ddos vector).
One could argue that above 56 bytes the truncation wouldn't matter for security anymore, since you already have quite a bit of entropy to spare in my opinion.
>One way to work around it is by using SHA-256 first and then BCrypt the result. In your case it would be something like
>hashpw(sha256('pass'), salt)
And if that doesn't roll with you, ignoring the extra characters and giving a warning when the password is set is still a way better UX than forcing your users to remember the arbitrary password length limitation you picked.
"My password for this site should be 'horse battery staple correct', but it doesn't fit. I can type only 'horse battery sta'. Let's see, oh, it doesn't work. Guess I've truncated on word boundary. But did I include the trailing space?..."