If you mean comparing "file" == b"file" that's not possible on several levels.
Firstly, even if you say "just compare the bytes", the computer doesn't know what byte-format you want for "file". Sure, it's "Unicode", but is it UTF-8 or UTF-16 or what? Those choices will produce different results, and the computer cannot accurately guess the right one for you.
Secondly, that violates Python's normal rules by introducing type juggling. It's equivalent to asking for expressions like ("15"==15) or ("True"==True) to work, and involves all the same kinds of long-term problems. (Don't believe me? Work in PHP for a few years...)
As for character sets/code points:
A byte string is simply a string that is using the lower ASCII characters (< 127). The code points for "file" map cleanly to the same code points in any Unicode encoding.
Furthermore, even for ascii sequences like b"file" the bytes do not map to the string "file" in every Unicode encoding - for example, in UTF-16 the bytes of b"file" represent "楦敬", which is a bit different than "file".
I thought Python was strongly-typed ? Am I incorrect in this regard ?
This behavior is a key requirement for all kinds of Python core data structures, for example, if you'd define bytestrings so that they throw an error when compared to a "normal" string, then this means that for a heterogenous list (pretty much all data structures in Python can be heterogenous regarding data types) containing both b"something" and "something" many standard operations (e.g. checking if "something" is in that list) would break because the list code would require a comparison to do that.
Not when it's a string literal like in your example.
The string "foo" has no file, not in the past, present, or reasonably-predictable future. Ditto for the literal bytes.
> It then also has to know what the encoding of the b"file" string is because it is explicitly specified.
Explicitly specified by who? Where? When?
They're just bytes, they don't have a text-encoding yet, or perhaps never: It could be a picture file, or a random seed.
Is Python not parsing/compiling the source file ? Does the "foo" string constant not live in such a source file ?
<< Explicitly specified by who? Where? When? >>
The "b" prefix states what the encoding is: it is a raw byte string whose bytes are assumed to correspond to their ASCII counterparts.
Except people don't really want to write and learn those languages?