On Wed, 2 Nov 2011 19:41:30 -0700
Guido van Rossum gu...@python.org 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
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
For what its worth
On 11/1/2011 11:43 AM, Paul Moore wrote:
On 1 November 2011 16:40, Paul Moorep.f.mo...@gmail.com wrote:
On 1 November 2011 16:29, Paul Moorep.f.mo...@gmail.com wrote:
On 31 October 2011 20:10, Carl Meyerc...@oddbird.net wrote:
For Windows, can you point me at the nt
On Sat, Oct 22, 2011 at 14:30, Andrea Crotti andrea.crott...@gmail.com 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
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
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, suggesting
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
Derek Shockey derek.shoc...@gmail.com 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
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.
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
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 such
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
On Thu, Nov 3, 2011 at 12:29 PM, Antoine Pitrou solip...@pitrou.net 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 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
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
code
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 character,
and
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
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
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 mar...@v.loewis.de wrote:
I started such hack for the
On Thu, 03 Nov 2011 22:47:00 +0100
Martin v. Löwis mar...@v.loewis.de 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).
20 matches
Mail list logo
