> Right, that's the danger I was worried about, but the problem is that
 > there's at least *some* minimum level of ASCII compatibility that
 > needs to be assumed in order to define an interpolation format at all
 > (this is the point I originally missed).

Only if you insist that bytes formats be admitted.  But that's an
implementation detail, really.  (I'm not going to push that point,
since it's the obvious way to request a bytes result, and insist on
the various restrictions and semantic differences proposed for bytes
interpolation -- anything else would be silly.)

More seriously, it's irrelevant *post*-interpolation, because by
definition bytes interpolation interpolates bytes, not "ASCII
compatible".  So what you're saying is iterated interpolation is
crazy:

    width1, width2 = compute_column_widths(table_rows)
    fmt = b"%%%ds %%%ds\n" % (width1, width2)
    for row in table_rows:
        print(fmt % row)        # might be useful in debugging ;-)
                                # writing to a file is plausible IMO

Tell me again why we have a '%%' format code? :-)

 > (which must make life interesting if you try to use an ASCII
 > incompatible coding cookie for your source code - I'm actually not
 > sure what the full implications of that *are* for bytes literals in
 > Python 3).

Currently None:

me 15:46$ python3.3 test.py 
  File "test.py", line 2
SyntaxError: bytes can only contain ASCII literal characters.

:-)

 > It's certainly a decision that has its downsides, with the potential
 > impact on users of ASCII incompatible encodings (mostly in Asia)

Which is most of the world at this point.  You ISO-8859-speakers are
gonna wither away! :-)  Nor do I think there's anybody crazy enough to
make a Tiananmen Square-style stand against GB18030.  In 2025 this
could be Python's most sensitive Achilles' heel.<wink/>  Hm.  Maybe I
should put a fractional coefficient on that <wink>.

 > being the main one, but I think the increased convenience in
 > working with ASCII compatible binary protocols and file formats is
 > worth the cost.

But there aren't any ASCII-compatible binary protocols in the sense
that Shift JIS is *not* ASCII compatible.  After interpolation, you
end up with something that's not ASCII compatible.

At the very least, the "iterated interpolation is a bad idea"
misfeature needs to be documented.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to