I pickedValueError here, but if there's a better error type let me know, I'm not super familiar with theemail module.

We should probably useemail.errors.HeaderParseError instead ofValueError.

It would be nice if you could use single quotes for consistency in the module.

Also, the error message seems a bit vague given that it is not too short to fitany value, but too short to hold encoded word. An ascii value would be just fine with the line length). And,Maximum length is a hard to make sense when coming from an exception message.max_line_length is more greppable to me.
What do you think about this error?

max_line_length is too small to fit an encoded word.

+1 forHeaderParseError but@bitdancer has more up-to-date perspective than I might have.

No, a ValueError would be more appropriate here, I think, because it is an error in thevalue of maxlen. This isn't aparsing error, it's arendering error.

Now, that said you might want to consider the fact that in_fold_mime_parameters I deal with this issue by bumping maxlen to 78 rather than raising an error. I'm not sure that was the right choice, but whatever we do, it should probably be made consistent between the two cases. It is so sad that I never came back to fix that XXX comment I left myself :(

Note: I unfortunately am not too likely to see github comments, I get too much noise from that source...I just caught this one by chance. If you need my attention please post on the issue.

Also, the error message seems a bit vague given that it is not too short to fitany value, but too short to hold encoded word. An ascii value would be just fine with the line length). And,Maximum length is a hard to make sense when coming from an exception message.max_line_length is more greppable to me.

I agree that "Maximum length" is not going to be a good error, switching tomax_line_length is a good idea.

Regarding the "encoded word" situation, I guess when I wrote this I had assumed that the RFC chrome was added to every line regardless, but only realized that that wasn't the case through testing. I'm still not entirely clearwhy the encoding chrome is unnecessary for shorter words, but I think the suggested comments at least explainwhen the chrome becomes necessary.

We should probably useemail.errors.HeaderParseError instead ofValueError.

It would be nice if you could use single quotes for consistency in the module.

Also, the error message seems a bit vague given that it is not too short to fitany value, but too short to hold encoded word. An ascii value would be just fine with the line length). And,Maximum length is a hard to make sense when coming from an exception message.max_line_length is more greppable to me.
What do you think about this error?

max_line_length is too small to fit an encoded word.

Slight change to the comment to make it a bit more clear why this bug is trigerred when there is a single world longer thanmaxlen.

# Note: This is only triggered when there is a single word longer than# max_line_length. This is because when we encounter a word longer than max_line_length,# it is broken down into encoded words to fit max_line_length. If the max_line_length isn't# large enough to even  contain RFC 2047 chrome (`?=<charset>?q??=`), we fail.# Hence the 1234567890 at the end of this whimsical subject.

Just to make it clear that Header can have words longer than max line length, as long asmax_line_length > 7 + len(charset) + 1.

(There's an extra space in your comment: "even contain"

HeaderParseError seems right to me too, but maybe@bitdancer has a different opinion?

Actually, the phrase "even contain RFC 2047 chrome (?=<charset>?q??=)" should probably be "even contain RFC 2047 chrome plus one character(?=<charset>?q?x?=)"

Missing period.