Re: [Python-Dev] Before 2.5 - More signed integer overflows
On 9/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz schrieb:
> > I also tested the fix (see patch below) for the abs() issue and it
> > seemed to work for 4.1.1 on 64-bit. I'll apply the patch to head and
> > 2.5 and a test after 2.5 is out.
>
> Please also add it to 2.4.
Yes
>
> > Index: Objects/intobject.c
> > ===
> > --- Objects/intobject.c (revision 51886)
> > +++ Objects/intobject.c (working copy)
> > @@ -763,7 +763,7 @@
> >register long a, x;
> >a = v->ob_ival;
> >x = -a;
> > - if (a < 0 && x < 0) {
> > + if (a < 0 && (unsigned long)x == 0-(unsigned long)x) {
>
> Hmm. Shouldn't this drop 'x' and use 'a' instead? If a is
> -sys.maxint-1, -a is already undefined.
Yes, probably. I didn't review carefully.
> P.S. As for finding these problems, I would have hoped that
> -ftrapv could help - unfortunately, gcc breaks with this
> option (consumes incredible amounts of memory).
I'm getting a crash when running test_builtin and test_calendar (at
least) with gcc 4.1.1 on amd64. It's happening in pymalloc, though I
don't know what the cause is. I thought I tested with gcc 4.1 before,
but probably would have been in debug mode.
n
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 22020)]
PyObject_Malloc (nbytes=40) at obmalloc.c:746
746 if ((pool->freeblock = *(block **)bp) != NULL) {
(gdb) p bp
$1 = (block *) 0x2a9558d41800
(gdb) l
741 * Pick up the head block of its free list.
742 */
743 ++pool->ref.count;
744 bp = pool->freeblock;
745 assert(bp != NULL);
746 if ((pool->freeblock = *(block **)bp) != NULL) {
747 UNLOCK();
748 return (void *)bp;
749 }
750 /*
(gdb) p *pool
$2 = {ref = {_padding = 0x1a , count = 26},
freeblock = 0x2a9558d41800 ,
nextpool = 0x2a95eac000, prevpool = 0x620210, arenaindex = 0, szidx = 4,
nextoffset = 4088, maxnextoffset = 4056}
(gdb) p size
$3 = 4
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Before 2.5 - More signed integer overflows
Neal Norwitz schrieb:
> I also tested the fix (see patch below) for the abs() issue and it
> seemed to work for 4.1.1 on 64-bit. I'll apply the patch to head and
> 2.5 and a test after 2.5 is out.
Please also add it to 2.4.
> Index: Objects/intobject.c
> ===
> --- Objects/intobject.c (revision 51886)
> +++ Objects/intobject.c (working copy)
> @@ -763,7 +763,7 @@
>register long a, x;
>a = v->ob_ival;
>x = -a;
> - if (a < 0 && x < 0) {
> + if (a < 0 && (unsigned long)x == 0-(unsigned long)x) {
Hmm. Shouldn't this drop 'x' and use 'a' instead? If a is
-sys.maxint-1, -a is already undefined.
Regards,
Martin
P.S. As for finding these problems, I would have hoped that
-ftrapv could help - unfortunately, gcc breaks with this
option (consumes incredible amounts of memory).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Before 2.5 - More signed integer overflows
I also tested the fix (see patch below) for the abs() issue and it
seemed to work for 4.1.1 on 64-bit. I'll apply the patch to head and
2.5 and a test after 2.5 is out.
I have no idea how to search for these problems. I know that xrange
can't display -sys.maxint-1 properly, but I think it works properly.
n
--
Index: Objects/intobject.c
===
--- Objects/intobject.c (revision 51886)
+++ Objects/intobject.c (working copy)
@@ -763,7 +763,7 @@
register long a, x;
a = v->ob_ival;
x = -a;
- if (a < 0 && x < 0) {
+ if (a < 0 && (unsigned long)x == 0-(unsigned long)x) {
PyObject *o = PyLong_FromLong(a);
if (o != NULL) {
PyObject *result = PyNumber_Negative(o);
On 9/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > BTW, did anyone try compiling Python with -fwrapv on a box where it
> > matters? I doubt that Python's speed is affected one way or the
> > other, and if adding wrapv makes the problems go away, that would be
> > an easy last-second workaround for all possible such problems (which
> > of course could get fixed "for real" for 2.5.1, provided someone cares
> > enough to dig into it).
>
> It's not so easy to add this option: configure needs to be taught to
> check whether the option is supported first; to test it, you ideally
> need an installation where it is supported, and one where it isn't.
>
> I've added a note to README indicating that GCC 4.2 shouldn't be
> used to compile Python. I don't consider this a terrible limitation,
> especially since GCC 4.2 isn't released, yet.
>
> OTOH, I get the same problem that Armin gets (abs(-sys.maxint-1)
> is negative) also on a 32-bit system, with Debian's gcc 4.1.2
> (which also isn't released, yet), so it appears that the problem
> is already with gcc 4.1.
>
> On my system, adding -fwrapv indeed solves the problem
> (tested for abs()). So I added this to the README also.
>
> Regards,
> Martin
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Before 2.5 - More signed integer overflows
> BTW, did anyone try compiling Python with -fwrapv on a box where it > matters? I doubt that Python's speed is affected one way or the > other, and if adding wrapv makes the problems go away, that would be > an easy last-second workaround for all possible such problems (which > of course could get fixed "for real" for 2.5.1, provided someone cares > enough to dig into it). It's not so easy to add this option: configure needs to be taught to check whether the option is supported first; to test it, you ideally need an installation where it is supported, and one where it isn't. I've added a note to README indicating that GCC 4.2 shouldn't be used to compile Python. I don't consider this a terrible limitation, especially since GCC 4.2 isn't released, yet. OTOH, I get the same problem that Armin gets (abs(-sys.maxint-1) is negative) also on a 32-bit system, with Debian's gcc 4.1.2 (which also isn't released, yet), so it appears that the problem is already with gcc 4.1. On my system, adding -fwrapv indeed solves the problem (tested for abs()). So I added this to the README also. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Before 2.5 - More signed integer overflows
[Armin Rigo] >> There are more cases of signed integer overflows in the CPython source >> code base... >> >> That's on a 64-bits machine: >> >> [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2 >> abs(-sys.maxint-1) == -sys.maxint-1 >< >> Humpf! Looks like one person or two need to do a quick last-minute >> review of all places trying to deal with -sys.maxint-1, and replace them >> all with the "official" fix from Tim [SF 1545668]. [Anthony Baxter] > Ick. We're now less than 24 hours from the scheduled release date for 2.5 > final. There seems to be a couple of approaches here: > > 1. Someone (it won't be me, I'm flat out with work and paperwriting today) >reviews the code and fixes it > 2. We leave it for a 2.5.1. I'm expecting (based on the number of bugs found >and fixed during the release cycle) that we'll probably need a 2.5.1 in > about >3 months. > 3. We delay the release until it's fixed. > > I'm strongly leaning towards (2) at this point. (1) would probably require > another release candidate, while (3) would result in another release > candidate and massive amount of sobbing from a lot of people (including me). I ignored this since I don't have a box where problems are visible (& nobody responded to my request to check my last flying-blind "fix" on a box where it mattered). Given that these are weird, unlikely-in-real-life endcase bugs specific to a single compiler, #2 is the natural choice. BTW, did anyone try compiling Python with -fwrapv on a box where it matters? I doubt that Python's speed is affected one way or the other, and if adding wrapv makes the problems go away, that would be an easy last-second workaround for all possible such problems (which of course could get fixed "for real" for 2.5.1, provided someone cares enough to dig into it). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BRANCH FREEZE/IMMINENT RELEASE: Python 2.5 (final). 2006-09-19, 00:00UTC
Ok, time to bring down the hammer. The release25-maint branch is absolutely frozen to everyone but the release team from 00:00UTC, Tuesday 19th September. That's just under 20 hours from now. This is for Python 2.5 FINAL, so anyone who breaks this release will make me very, very sad. Based on the last few releases, I'd expect the release process to take around 18 hours (timezones are a swine). Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Before 2.5 - More signed integer overflows
On Saturday 16 September 2006 21:11, Armin Rigo wrote: > Hi all, > > There are more cases of signed integer overflows in the CPython source > code base... > > That's on a 64-bits machine: > > [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2 > abs(-sys.maxint-1) == -sys.maxint-1 > Humpf! Looks like one person or two need to do a quick last-minute > review of all places trying to deal with -sys.maxint-1, and replace them > all with the "official" fix from Tim [SF 1545668]. Ick. We're now less than 24 hours from the scheduled release date for 2.5 final. There seems to be a couple of approaches here: 1. Someone (it won't be me, I'm flat out with work and paperwriting today) reviews the code and fixes it 2. We leave it for a 2.5.1. I'm expecting (based on the number of bugs found and fixed during the release cycle) that we'll probably need a 2.5.1 in about 3 months. 3. We delay the release until it's fixed. I'm strongly leaning towards (2) at this point. (1) would probably require another release candidate, while (3) would result in another release candidate and massive amount of sobbing from a lot of people (including me). -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
Ronald Oussoren schrieb: > BTW. several sites on the interweb claim that x86-64 runs faster than > plain x86 due to a larger register set. All my machines are 32-bit so I > can't check if this is relevant for Python (let alone Python on OSX). That is plausible. OTOH, the AMD64 binaries will often require twice as much main memory, as all pointers double their size, and the Python implementation (or most OO languages, for that matter) is full of pointers. So it will be more efficient only until it starts swapping. (there is also a negative effect of larger pointers on the processor cache; the impact of this effect is hard to estimate). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
Jack Jansen schrieb: > Just wondering: is it a good idea in the first place to create a > universal 32/64 bit Python on MacOSX? I wonder about the same thing. > For extension modules it's different, though: there it would be nice > to be able to have a single module that could load into any Python > (32/64 bit, Intel/PPC) on any applicable MacOSX version. That seems to suggest that the standard distribution should indeed provide a four-times fat binary, at least for libpython: AFAIU, to build extension modules that way, all target architectures must be supported in all necessary libraries on the build machine (somebody will surely correct me if that's wrong). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
On Sep 17, 2006, at 9:37 PM, Jack Howarth wrote: Martin, I believe if you use the Xcode project management the Universal binary creation is automated. Currently they support the i386/ppc binaries but once Leopard comes out you will see i386/x86_64/ppc/ppc64 binaries for shared libraries. That's not really relevant for python, python is build using makefiles not using a Xcode project (and I'd like to keep it that way). BTW. Xcode 2.4 can already build 4-way universal binaries, Tiger supports 64-bit unix programs. On my system file /usr/lib/ libSystem.B.dylib (the unix/C library) says: $ file /usr/lib/libSystem.B.dylib /usr/lib/libSystem.B.dylib: Mach-O universal binary with 3 architectures /usr/lib/libSystem.B.dylib (for architecture ppc64):Mach-O 64-bit dynamically linked shared library ppc64 /usr/lib/libSystem.B.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/lib/libSystem.B.dylib (for architecture ppc): Mach-O dynamically linked shared library ppc On the new Mac Pro's and probably the Core2 based iMac's as well libSystem also contains a x86-64 version. Ronald Jack smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
On Sep 17, 2006, at 9:29 PM, Jack Jansen wrote: Just wondering: is it a good idea in the first place to create a universal 32/64 bit Python on MacOSX? On MacOS you don't pay a penalty or anything for running in 32-bit mode on any current hardware, so the choice of whether to use 32 or 64 bits really depends on the application. A single Python interpreter that can run in both 32 and 64 bit mode would possibly make this more difficult rather than easier. I think I'd prefer a situation where we have python32 and python64 (with both being ppc/ intel fat) and python being a symlink to either, at the end-users' discretion. For extension modules it's different, though: there it would be nice to be able to have a single module that could load into any Python (32/64 bit, Intel/PPC) on any applicable MacOSX version. A 4-way universal python framework could be useful, but I agree that the python executable shouldn't be 64-bit. I'm not too happy about a symlink that selects which version you get to use, wouldn't 'python' (32-bit) and 'python-64' (64-bit) be just as good. That way the user doesn't have to set up anything and it helps to reinforce the message that 64-bit isn't necessarily better than 32-bit. Having a 4-way universal framework would IMO be preferable over two seperate python installs, that would just increase the confusion. There are too many python distributions for the mac anyway. A major stumbling-block for a 4-way universal installation is the availability of binary packages for (popular) 3th party packages, this is not really relevant for python-dev but I'd prefer not having 64-bit support in the default installer over a 64-bit capable installation where it is very hard to get popular packages to work. BTW. several sites on the interweb claim that x86-64 runs faster than plain x86 due to a larger register set. All my machines are 32-bit so I can't check if this is relevant for Python (let alone Python on OSX). Ronald -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
Martin, I believe if you use the Xcode project management the Universal binary creation is automated. Currently they support the i386/ppc binaries but once Leopard comes out you will see i386/x86_64/ppc/ppc64 binaries for shared libraries. Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
Just wondering: is it a good idea in the first place to create a universal 32/64 bit Python on MacOSX? On MacOS you don't pay a penalty or anything for running in 32-bit mode on any current hardware, so the choice of whether to use 32 or 64 bits really depends on the application. A single Python interpreter that can run in both 32 and 64 bit mode would possibly make this more difficult rather than easier. I think I'd prefer a situation where we have python32 and python64 (with both being ppc/ intel fat) and python being a symlink to either, at the end-users' discretion. For extension modules it's different, though: there it would be nice to be able to have a single module that could load into any Python (32/64 bit, Intel/PPC) on any applicable MacOSX version. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
On Sep 17, 2006, at 8:56 PM, Martin v. Löwis wrote:
One of the announced features of osx 10.5 is 64-bit support
throughout
the system and I definitely want to see if we can get 4-way universal
support on such systems. As I don't have a system that is capable of
running 64-bit code I'm not going to worry too much about this right
now :-)
Isn't this a size issue, also? There might be very few users of a
64-bit
binary (fewer even on PPC64 than on AMD64).
On Tiger it's primairily a useability issue: 64-bit binaries can't
use most of the system API's because only the unix API (libSystem) is
64-bit at the moment.
The size of the python installer would grow significantly for a 4-way
universal distribution, it would be almost twice as large as the
current distribution ("almost" because only binaries would grow in
site, python source files and data files wouldn't grow in size).
In addition: how does the system chose whether to create a 32-bit
or a 64-bit process if the python binary is fat?
It should take the best fit, on 32-bit processors it picks the 32-bit
version and on 64-bit processors it picks the 64-bit one. This
probably means that we'll have to ship multiple versions of the
python executable, otherwise Tiger (10.4) users would end up with an
interpreter that cannot use OSX-specific API's.
Ronald
smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
Ronald Oussoren schrieb: > The sizes of basic types are the same on PPC32 and x86 which helps a > lot. Ah, right. This was the missing piece of the puzzle. The byteorder is different, but we can use GCC feature checks > there. The relevant bit of pyconfig.h.in: > > #ifdef __BIG_ENDIAN__ > #define WORDS_BIGENDIAN 1 > #else > #ifndef __LITTLE_ENDIAN__ > #undef WORDS_BIGENDIAN > #endif > #endif Yes, I remember this change very well. > One of the announced features of osx 10.5 is 64-bit support throughout > the system and I definitely want to see if we can get 4-way universal > support on such systems. As I don't have a system that is capable of > running 64-bit code I'm not going to worry too much about this right > now :-) Isn't this a size issue, also? There might be very few users of a 64-bit binary (fewer even on PPC64 than on AMD64). In addition: how does the system chose whether to create a 32-bit or a 64-bit process if the python binary is fat? Regards, Martin P.S.: for distutils, I think adding special cases would retrieving pyconfig.h items would be necessary. In addition, I think Python should expose some of these in the image, e.g. as sys.platform_config.SIZEOF_INT. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
On Sep 17, 2006, at 8:35 PM, Martin v. Löwis wrote: Josiah Carlson schrieb: "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Out of curiosity: how do the current universal binaries deal with this issue? If I remember correctly, usually you do two completely independant compile runs (optionally on the same machine with different configure or macro definitions, then use a packager provided by Apple to merge the results for each binary/so to be distributed. Each additional platform would just be a new compile run. It's true that the compiler is invoked twice, however, I very much doubt that configure is run twice. Doing so would cause the Makefile being regenerated, and the build starting from scratch. It would find the object files from the previous run, and either all overwrite them, or leave them in place. The gcc driver on OSX allows to invoke cc1/as two times, and then combines the resulting object files into a single one (not sure whether or not by invoking lipo). IIRC the gcc driver calls lipo when multiple -arch flags are present in the command line. This is very convenient, especially when combined with distutils. Universal builds of Python will automaticly build universal extensions as well, without major patches to distutils. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
On 9/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Josiah Carlson schrieb: > > "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >> Out of curiosity: how do the current universal binaries deal with this > >> issue? > > > > If I remember correctly, usually you do two completely independant > > compile runs (optionally on the same machine with different configure or > > macro definitions, then use a packager provided by Apple to merge the > > results for each binary/so to be distributed. Each additional platform > > would just be a new compile run. Sometimes this is done, but usually people just use CC="cc -arch i386 -arch ppc". Most of the time that Just Works, unless the source depends on autoconf gunk for endianness related issues. > It's true that the compiler is invoked twice, however, I very much doubt > that configure is run twice. Doing so would cause the Makefile being > regenerated, and the build starting from scratch. It would find the > object files from the previous run, and either all overwrite them, or > leave them in place. > > The gcc driver on OSX allows to invoke cc1/as two times, and then > combines the resulting object files into a single one (not sure whether > or not by invoking lipo). > That's exactly what it does. The gcc frontend ensures that cc1/as is invoked exactly as many times as there are -arch flags, and the result is lipo'ed together. This also means that you get to see a copy of all warnings and errors for each -arch flag. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
On Sep 17, 2006, at 8:03 PM, Josiah Carlson wrote: "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Out of curiosity: how do the current universal binaries deal with this issue? If I remember correctly, usually you do two completely independant compile runs (optionally on the same machine with different configure or macro definitions, then use a packager provided by Apple to merge the results for each binary/so to be distributed. Each additional platform would just be a new compile run. That's the hard way to do things, if you don't mind to spent some time checking the code you try to compile you can usually tweak header files and use '-arch ppc -arch i386' to build a universal binary in one go. This is a lot more convenient when building universal binaries and is what's used to build Python as a universal binary. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New relative import issue
I've been playing with the new features and there's one thing about the new relative import that I find a little strange and I'm not sure this was intended... When you do a from . import xxx, it will always fail if you're in a top-level module, and when executing any module, the directory of the module will automatically go into the pythonpath, thus making all the relative imports in that structure fail. E.g.: /foo/bar/imp1.py <-- has a "from . import imp2" /foo/bar/imp2.py if I now put a test-case (or any other module I'd like as the main module) at: /foo/bar/mytest.py if it imports imp1, it will always fail. The solutions I see would be: - only use the pythonpath actually defined by the user (and don't put the current directory in the pythonpath) - make relative imports work even if they reach some directory in the pythonpath (making it work as an absolute import that would only search the current directory structure) Or is this actually a bug? (I'm with python 2.5 rc2) I took another look at http://docs.python.org/dev/whatsnew/pep-328.html and the example shows: pkg/ pkg/__init__.py pkg/main.py pkg/string.py with the main.py doing a "from . import string", which is what I was trying to accomplish... Cheers, Fabio ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
Josiah Carlson schrieb: > "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Out of curiosity: how do the current universal binaries deal with this >> issue? > > If I remember correctly, usually you do two completely independant > compile runs (optionally on the same machine with different configure or > macro definitions, then use a packager provided by Apple to merge the > results for each binary/so to be distributed. Each additional platform > would just be a new compile run. It's true that the compiler is invoked twice, however, I very much doubt that configure is run twice. Doing so would cause the Makefile being regenerated, and the build starting from scratch. It would find the object files from the previous run, and either all overwrite them, or leave them in place. The gcc driver on OSX allows to invoke cc1/as two times, and then combines the resulting object files into a single one (not sure whether or not by invoking lipo). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
On Sep 17, 2006, at 6:53 PM, Martin v. Löwis wrote: Ronald Oussoren schrieb: One problem is that python's configure script detects the sizes of various types and those values will be different on 32-bit and 64-bit flavours. FWIW, the PC build "solves" this problem by providing a hand-crafted pyconfig.h file, instead of using an autoconf-generated one. That could work for OSX as well, although it is tedious to keep the hand-crafted file up-to-date. For the PC, this isn't really a problem, since Windows doesn't suddenly grow new features, at least not those that configure checks for. So forking pyconfig.h once and then customizing it for universal binaries might work. Another approach would be to override architecture-specific defines. For example, a block #ifdef __APPLE__ #include "pyosx.h" #endif Thats what I had started on before Bob came up with the endianness check that is in pyconfig.h.in at the moment. I'd to do this instead of manually maintaining a fork of pyconfig.h, my guess it is a lot less likely that pyconfig.h will grow new size related macros than new feature related ones. One possible issue here is that distutils has an API for fetching definitions from pyconfig.h, code that uses this to detect architecture features could cause problems. could be added to the end of pyconfig.h, and then pyosx.h would have #undef SIZEOF_LONG #if defined(__i386__) || defined(__ppc__) #define SIZEOF_LONG 4 #elif defined(__amd64__) || defined(__ppc64__) #define SIZEOF_LONG 8 #else #error unsupported architecture #endif Out of curiosity: how do the current universal binaries deal with this issue? The sizes of basic types are the same on PPC32 and x86 which helps a lot. The byteorder is different, but we can use GCC feature checks there. The relevant bit of pyconfig.h.in: #ifdef __BIG_ENDIAN__ #define WORDS_BIGENDIAN 1 #else #ifndef __LITTLE_ENDIAN__ #undef WORDS_BIGENDIAN #endif #endif Users of pyconfig.h will see the correct definition of WORDS_BIGENDIAN regardless of the architecture that was used to create the file. One of the announced features of osx 10.5 is 64-bit support throughout the system and I definitely want to see if we can get 4- way universal support on such systems. As I don't have a system that is capable of running 64-bit code I'm not going to worry too much about this right now :-) Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Out of curiosity: how do the current universal binaries deal with this > issue? If I remember correctly, usually you do two completely independant compile runs (optionally on the same machine with different configure or macro definitions, then use a packager provided by Apple to merge the results for each binary/so to be distributed. Each additional platform would just be a new compile run. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
Ronald Oussoren schrieb: > One problem is that python's configure script detects the sizes of > various types and those values will be different on 32-bit and 64-bit > flavours. FWIW, the PC build "solves" this problem by providing a hand-crafted pyconfig.h file, instead of using an autoconf-generated one. That could work for OSX as well, although it is tedious to keep the hand-crafted file up-to-date. For the PC, this isn't really a problem, since Windows doesn't suddenly grow new features, at least not those that configure checks for. So forking pyconfig.h once and then customizing it for universal binaries might work. Another approach would be to override architecture-specific defines. For example, a block #ifdef __APPLE__ #include "pyosx.h" #endif could be added to the end of pyconfig.h, and then pyosx.h would have #undef SIZEOF_LONG #if defined(__i386__) || defined(__ppc__) #define SIZEOF_LONG 4 #elif defined(__amd64__) || defined(__ppc64__) #define SIZEOF_LONG 8 #else #error unsupported architecture #endif Out of curiosity: how do the current universal binaries deal with this issue? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python, lipo and the future?
On Sep 17, 2006, at 2:51 PM, Jack Howarth wrote: I am curious if there are any plans to support the functionality provided by lipo on MacOS X to create a python release that could operate at either 32-bit or 64-bit on Darwin ppc and Darwin intel? We already support universal binaries for PPC and x86, adding PPC64 and x86-64 to the mix should be relatively straigthforward, but it isn't a complete no-brainer. One problem is that python's configure script detects the sizes of various types and those values will be different on 32-bit and 64-bit flavours. Another problem is that Tiger's 64-bit support is pretty limited, basically just the Unix APIs, which means you cannot have a 4-way universal python interpreter without upsetting anyone with a 64- bit machine :-). My understanding was that the linux developers are very interested in lipo as well as an approach to avoid the difficulty of maintaining separate lib directories for 32 and 64-bit libraries. Thanks in advance for any insights on this issue. OSX uses the MachO binary format which natively supports fat binaries, I don't know if ELF (the linux binary format) support fat binaries. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python, lipo and the future?
I am curious if there are any plans to support the functionality provided by lipo on MacOS X to create a python release that could operate at either 32-bit or 64-bit on Darwin ppc and Darwin intel? My understanding was that the linux developers are very interested in lipo as well as an approach to avoid the difficulty of maintaining separate lib directories for 32 and 64-bit libraries. Thanks in advance for any insights on this issue. Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IronPython and AST branch
Brett Cannon wrote: > As for making the AST branch itself more of a standard, I have talked to > Jeremy Hylton about that and he didn't like the idea, at least for now. > The reasons for keeping it as "experimental" in terms of exposure at the > Python level is that we do not want to lock ourselves down to some AST > spec that we end up changing in the future. It's the same reasoning > behind not officially documenting the marshal format; we want the > flexibility. > > How best to resolve all of this, I don't know. I completely understand > not wanting to lock ourselves down to an AST too soon. Might need to > wait a little while after the AST has been out in the wild to see what > the user response is and then make a decision. One of the biggest issues I have with the current AST is that I don't believe it really gets the "slice" and "extended slice" terminology correct (it uses 'extended slice' to refer to multi-dimensional indexing, but the normal meaning of that phrase is to refer to the use of a step argument for a slice [1]) Cheers, Nick. [1] http://www.python.org/doc/2.3.5/whatsnew/section-slices.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
Fabio Zadrozny wrote: > On 9/16/06, Lawrence Oluyede <[EMAIL PROTECTED]> wrote: >>> I think that this change should be presented at >>> http://docs.python.org/dev/whatsnew/whatsnew25.html >> It's already listed there: >> http://docs.python.org/dev/whatsnew/other-lang.html >> > > Thanks... also, I don't know if the empty yield statement is mentioned > too (I couldn't find it either). It's part of the PEP 342 changes. However, I don't believe AMK mentioned that part explicitly in the What's New. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Grammar change in classdef
Talin wrote: > Nick Coghlan wrote: >> As for the reason: it makes it possible to use the same style for classes >> without bases as is used for functions without arguments. Prior to this >> change, there was a sharp break in the class syntax, such that if you got >> rid >> of the last base class you had to get rid of the parentheses as well. > > Is the result a new-style or classic-style class? It would be nice if > using the empty parens forced a new-style class... This was considered & rejected by Guido as too subtle a distinction. So you still need to set __metaclass__=type (or inherit from such a class) to get a new-style class. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
