Re: [Python-Dev] List insert at index that is well out of range - behaves like append
On Mon, Sep 15, 2014 at 6:18 AM, Harish Tech wrote: > I had a list > > a = [1, 2, 3] > > when I did > > a.insert(100, 100) > > [1, 2, 3, 100] > > as list was originally of size 4 and I was trying to insert value at index > 100 , it behaved like append instead of throwing any errors as I was trying > to insert in an index that did not even existed . > > > Should it not throw > > > IndexError: list assignment index out of range > > > exception as it throws when I attempt doing > > > a[100] = 100 > > Question : 1. Any idea Why has it been designed to silently handle this > instead of informing the user with an exception ? > > > Personal Opinion : Lets see how other dynamic languages behave in such a > situation : Ruby : > > > > a = [1, 2] > > > a[100] = 100 > > > a > > => [1, 2, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, 100] > > The way ruby handles this is pretty clear and sounds meaningful (and this is > how I expected to behave and it behaved as per my expectation) at least to > me . So what I felt was either it should throw exception or do the way ruby > handles it . > > > Is ruby way of handling not the obvious way ? > > I even raised it in stackoverflow > http://stackoverflow.com/questions/25840177/list-insert-at-index-that-is-well-out-of-range-behaves-like-append > > and got some responses . Hello Harish, The appropriate place to ask questions like this is python-list [1], or perhaps Stack Overflow. If you meant to suggest changing the behavior of Python in such cases, you should first discuss this on python-list, and then post a clearly written suggestion to python-ideas [2]. This list, python-dev, is used for discussing the development *of* the Python language. See the "Python Mailing Lists" page [3] for more information. Regards, - Tal Einat ..[1]: http://mail.python.org/mailman/listinfo/python-list ..[2]: http://mail.python.org/mailman/listinfo/python-ideas ..[3]: https://www.python.org/community/lists/ ___ 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
Re: [Python-Dev] List insert at index that is well out of range - behaves like append
Hi , Sorry for that mistake . Now I have posted it in python-list mailing list . Thanks for your guidance. Harish On Mon, Sep 15, 2014 at 5:01 PM, Tal Einat wrote: > On Mon, Sep 15, 2014 at 6:18 AM, Harish Tech > wrote: > > I had a list > > > > a = [1, 2, 3] > > > > when I did > > > > a.insert(100, 100) > > > > [1, 2, 3, 100] > > > > as list was originally of size 4 and I was trying to insert value at > index > > 100 , it behaved like append instead of throwing any errors as I was > trying > > to insert in an index that did not even existed . > > > > > > Should it not throw > > > > > > IndexError: list assignment index out of range > > > > > > exception as it throws when I attempt doing > > > > > > a[100] = 100 > > > > Question : 1. Any idea Why has it been designed to silently handle this > > instead of informing the user with an exception ? > > > > > > Personal Opinion : Lets see how other dynamic languages behave in such a > > situation : Ruby : > > > > > > > a = [1, 2] > > > > > a[100] = 100 > > > > > a > > > > => [1, 2, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, > > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, > > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, > > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, > > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, > > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, > > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, 100] > > > > The way ruby handles this is pretty clear and sounds meaningful (and > this is > > how I expected to behave and it behaved as per my expectation) at least > to > > me . So what I felt was either it should throw exception or do the way > ruby > > handles it . > > > > > > Is ruby way of handling not the obvious way ? > > > > I even raised it in stackoverflow > > > http://stackoverflow.com/questions/25840177/list-insert-at-index-that-is-well-out-of-range-behaves-like-append > > > > and got some responses . > > Hello Harish, > > The appropriate place to ask questions like this is python-list [1], > or perhaps Stack Overflow. > > If you meant to suggest changing the behavior of Python in such cases, > you should first discuss this on python-list, and then post a clearly > written suggestion to python-ideas [2]. > > This list, python-dev, is used for discussing the development *of* the > Python language. > > See the "Python Mailing Lists" page [3] for more information. > > Regards, > - Tal Einat > > ..[1]: http://mail.python.org/mailman/listinfo/python-list > ..[2]: http://mail.python.org/mailman/listinfo/python-ideas > ..[3]: https://www.python.org/community/lists/ > ___ 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
Re: [Python-Dev] namedtuples bug between 3.3.2 and 3.4.1
FWIW I cannot reproduce the bug with Anaconda's Python 3.4.1 (from a
miniconda install):
$ python
Python 3.4.1 |Continuum Analytics, Inc.| (default, Sep 2 2014, 14:00:37)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import namedtuple; vars(namedtuple("T", "a b")(1, 2))
OrderedDict([('a', 1), ('b', 2)])
Antony
2014-09-14 9:27 GMT-07:00 Antoine Pitrou :
> On Mon, 15 Sep 2014 02:13:53 +1000
> Chris Angelico wrote:
> > On Sun, Sep 14, 2014 at 8:13 PM, Brynjar Smári Bjarnason
> > wrote:
> > > I am using Python 3.4.1 installed with Anaconda. I tried the following
> > > (expecting an OrderedDict as result):
> > >
> > from collections import namedtuple
> > NT = namedtuple("NT",["a","b"])
> > nt = NT(1,2)
> > print(vars(nt))
> > > {}
> > >
> > > so the result is an empty dict. In Python 3.3.2 (downgraded in the
> > > same Anaconda environment) results in:
> > >
> > print(vars(nt))
> > > OrderedDict([('a', 1), ('b', 2)])
> >
> > For what it's worth, I can't reproduce the issue on trunk CPython
> > (built from default branch on Aug 21, so it's a little old now), nor
> > on 3.4.1 as currently shipping with Debian Jessie, nor with 3.4.0 on
> > Windows. So this may be an Anaconda issue. Do you know if it's meant
> > to be a patched install of Python?
>
> There may be a couple distutils-specific patches, but that's all.
> Anaconda issues should be reported at
> https://github.com/ContinuumIO/anaconda-issues/issues/
>
> Regards
>
> Antoine.
>
>
> ___
> 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/antony.lee%40berkeley.edu
>
___
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
Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog
On Sat Sep 13 00:16:30 CEST 2014, Jeff Allen wrote: > 1. Java does not really have a Unicode type, therefore not one that > validates. It has a String type that is a sequence of UTF-16 code units. > There are some String methods and Character methods that deal with code > points represented as int. I can put any 16-bit values I like in a String. Including lone surrogates, and invalid characters in general? > 2. With proper accounting for indices, and as long as surrogates appear > in pairs, I believe operations like find or endswith give correct > answers about the unicode, when applied to the UTF-16. This is an > attractive implementation option, and mostly what we do. So use it. The fact that you're having to smuggle bytes already guarantees that your data is either invalid or misinterpreted, and bug-free isn't possible. In terms of best-effort, it is reasonable to treat the smuggled bytes as representing a character outside of your unicode repertoire -- so it won't ever match entirely valid strings, except perhaps via a wildcard. And it should still work for .endswith(). > 3. I'm fixing some bugs where we get it wrong beyond the BMP, and the > fix involves banning lone surrogates (completely). At present you can't > type them in literals but you can sneak them in from Java. So how will you ban them, and what will you do when some java class sends you an invalid sequence anyhow? That is exactly the use case for these smuggled bytes... If you distinguish between a fully constructed PyString and a code-unit-sequence-that-could-be-made-into-a-PyString-later, then you could always have your constructor return an InvalidPyString subclass on the rare occasions when one is needed. If you want to avoid invalid surrogates even then, just use the replacement character and keep a separate list of "original characters that got replaced in this string" -- a hassle, but no worse than tracking indices for surrogates. > 4. I think (with Antoine) if Jython supported PEP-383 byte smuggling, it > would have to do it the same way as CPython, as it is visible. It's not > impossible (I think), but is messy. Some are strongly against. If you allow direct write access to the underlying charsequence (as CPython does to C extensions), then you can't really ban invalid sequences. If callers have to go through an API -- even something as minimal as getBytes or getChars -- then you can use whatever internal representation you prefer. Hopefully, the vast majority of strings won't actually have smuggled bytes. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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
Re: [Python-Dev] List insert at index that is well out of range - behaves like append
On 15/09/14 12:31, Tal Einat wrote: On Mon, Sep 15, 2014 at 6:18 AM, Harish Tech wrote: I had a list a = [1, 2, 3] when I did a.insert(100, 100) [1, 2, 3, 100] as list was originally of size 4 and I was trying to insert value at index 100 , it behaved like append instead of throwing any errors as I was trying to insert in an index that did not even existed . Should it not throw IndexError: list assignment index out of range exception as it throws when I attempt doing a[100] = 100 Question : 1. Any idea Why has it been designed to silently handle this instead of informing the user with an exception ? Personal Opinion : Lets see how other dynamic languages behave in such a situation : Ruby : > a = [1, 2] > a[100] = 100 > a => [1, 2, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, 100] The way ruby handles this is pretty clear and sounds meaningful (and this is how I expected to behave and it behaved as per my expectation) at least to me . So what I felt was either it should throw exception or do the way ruby handles it . Is ruby way of handling not the obvious way ? I even raised it in stackoverflow http://stackoverflow.com/questions/25840177/list-insert-at-index-that-is-well-out-of-range-behaves-like-append and got some responses . Hello Harish, The appropriate place to ask questions like this is python-list [1], or perhaps Stack Overflow. I think this is an OK forum for this question. If someone isn't sure if something is a bug or not, then why not ask here before reporting it on the bug tracker? This does seem strange behaviour, and the documentation for list.insert gives no clue as to why this behaviour was chosen. Cheers, Mark. ___ 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
Re: [Python-Dev] List insert at index that is well out of range - behaves like append
On 15/09/2014 23:29, Mark Shannon wrote: On 15/09/14 12:31, Tal Einat wrote: On Mon, Sep 15, 2014 at 6:18 AM, Harish Tech wrote: I had a list a = [1, 2, 3] when I did a.insert(100, 100) [1, 2, 3, 100] as list was originally of size 4 and I was trying to insert value at index 100 , it behaved like append instead of throwing any errors as I was trying to insert in an index that did not even existed . Should it not throw IndexError: list assignment index out of range exception as it throws when I attempt doing a[100] = 100 Question : 1. Any idea Why has it been designed to silently handle this instead of informing the user with an exception ? Personal Opinion : Lets see how other dynamic languages behave in such a situation : Ruby : > a = [1, 2] > a[100] = 100 > a => [1, 2, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, 100] The way ruby handles this is pretty clear and sounds meaningful (and this is how I expected to behave and it behaved as per my expectation) at least to me . So what I felt was either it should throw exception or do the way ruby handles it . Is ruby way of handling not the obvious way ? I even raised it in stackoverflow http://stackoverflow.com/questions/25840177/list-insert-at-index-that-is-well-out-of-range-behaves-like-append and got some responses . Hello Harish, The appropriate place to ask questions like this is python-list [1], or perhaps Stack Overflow. I think this is an OK forum for this question. If someone isn't sure if something is a bug or not, then why not ask here before reporting it on the bug tracker? This does seem strange behaviour, and the documentation for list.insert gives no clue as to why this behaviour was chosen. Cheers, Mark. I assume it's based on the concepts of slicing. From the docs "s.insert(i, x) - inserts x into s at the index given by i (same as s[i:i] = [x])". Although shouldn't that read s[i:i+1] = [x] ? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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
Re: [Python-Dev] List insert at index that is well out of range - behaves like append
On Mon, 15 Sep 2014 23:46:03 +0100 Mark Lawrence wrote: > > I assume it's based on the concepts of slicing. From the docs > "s.insert(i, x) - inserts x into s at the index given by i (same as > s[i:i] = [x])". Although shouldn't that read s[i:i+1] = [x] ? No, the latter would replace the contents at index i, while the former inserts it (formally, it replaces the 0-length slice with a 1-length slice). Regards Antoine. ___ 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
Re: [Python-Dev] List insert at index that is well out of range - behaves like append
On 09/15/2014 03:46 PM, Mark Lawrence wrote: On 15/09/2014 23:29, Mark Shannon wrote: I think this is an OK forum for this question. It isn't. ;) If someone isn't sure if something is a bug or not, then why not ask here before reporting it on the bug tracker? The first stop should still be the main Python list, or Python Dev would be inundated with questions about why this or that doesn't work the same way as . If the responses from Python list indicate that it is (or probably is) a bug, then possibly a post here to verify -- but a bug-tracker entry at that point is quite reasonable. This does seem strange behaviour, and the documentation for list.insert gives no clue as to why this behaviour was chosen. I assume it's based on the concepts of slicing. From the docs "s.insert(i, x) - inserts x into s at the index given by i (same as s[i:i] = [x])". Although shouldn't that read s[i:i+1] = [x] ? No. If it was `s[i:i+1]` then the ith element would be replaced by the inserted object. -- ~Ethan~ ___ 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
Re: [Python-Dev] List insert at index that is well out of range - behaves like append
This functionality has existed since the earliest days of Python, and even if we all agreed it was wrong we couldn't change it -- it would just break too much existing code. I can't quite remember why I did it that way but it was definitely a conscious choice; probably some symmetry or edge case. (Note that it works this way at the other end too -- a.insert(-100, x) will insert x at the beginning of a, if a has fewer than 100 elements.) On Mon, Sep 15, 2014 at 3:29 PM, Mark Shannon wrote: > > > On 15/09/14 12:31, Tal Einat wrote: > >> On Mon, Sep 15, 2014 at 6:18 AM, Harish Tech >> wrote: >> >>> I had a list >>> >>> a = [1, 2, 3] >>> >>> when I did >>> >>> a.insert(100, 100) >>> >>> [1, 2, 3, 100] >>> >>> as list was originally of size 4 and I was trying to insert value at >>> index >>> 100 , it behaved like append instead of throwing any errors as I was >>> trying >>> to insert in an index that did not even existed . >>> >>> >>> Should it not throw >>> >>> >>> IndexError: list assignment index out of range >>> >>> >>> exception as it throws when I attempt doing >>> >>> >>> a[100] = 100 >>> >>> Question : 1. Any idea Why has it been designed to silently handle this >>> instead of informing the user with an exception ? >>> >>> >>> Personal Opinion : Lets see how other dynamic languages behave in such a >>> situation : Ruby : >>> >>> >>> > a = [1, 2] >>> >>> > a[100] = 100 >>> >>> > a >>> >>> => [1, 2, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, >>> nil, >>> nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, >>> nil, >>> nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, >>> nil, >>> nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, >>> nil, >>> nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, >>> nil, >>> nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, >>> nil, >>> nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, 100] >>> >>> The way ruby handles this is pretty clear and sounds meaningful (and >>> this is >>> how I expected to behave and it behaved as per my expectation) at least >>> to >>> me . So what I felt was either it should throw exception or do the way >>> ruby >>> handles it . >>> >>> >>> Is ruby way of handling not the obvious way ? >>> >>> I even raised it in stackoverflow >>> http://stackoverflow.com/questions/25840177/list- >>> insert-at-index-that-is-well-out-of-range-behaves-like-append >>> >>> and got some responses . >>> >> >> Hello Harish, >> >> The appropriate place to ask questions like this is python-list [1], >> or perhaps Stack Overflow. >> > > I think this is an OK forum for this question. > If someone isn't sure if something is a bug or not, then why not ask here > before reporting it on the bug tracker? > > This does seem strange behaviour, and the documentation for list.insert > gives no clue as to why this behaviour was chosen. > > Cheers, > Mark. > > ___ > 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/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] List insert at index that is well out of range - behaves like append
On Mon, Sep 15, 2014 at 3:46 PM, Mark Lawrence wrote: > > I assume it's based on the concepts of slicing. From the docs > "s.insert(i, x) - inserts x into s at the index given by i (same as s[i:i] > = [x])". Ah, right. It matches thigs like s[100:] which is the empty string if s is shorter than 100. > Although shouldn't that read s[i:i+1] = [x] ? > Should've stopped while you were ahead. :-) 'Nuff said. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog
Jim J. Jewett writes: > In terms of best-effort, it is reasonable to treat the smuggled bytes > as representing a character outside of your unicode repertoire I have to disagree. If you ever end up passing them to something that validates or tries to reencode them without surrogateescape, BOOM! These things are the text equivalent of IEEE NaNs. If all you know (as in the stdlib) is that you have "generic text", the only fairly safe things to do with them are (1) delete them, (2) substitute an appropriate replacement character for them, (3) pass the text containing them verbatim to other code, and (4) reencode them using the same codec they were read with. > -- so it won't ever match entirely valid strings, except perhaps > via a wildcard. And it should still work for .endswith( invalid characters>). Incorrect, I'm pretty sure, unless you know that both texts containing were read with the same codec. Eg, consider two filenames encoded in ISO Cyrillic and ISO Hebrew, read with (encoding='ascii', errors='surrogateescape'). Apps that know the semantics of the text may DWIM/DTRT if they want to, but FWIW-IMHO-YMMV-and-any-other-4-letter-caveat-acronyms-that- may-apply Python and the stdlib shouldn't try to guess. Guessing may be unavoidable, of course. ___ 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
Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog
On Tue, Sep 16, 2014 at 1:34 PM, Stephen J. Turnbull wrote: > Jim J. Jewett writes: > > > In terms of best-effort, it is reasonable to treat the smuggled bytes > > as representing a character outside of your unicode repertoire > > I have to disagree. If you ever end up passing them to something that > validates or tries to reencode them without surrogateescape, BOOM! > These things are the text equivalent of IEEE NaNs. If all you know > (as in the stdlib) is that you have "generic text", the only fairly > safe things to do with them are (1) delete them, (2) substitute an > appropriate replacement character for them, (3) pass the text > containing them verbatim to other code, and (4) reencode them using > the same codec they were read with. Don't forget, these are *errors*. These are bytes that cannot be correctly decoded. That's not something that has any meaning whatsoever in text; so by definition, the only things you can do are the four you list there (as long as "codec" means both the choice of encoding and the use of the surrogateescape flag). It's like dealing with control characters when you need to print something visually, except that they have an official solution [1] and surrogateescape is unofficial. They're not real text, so you have to deal with them somehow. The bytes might each represent one character. Several of them together might represent a single character. Or maybe they don't mean anything at all, and they're just part of a chunked data format... like I was finding in the .cwk files that I was reading this weekend (it's mostly MacRoman encoding, but the text is divided into chunks separated by \0\0 and two more bytes - turns out the bytes are chunk lengths, so they don't mean any sort of characters at all). You can't know. ChrisA [1] http://www.unicode.org/charts/PDF/U2400.pdf ___ 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
