Michael Hudson wrote:
Option 1) Call PyEval_ThreadsInitialized() in PyGilState_Release().
Non-invasive, but bleh.
Tim rejected this option back when PyEval_ThreadsInitialized() was added to the
API [1]. Gustavo was having a similar problem with pygtk, and the end result was
to add the
Nick Coghlan [EMAIL PROTECTED] writes:
Michael Hudson wrote:
Option 1) Call PyEval_ThreadsInitialized() in PyGilState_Release().
Non-invasive, but bleh.
Tim rejected this option back when PyEval_ThreadsInitialized() was
added to the API [1].
Well, not really. The patch that was rejected
On Apr 7, 2005, at 5:07 AM, M.-A. Lemburg wrote:
The current implementation of the utf-16 codecs makes for some
irritating gymnastics to write the BOM into the file before reading it
if it contains no BOM, which seems quite like a bug in the codec.
The codec writes a BOM in the first call to
[Michael Hudson]
...
Point the first is that I really think this is a bug in the GilState
APIs: the readline API isn't inherently multi-threaded and so it would
be insane to call PyEval_InitThreads() in initreadline, yet it has to
cope with being called in a multithreaded situation. If you
Nicholas Bastin wrote:
On Apr 7, 2005, at 5:07 AM, M.-A. Lemburg wrote:
The current implementation of the utf-16 codecs makes for some
irritating gymnastics to write the BOM into the file before reading it
if it contains no BOM, which seems quite like a bug in the codec.
The codec
Tim Peters [EMAIL PROTECTED] writes:
[Michael Hudson]
...
Point the first is that I really think this is a bug in the GilState
APIs: the readline API isn't inherently multi-threaded and so it would
be insane to call PyEval_InitThreads() in initreadline, yet it has to
cope with being called
On Apr 7, 2005, at 11:35 AM, M.-A. Lemburg wrote:
Ok, but I don't really follow you here: you are suggesting to
relax the current UTF-16 behavior and to start defaulting to
UTF-16-BE if no BOM is present - that's most likely going to
cause more problems that it seems to solve: namely complete
Nicholas Bastin sagte:
On Apr 7, 2005, at 11:35 AM, M.-A. Lemburg wrote:
[...]
If you do have UTF-16 without a BOM mark it's much better
to let a short function analyze the text by reading for first
few bytes of the file and then make an educated guess based
on the findings. You can then
Nicholas Bastin wrote:
It would be nice if you could optionally specify that the codec would
assume UTF-16BE if no BOM was present, and not raise UnicodeError in
that case, which would preserve the current behaviour as well as allow
users' to ask for behaviour which conforms to the standard.
On Apr 7, 2005, at 07:58, Raymond Hettinger wrote:
Does anyone know what has become of the following developers and
perhaps
have their current email addresses? Are any of these folks still
active
in Python development?
Ben Gertzfield
Charles G Waldman
Eric Price
Finn Bock
Ken
10 matches
Mail list logo
