On Thu, 03 Nov 2011 22:47:00 +0100
"Martin v. Löwis" wrote:
> >> On the one hand, these indices are used in formatting error messages such
> >> as
> >> "codec can't encode character \u%04x in position %d", suggesting they
> >> are regular
> >> indices into the string (counting code points).
>
Your approach (doing the right thing for both Python and C, new API to
avoid the C performance problem) sounds good to me.
--
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)
On Nov 4, 2011 7:58 AM, Martin v. Löwis wrote:
> > I started such hack for the UTF-8 codec... I
On 11/3/2011 5:43 PM, "Martin v. Löwis" wrote:
I had the impression that we were abolishing the wide versus narrow
build difference and that this issue would disappear. I must have missed
something.
Most certainly. The Py_UNICODE type continues to exist for backwards
compatibility. It is now
> I started such hack for the UTF-8 codec... It is really tricky, we should not
> do that!
With the proper encapsulation, it's not that tricky. I have written
functions PyUnicode_IndexToWCharIndex and PyUnicode_WCharIndexToIndex,
and PyUnicodeEncodeError_GetStart and friends would use that functi
>> On the one hand, these indices are used in formatting error messages such as
>> "codec can't encode character \u%04x in position %d", suggesting they
>> are regular
>> indices into the string (counting code points).
>>
>> On the other hand, they are used by error handlers to lookup the charact
Am 03.11.2011 22:19, schrieb Terry Reedy:
> On 11/3/2011 3:16 PM, Victor Stinner wrote:
>> Le jeudi 3 novembre 2011 18:14:42, mar...@v.loewis.de a écrit :
>>> There is a backwards compatibility issue with PEP 393 and Unicode
>>> exceptions: the start and end indices: are they Py_UNICODE indices, or
On 11/3/2011 3:16 PM, Victor Stinner wrote:
Le jeudi 3 novembre 2011 18:14:42, mar...@v.loewis.de a écrit :
There is a backwards compatibility issue with PEP 393 and Unicode
exceptions: the start and end indices: are they Py_UNICODE indices, or
code point indices?
I had the impression that we
On Thu, Nov 3, 2011 at 12:29 PM, Antoine Pitrou wrote:
> On Thu, 03 Nov 2011 18:14:42 +0100
> mar...@v.loewis.de wrote:
>> There is a backwards compatibility issue with PEP 393 and Unicode exceptions:
>> the start and end indices: are they Py_UNICODE indices, or code point
>> indices?
>>
>> On th
You're right; among my many tests I think I muddled the situation with
a stray CFLAGS variable in my environment. Apologies for the
misinformation. The current MacPorts portfile does not add -fwrapv.
Adding -fwrapv to OPT in the Makefile solves the problem. I confirmed
by manually building the v2.7
On Thu, 03 Nov 2011 18:14:42 +0100
mar...@v.loewis.de wrote:
> There is a backwards compatibility issue with PEP 393 and Unicode exceptions:
> the start and end indices: are they Py_UNICODE indices, or code point indices?
>
> On the one hand, these indices are used in formatting error messages suc
Brian Curtin, 03.11.2011 15:59:
On Sat, Oct 22, 2011 at 14:30, Andrea Crotti wrote:
On 10/21/2011 10:08 PM, Antoine Pitrou wrote:
Hello,
There are currently a bunch of various buildbot failures on all 3
branches. I would remind committers to regularly take a look at the
buildbots, so that the
Le jeudi 3 novembre 2011 18:14:42, mar...@v.loewis.de a écrit :
> There is a backwards compatibility issue with PEP 393 and Unicode
> exceptions: the start and end indices: are they Py_UNICODE indices, or
> code point indices?
Oh oh. That's exactly why I didn't want to start to work on this issue.
Derek Shockey wrote:
> I believe you're right. The 2.7.2 MacPorts portfile definitely passes
> the -fwrapv flag to clang, but the bad behavior still occurs with
> exponents.
Really? Even without the fix for issue12973 the -fwrapv flag
should be sufficient, as reported in issue13061 and Issue11149
I believe you're right. The 2.7.2 MacPorts portfile definitely passes
the -fwrapv flag to clang, but the bad behavior still occurs with
exponents. I verified the current head of the 2.7 branch does not have
this problem when built with clang, so I'm assuming that issue12973
resolved this with a pat
There is a backwards compatibility issue with PEP 393 and Unicode exceptions:
the start and end indices: are they Py_UNICODE indices, or code point indices?
On the one hand, these indices are used in formatting error messages such as
"codec can't encode character \u%04x in position %d", suggestin
Hi Derek,
> I tried in the 2.7.1 and 2.6.7 installations included in OS X 10.7,
> and also a 2.7.2+ (not sure what the + is)
The + means that’s it’s 2.7.2 + some commits, in other words the
in-development version that will become 2.7.3. This bit of info seems
to be missing from the doc.
Regards
On Sat, Oct 22, 2011 at 14:30, Andrea Crotti wrote:
> On 10/21/2011 10:08 PM, Antoine Pitrou wrote:
>>
>> Hello,
>>
>> There are currently a bunch of various buildbot failures on all 3
>> branches. I would remind committers to regularly take a look at the
>> buildbots, so that these failures get s
For what its worth
On 11/1/2011 11:43 AM, Paul Moore wrote:
On 1 November 2011 16:40, Paul Moore wrote:
On 1 November 2011 16:29, Paul Moore wrote:
On 31 October 2011 20:10, Carl Meyer wrote:
For Windows, can you point me at the nt scripts? If they aren't too
complex, I'd be willing to por
Le Mercredi 2 Novembre 2011 19:32:38 Derek Shockey a écrit :
> I just found an unexpected behavior and I'm wondering if it is a bug.
> In my 2.7.2 interpreter on OS X, built and installed via MacPorts, it
> appears that integers are not correctly overflowing into longs and
> instead are yielding bi
On Wed, 2 Nov 2011 19:41:30 -0700
Guido van Rossum wrote:
> Apparently Macports is still using a buggy compiler.
If I understand things correctly, this is technically not a buggy
compiler but Python making optimistic assumptions about the C standard.
(from issue11149: "clang (as with gcc 4.x) ass
20 matches
Mail list logo
