Martin v. Löwis wrote:
Define correctly. Python, in ucs2 mode, will allow to address individual
surrogate codes, e.g. in indexing. So you get
u\U00012345[0]
When Python encodes characters internally in UCS-2, I would expect
u\U00012345 to produce a UnicodeError(character can not be encoded
I suggest using a variation on the consumer interface, as described by
Fredrik Lundh at http://effbot.org/zone/consumer.htm :
.next() -- stays .next()
.__next__(arg) -- becomes .feed(arg)
.__exit__(StopIteration, ...) -- becomes .close()
.__exit__(..,..,..) -- becomes .feed(exc_info=(..,..,..))
Martin v. Löwis wrote:
Shane Hathaway wrote:
I agree that UCS4 is needed. There is a balancing act here; UTF-16 is
widely used and takes less space, while UCS4 is easier to treat as an
array of characters. Maybe we can have both: unicode objects start with
an internal representation in
Shane Hathaway wrote:
Py_UNICODE would always be 32 bits wide.
This would break PythonWin, which relies on Py_UNICODE being
the same as WCHAR_T. PythonWin is not broken, it just hasn't
been ported to UCS-4, yet (and porting this is difficult and
will cause a performance loss).
Regards,
Martin
Shane Hathaway wrote:
Martin v. Löwis wrote:
Shane Hathaway wrote:
I agree that UCS4 is needed. There is a balancing act here; UTF-16 is
widely used and takes less space, while UCS4 is easier to treat as an
array of characters. Maybe we can have both: unicode objects start with
an internal
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Hmm, looking at the configure.in script, it seems you're right.
I wonder why this weird dependency on TCL was added.
If Python is configured for UCS-2, and Tcl for UCS-4, then
Tkinter would not work out of the box. Hence the weird dependency.
I
On May 7, 2005, at 9:29 AM, Martin v. Löwis wrote:
Nicholas Bastin wrote:
--enable-unicode=ucs2
be replaced with:
--enable-unicode=utf16
and the docs be updated to reflect more accurately the variance of the
internal storage type.
-1. This breaks existing documentation and usage, and
Nick Coghlan wrote:
[...]
The whole PEP draft can be found here:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
[...]
Used as follows::
for del auto_retry(3, IOError):
f = urllib.urlopen(http://python.org/;)
print f.read()
I don't know.
Nicholas Bastin wrote:
On May 7, 2005, at 9:29 AM, Martin v. Löwis wrote:
With --enable-unicode=ucs2, Python's Py_UNICODE does *not* start
supporting the full Unicode ccs the same way it supports UCS-2.
Individual surrogate values remain accessible, and supporting
non-BMP characters is left to
On May 7, 2005, at 5:09 PM, M.-A. Lemburg wrote:
However, I don't understand all the excitement
about Py_UNICODE: if you don't like the way this Python
typedef works, you are free to interface to Python using
any of the supported encodings using PyUnicode_Encode()
and PyUnicode_Decode().
Nicholas Bastin wrote:
On May 7, 2005, at 5:09 PM, M.-A. Lemburg wrote:
However, I don't understand all the excitement
about Py_UNICODE: if you don't like the way this Python
typedef works, you are free to interface to Python using
any of the supported encodings using PyUnicode_Encode()
and
Josiah Carlson wrote:
You should know why that can't work. If I pass a list, is a list an
iterator? No, but it should neither be created nor destroyed before or
after.
The discussion has been had in regards to why re-using 'for' is a
non-starter; re-read the 200+ messages in the
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
You should know why that can't work. If I pass a list, is a list an
iterator? No, but it should neither be created nor destroyed before or
after.
The discussion has been had in regards to why re-using 'for' is a
On Sun, 08 May 2005 14:16:40 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
Ron Adam wrote:
I agree, re-using or extending 'for' doesn't seem like a good idea to me.
I agree that re-using a straight 'for' loop is out, due to performance and
compatibility issues with applying finalisation semantics
14 matches
Mail list logo
