I think I've found a small flaw in the implementation
of binary operator methods for new-style Python classes.
If the left and right operands are of the same class,
and the class implements a right operand method but
not a left operand method, the right operand method
is not called. Instead, two at
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 Manheime
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 Manheimer
Moshe Zadka
Raymond Hettinger
_
> "MvL" == "Martin v. Löwis" <[EMAIL PROTECTED]> writes:
MvL> This would also support your usecase, and in a better way.
MvL> The Unicode assertion that UTF-16 is BE by default is void
MvL> these days - there is *always* a higher layer protocol, and
MvL> it more often than not
Martin v. Löwis wrote:
> 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 wh
Walter Dörwald sagte:
> Nicholas Bastin sagte:
>
> It should be feasible to implement your own codec for that
> based on Lib/encodings/utf_16.py. Simply replace the line
> in StreamReader.decode():
> raise UnicodeError,"UTF-16 stream does not start with BOM"
> with:
> self.decode = codecs.utf_
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
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
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
garba
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 b
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.
>>
>>
>
[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 y
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 .write
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 r
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 ThreadsInit
I recently redid how the readline module handled threads around
callbacks into Python (the previous code was insane).
This resulted in the following bug report:
http://www.python.org/sf/1176893
Which is correctly assigned to me as it's clearly a result of my
recent checkin. However, I think
Nicholas Bastin wrote:
>
> On Apr 5, 2005, at 6:19 AM, M.-A. Lemburg wrote:
>
>> Note that the UTF-16 codec is strict w/r to the presence
>> of the BOM mark: you get a UnicodeError if a stream does
>> not start with a BOM mark. For the UTF-8-SIG codec, this
>> should probably be relaxed to not re
On Sunday 03 April 2005 16:48, Martin v. Löwis wrote:
> If this kind of functionality would fall on immediate rejection for
> some reason, even writing the PEP might be pointless.
Note that even if something is rejected, the PEP itself is useful - it
collects knowledge in a format that's far more
18 matches
Mail list logo
