Martin v. Löwis sagte:
> Walter Dörwald wrote:
>> There are situations where the byte stream might be temporarily
>> exhausted, e.g. an XML parser that tries to support the
>> IncrementalParser interface, or when you want to decode
>> encoded data piecewise, because you want to give a progress
>> r
> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
Martin> I can't put these two paragraphs together. If you think
Martin> that explicit is better than implicit, why do you not want
Martin> to make different calls for the first chunk of a stream,
Martin> and the subsequen
Stephen J. Turnbull wrote:
"Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
Martin> I can't put these two paragraphs together. If you think
Martin> that explicit is better than implicit, why do you not want
Martin> to make different calls for the first chunk of a stream,
Marti
Tim Peters <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
>> Asking mostly for curiousity, how hard would it be to have longs store
>> their sign bit somewhere less aggravating?
>
> Depends on where that is.
>
>> It seems to me that the top bit of ob_digit[0] is always 0, for example,
>
> Yes, the
[EMAIL PROTECTED]
> Modified Files:
>mathmodule.c
> Log Message:
> Add a comment explaining the import of longintrepr.h.
>
> Index: mathmodule.c
...
> #include "Python.h"
> -#include "longintrepr.h"
> +#include "longintrepr.h" // just for SHIFT
The intent is fine, but please use a standar
Michael Hudson <[EMAIL PROTECTED]> writes:
> Tim Peters <[EMAIL PROTECTED]> writes:
>
>> [Michael Hudson]
>>> Asking mostly for curiousity, how hard would it be to have longs store
>>> their sign bit somewhere less aggravating?
>>
>> Depends on where that is.
[...]
>> I'd much rather give struct
On Apr 5, 2005 8:46 PM, Brett C. <[EMAIL PROTECTED]> wrote:
> Alex A. Naanou wrote:
> > Here there are two problems, the first is minor, and it is that
> > anything assigned to the __dict__ attribute is checked to be a
> > descendant of the dict class (mixing this in does not seem to work)...
> > a
P.S. (IMHO) the type check here is not that necessary (at least in its
current state), as what we need to assert is not the relation to the
dict class but the support of the mapping protocol
The type-check is basically correct - as you have discovered, type & object use
the PyDict_* API intern
Stephen J. Turnbull wrote:
Because the signature/BOM is not a chunk, it's a header. Handling the
signature/BOM is part of stream initialization, not translation, to my
mind.
I'm sorry, but I'm losing track as to what precisely you are trying to
say. You seem to be using a mental model that is enti
Patch / Bug Summary
___
Patches : 308 open (+11) / 2819 closed ( +7) / 3127 total (+18)
Bugs: 882 open (+11) / 4913 closed (+13) / 5795 total (+24)
RFE : 176 open ( +1) / 151 closed ( +1) / 327 total ( +2)
New / Reopened Patches
__
improveme
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 require the BOM.
I've actually been confused
> "Walter" == Walter Dörwald <[EMAIL PROTECTED]> writes:
Walter> Not really. In every encoding where a sequence of more
Walter> than one byte maps to one Unicode character, you will
Walter> always need some kind of buffering. If we remove the
Walter> handling of initial BOMs fr
12 matches
Mail list logo