Comment on PEP 263 - Defining Python Source Code Encodings

[Stephen J. Turnbull]

>>>>> "Martin" == Martin v Loewis <martin at v.loewis.de> writes:

    Martin> What data type would you use to represent the BOM if not
    Martin> the byte string type?

Who said anything about not representing it?  But that should be up to
something higher level than an internal cast.

    >> They're purely for interapplication communication (as you point
    >> out elsewhere, Python surely knows implicitly whether it's BE
    >> or LE).

    Martin> Sure, but Python should allow to implement such
    Martin> interapplication communication, so application programmers
    Martin> need a way to emit them.

What's wrong with `f.write("codecs.BOM")'?

    Martin> "Batteries included" means that common cases of
    Martin> interapplication communication ought to be supported by
    Martin> the library.

Well, the current implementation (2.1.3, anyway) cannot be considered
"support", as it handles appends incorrectly.  See my other post or
bug #555360.  And I still don't see Python internal string conversion
as _interapplication_ communication.

    Martin> That's fine; most people seem to agree that the signatures
    Martin> are not very Unixish. I disagree

It's not the people; it's sh(1), cat(1), cp(1), and all the str*(3)
functions.  But that's up to you, of course.


Footnotes: 
[1]  I'm trying to do something about that, but at the moment that's
the way I am.  Not quite potty-trained by c.l.py standards.  :-(

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py