Zooko O'Whielacronx wrote:
> I'm sorry, I should have mentioned that I did read those archives
> before I posted my letter. That discussion was all about whether UCS2
> or UCS4 is better. I consider that question to be mostly irrelevant
> to this issue, which is about compatibility for people who
Pascal Chambon wrote:
Daniel Stutzbach a écrit :
On Sun, Sep 20, 2009 at 4:48 AM, Pascal Chambon
mailto:chambon.pas...@gmail.com>> wrote:
*RawIOBase*.readinto(b: bytes) -> int
"bytes" are immutable. The signature is:
*RawIOBase*.readinto(b: bytearray) -> int
Your efforts in working on
Zooko O'Whielacronx wrote:
> On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou wrote:
>>
>> What "binaries" are you talking about?
>
> I mean extension modules with native code, which means .so shared
> library files on unix.
Those will not load unless they are for the right UCS-version of
Python.
Le Sun, 20 Sep 2009 10:33:23 -0600, Zooko O'Whielacronx a écrit :
>
> By the way, I was investigating this, and discovered an issue on the
> Mandriva tracker which suggests that they intend to switch to UCS4 in
> the next release in order to avoid compatibility problems like these.
Trying to use
Le Sun, 20 Sep 2009 10:17:45 -0600, Zooko O'Whielacronx a écrit :
>
>> AFAIK, C extensions should fail loading when they have the wrong UCS2/4
>> setting.
>
> That would be an improvement! Unfortunately we instead get mysterious
> misbehavior of the module, e.g.:
>
> http://bugs.python.org/setu
On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou wrote:
> For information, all Mandriva versions I've used until now have had their
> Python's built with UCS2 (maxunicode == 65535).
By the way, I was investigating this, and discovered an issue on the
Mandriva tracker which suggests that they inten
Daniel Stutzbach a écrit :
On Sun, Sep 20, 2009 at 4:48 AM, Pascal Chambon
mailto:chambon.pas...@gmail.com>> wrote:
*RawIOBase*.readinto(b: bytes) -> int
"bytes" are immutable. The signature is:
*RawIOBase*.readinto(b: bytearray) -> int
Your efforts in working on clarifying these impor
On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou wrote:
>
> What "binaries" are you talking about?
I mean extension modules with native code, which means .so shared
library files on unix.
> AFAIK, C extensions should fail loading when they have the wrong UCS2/4
> setting.
That would be an impro
On Sun, Sep 20, 2009 at 4:48 AM, Pascal Chambon wrote:
> *RawIOBase*.readinto(b: bytes) -> int
>
"bytes" are immutable. The signature is:
*RawIOBase*.readinto(b: bytearray) -> int
Your efforts in working on clarifying these important corner cases is
appreciated. :-)
--
Daniel Stutzbach, Ph.D.
Zooko O'Whielacronx gmail.com> writes:
>
> Users occasionally get binaries built for a
> compatible Linux and Python version but with a different UCS2-vs-UCS4 setting,
> and those users get mysterious memory corruption errors which are hard to
> diagnose.
What "binaries" are you talking about?
A
I'm sorry, I should have mentioned that I did read those archives
before I posted my letter. That discussion was all about whether UCS2
or UCS4 is better. I consider that question to be mostly irrelevant
to this issue, which is about compatibility for people who don't
choose to configure that set
2009/9/20 Zooko O'Whielacronx :
> Dear Pythonistas:
>
> This issue causes serious problems. Users occasionally get binaries built
> for a
> compatible Linux and Python version but with a different UCS2-vs-UCS4 setting,
> and those users get mysterious memory corruption errors which are hard to
>
Dear Pythonistas:
This issue causes serious problems. Users occasionally get binaries built for a
compatible Linux and Python version but with a different UCS2-vs-UCS4 setting,
and those users get mysterious memory corruption errors which are hard to
diagnose. It is possible that these situation
Hello,
> *Truncate and file pointer semantics*
[snip]
The major problem here is that you are changing the current semantics.
I don't think the argument you are making for it is strong enough to
counter-balance the backwards compatibility issue. The situation would be
different if 3.0 hadn't be
Greg Ewing wrote:
Pascal Chambon wrote:
Concerning the naming of truncate(), would it be possible to
deprecate it and alias it to "resize()" ? It's not very gratifying to
have duplicated methods at the beginning of a major release, but I
feel too that "truncate" is a misleading term, that h
Pascal Chambon wrote:
Hello
After weighing up here and that, here is what I have come with. Comments
and issue notifications more than welcome, of course. The exception
thingy is not yet addressed.
Regards,
Pascal
*Truncate and file pointer semantics*
Rationale :
The current implementati
Hello
After weighing up here and that, here is what I have come with. Comments
and issue notifications more than welcome, of course. The exception
thingy is not yet addressed.
Regards,
Pascal
*Truncate and file pointer semantics*
Rationale :
The current implementation of truncate() always
Pascal Chambon wrote:
Concerning the naming of truncate(), would it be possible to deprecate
it and alias it to "resize()" ? It's not very gratifying to have
duplicated methods at the beginning of a major release, but I feel too
that "truncate" is a misleading term, that had better be replac
What we could do with is better platform-independent
ways of distinguishing particular error conditions,
such as file not found, out of space, etc., either
using subclasses of IOError or mapping error codes
to a set of platform-independent ones.
Well, mapping all errors (including C ones and
Well, system compatibility argues strongl in favor of not letting
filepointer > EOF.
However, is that really necessary to move the pointer to EOF in ANY case
? I mean, if I extend the file, or if I reduce it without going lower
than my current filepointer, I really don't expect at all the io sys
20 matches
Mail list logo
