[ python-Bugs-1385004 ] exec statement link in index broken
Bugs item #1385004, was opened at 2005-12-19 09:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385004&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: exec statement link in index broken Initial Comment: In library reference index: http://www.python.org/doc/2.4.2/lib/genindex.html "exec statement" points to http://www.python.org/doc/2.4.2/lib/bltin-code-objects.html#l2h-265 Which seems wrong. (2.4 docs already had the same). -Harri -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385004&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1385040 ] compiler module does not detect a syntax error
Bugs item #1385040, was opened at 2005-12-19 09:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler module does not detect a syntax error
Initial Comment:
import compiler
compiler.parse("def foo(a=1,b): pass")
Gives:
Module(None, Stmt([Function(None, 'foo', ['a', 'b'],
[Const(1)], 0, None, Stmt([Pass()]))]))
However, the python interpreter itself barks for the
same code:
SyntaxError: non-default argument follows default
argument
-Harri
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1385055 ] execfile anomaly with "from __future__ import division"
Bugs item #1385055, was opened at 2005-12-19 10:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: execfile anomaly with "from __future__ import division"
Initial Comment:
If I have a file init.py with two lines:
from __future__ import division
print 3/4
and I do
[EMAIL PROTECTED] tests]$ python
Python 2.4 (#1, Feb 16 2005, 01:23:25)
[GCC 3.4.3 (Mandrakelinux 10.0 3.4.3-2mdk)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> execfile('init.py')
0.75
>>> 3/4
0
I would have expected the latter to return 0.75 as
well.
Due to this it seems impossible to provide init code
that would initialize the interactive prompt to
future division behaviour.
The same applies to exec statement.
I'm not sure if this is bug, or an unfortunate
feature. The documention is not very clear on this
issue.
-Harri
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1385055 ] execfile anomaly with "from __future__ import division"
Bugs item #1385055, was opened at 2005-12-19 10:15
Message generated for change (Comment added) made by harripasanen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: execfile anomaly with "from __future__ import division"
Initial Comment:
If I have a file init.py with two lines:
from __future__ import division
print 3/4
and I do
[EMAIL PROTECTED] tests]$ python
Python 2.4 (#1, Feb 16 2005, 01:23:25)
[GCC 3.4.3 (Mandrakelinux 10.0 3.4.3-2mdk)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> execfile('init.py')
0.75
>>> 3/4
0
I would have expected the latter to return 0.75 as
well.
Due to this it seems impossible to provide init code
that would initialize the interactive prompt to
future division behaviour.
The same applies to exec statement.
I'm not sure if this is bug, or an unfortunate
feature. The documention is not very clear on this
issue.
-Harri
--
>Comment By: Harri Pasanen (harripasanen)
Date: 2005-12-19 10:42
Message:
Logged In: YES
user_id=77088
Looks like this is a duplicate of
[ 567568 ] future division broken w/ PYTHONSTARTUP
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=567568
As I suspected, it is an unfortunate feature. Tim's
explication provides the missing documentation. And I
assume the exec statement provides its own anonymous
module.
Btw. where is the -Qnew documented? from __future__
division docs should carry a pointer to it.
Here is another thread on the subject in the ipython
mailing list:
http://scipy.net/pipermail/ipython-user/2005-December/001183.html
This can be closed.
-Harri
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1382740 ] len() on class broken
Bugs item #1382740, was opened at 2005-12-16 13:18 Message generated for change (Comment added) made by kquick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Guido van Rossum (gvanrossum) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. -- >Comment By: Kevin Quick (kquick) Date: 2005-12-19 08:25 Message: Logged In: YES user_id=6133 This bug *may* be related to Bug#1066490 -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-16 21:40 Message: Logged In: YES user_id=80475 Guido, this issue arises throughout the language in various guises (for instance, it applies to __neg__ as well as __len__). It comes-up whenever built-in functions or operators bypass attribute lookup in favor of direct slot access. Much of the code in abstract.c is in the form: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) raise TypeError If we cared about this (and I'm not sure we do), the solution is to make the abstract.c functions smarter: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) try: f = gettattr(o, 'somefunc') except AttributeError: raise TypeError else: return f() The advantage of the change is restoring the symmetry between len(o) and o.__len__() where the method definition is available via attribute lookup but not via a slot. The thought is to keep the speedy access as default, but if that fails, then do a normal attribute lookup before barfing back an error message. This is precedent for this solution elsewhere in the codebase (though I don't remember where at the moment). OTOH, I'm not sure we care. pervades the code in abstract.c which is in the form: def PyObject_Size -- Comment By: Kevin Quick (kquick) Date: 2005-12-16 15:52 Message: Logged In: YES user_id=6133 That would indeed solve '4', but has a non-orthogonality of attribute propagation that I don't understand and which seems inconsistent. In my original: '1' demonstrates that __len__ is indeed in the dictionary for the class. '2' shows the expected attribute propagation effects: if at attribute is not found in the instance dictionary, the class dictionary is checked. '3' shows that len is implemented (generally) by looking for a __len__ method on the object in question. '4' confuses me, because it means that '3' isn't quite correct... With your metaclass solution (using "__metaclass__ = meta" :) it does indeed make '4' work, and '1', but '2' and '3' now do not work, showing that instance-->class propagation does not follow instance-->class-->metaclass. Or something ... Approaching this a different way: My understanding of @classmethod (or perhaps more properly @staticmethod) is that it allows "constant" methods that are independent of the particular object instance. So if I had: class C: @staticmethod def f(): return 1 then both C.f() and C().f() are valid and return 1. Why the len() translation to __len__ works *differently* is strange. I'm still defining a method, just one that I want Python to use for any len(A) or len(A()) refs, translating those to A.__len__() or A().__len__() and using those just as for C and f, respectively. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 14:43 Message: Logged In: YES user_id=1188172 You want to use a metaclass: class meta(type): def __len__(cls): return 12 class B: __metaclass__ = B print len(B) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c
Bugs item #970334, was opened at 2004-06-10 12:46 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff -- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:42 Message: Logged In: YES user_id=6606 I'm seeing this exact problem compiling Python 2.4.2 on Solaris 10. I've got the following gcc-related packages installed: SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49 SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49 SUNWgccruntime - runtime libraries (also?), 11.10.0,REV=2005.01.08.05.16 $ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL' /usr/include/iso/math_c99.h:#undef HUGE_VAL /usr/include/iso/math_c99.h:#define HUGE_VAL __builtin_huge_val A quick look around didn't tell me what __builtin_huge_val is defined to. printf()'ing HUGE_VAL from a test.c proggie shows the following: e=0.00e+00, f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.00 -- Comment By: Michael Hudson (mwh) Date: 2004-08-23 11:00 Message: Logged In: YES user_id=6656 Closing as threatened. -- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) -- Comment By: Tim Peters (tim_one) Date: 2004-06-10 15:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c
Bugs item #970334, was opened at 2004-06-10 12:46 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff -- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:52 Message: Logged In: YES user_id=6606 Oops, forgot an arg -- HUGE_VAL is defined as the following on Solaris 10: e=Inf f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.00 -- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:42 Message: Logged In: YES user_id=6606 I'm seeing this exact problem compiling Python 2.4.2 on Solaris 10. I've got the following gcc-related packages installed: SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49 SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49 SUNWgccruntime - runtime libraries (also?), 11.10.0,REV=2005.01.08.05.16 $ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL' /usr/include/iso/math_c99.h:#undef HUGE_VAL /usr/include/iso/math_c99.h:#define HUGE_VAL __builtin_huge_val A quick look around didn't tell me what __builtin_huge_val is defined to. printf()'ing HUGE_VAL from a test.c proggie shows the following: e=0.00e+00, f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.00 -- Comment By: Michael Hudson (mwh) Date: 2004-08-23 11:00 Message: Logged In: YES user_id=6656 Closing as threatened. -- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) -- Comment By: Tim Peters (tim_one) Date: 2004-06-10 15:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c
Bugs item #970334, was opened at 2004-06-10 12:46
Message generated for change (Comment added) made by dlr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
Status: Closed
Resolution: None
Priority: 5
Submitted By: JD Bronson (lonebandit)
Assigned to: Michael Hudson (mwh)
Summary: 2.3.4 fails build on solaris 10 - complexobject.c
Initial Comment:
this has been an ongoing issue:
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/classobject.o Objects/classobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/cobject.o Objects/cobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:469: error: invalid operands to
binary ==
Objects/complexobject.c:469: error: wrong type
argument to unary minus
Objects/complexobject.c:469: error: invalid operands to
binary ==
Objects/complexobject.c:469: error: wrong type
argument to unary minus
make: *** [Objects/complexobject.o] Error 1
..It fails at that point with no workaround.
Jeff
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 20:52
Message:
Logged In: YES
user_id=6606
As noted by some other people on the web, defining
Py_HUGE_VAL to some other value (e.g. math.h's HUGE, which
is defined as MAXFLOAT on Solaris), a successful compile can
be achieved. If I explicitly #define Py_HUGE_VAL to
__builtin_huge_val, I get the same compilation error as
reported by this bug. Removing optimization flags does not
help. The HUGE_VAL provided by Solaris 10 doesn't seem to
be a workable value for pyport.h's macro.
My little test proggie was missing yet more args, so I'm
posting both the source and output this time.
--- snip ---
#include
int main(char **argv)
{
#ifdef SOLARIS
printf("SOLARIS=%e\n", SOLARIS);
#endif
printf("MAXFLOAT: e=%e, f=%f\n", MAXFLOAT, MAXFLOAT);
printf("HUGE: e=%e, f=%f\n", HUGE, HUGE);
printf("HUGE_VAL: e=%e, f=%f\n", HUGE_VAL, HUGE_VAL);
}
--- snip ---
Output:
MAXFLOAT: e=3.402823e+38,
f=340282346638528859811704183484516925440.00
HUGE: e=3.402823e+38,
f=340282346638528859811704183484516925440.00
HUGE_VAL: e=Inf, f=Inf
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 19:52
Message:
Logged In: YES
user_id=6606
Oops, forgot an arg -- HUGE_VAL is defined as the following
on Solaris 10:
e=Inf
f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.00
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 19:42
Message:
Logged In: YES
user_id=6606
I'm seeing this exact problem compiling Python 2.4.2 on
Solaris 10. I've got the following gcc-related packages
installed:
SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49
SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49
SUNWgccruntime - runtime libraries (also?),
11.10.0,REV=2005.01.08.05.16
$ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL'
/usr/include/iso/math_c99.h:#undef HUGE_VAL
/usr/include/iso/math_c99.h:#define HUGE_VAL
__builtin_huge_val
A quick look around didn't tell me what __builtin_huge_val
is defined to. printf()'ing HUGE_VAL from a test.c proggie
shows the following:
e=0.00e+00,
f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.00
--
Comment By: Michael Hudson (mwh)
Date: 2004-08-23 11:00
Message:
Logged In: YES
user_id=6656
Closing as threatened.
--
Comment By: Michael Hudson (mwh)
Date: 2004-08-07 21:43
Message:
Logged In: YES
user_id=6656
Given that this has sat here for two months without
activity, I propose closing it in another fortnight.
Assigning to me on the off-chance this makes me more likely
to remember :-)
---
[ python-Bugs-837046 ] pyport.h redeclares gethostname() if SOLARIS is defined
Bugs item #837046, was opened at 2003-11-06 08:09 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Bostock (jbostock) Assigned to: Nobody/Anonymous (nobody) Summary: pyport.h redeclares gethostname() if SOLARIS is defined Initial Comment: The file pyport.h contains the lines: #ifdef SOLARIS /* Unchecked */ extern int gethostname(char *, int); #endif However, Solaris already defines gethostname() in /usr/include/unistd.h [I only have access to Solaris 2.6 and 2.8 so I can't vouch for other versions]. This in iteself is not a problem. However, under Python2.3, pyconfig.h defines _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED which cause (indirectly) the following prototype to be selected from unitstd.h: extern int gethostname(char *, size_t); Since size_t is an unsigned char, a compiler error message is generated (both by the native compiler and gcc) saying that the function has been redefined. This means that no python program can be compiled if SOLARIS is #defined. I imagine that the above code from pyport.h is only applicable to an earlier version of Solaris than 2.6, and so should either be removed or qualified somehow. -- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 21:19 Message: Logged In: YES user_id=6606 I can verify this issue on Solaris 10 (SunOS 5.10). Not only does this code seem unnecessary, but there is no configury nor make magic which _can_ ever set the SOLARIS preprocessor define. If I run 'make' as follows, I can trigger a hard compilation error: [Python-2.4.2]$ make CFLAGS='$(BASECFLAGS) $(OPT) -DSOLARIS=true' ... In file included from ./Include/Python.h:55, from Objects/complexobject.c:8: ./Include/pyport.h:382: error: conflicting types for 'gethostname' /usr/include/unistd.h:319: error: previous declaration of 'gethostname' was here./Include/pyport.h:382: error: conflicting types for 'gethostname' /usr/include/unistd.h:319: error: previous declaration of 'gethostname' was here*** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I recommend removing this snippet from pyport.h: --- Include/pyport.h(revision 41772) +++ Include/pyport.h(working copy) @@ -372,11 +372,6 @@ in platform-specific #ifdefs. **/ -#ifdef SOLARIS -/* Unchecked */ -extern int gethostname(char *, int); -#endif - #ifdef __BEOS__ /* Unchecked */ /* It's in the libs, but not the headers... - [cjh] */ -- Comment By: James Bostock (jbostock) Date: 2003-11-26 18:43 Message: Logged In: YES user_id=902503 "Since size_t is an unsigned char" should read "Since size_t is an unsigned int". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837046&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL)
Bugs item #1276509, was opened at 2005-08-30 10:48 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: csmuc (chrschaffer) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL) Initial Comment: Hi all, my efforts building Python 2.4.1 on Solaris 10(x386) failed. The error mesage reads: (...)Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I found bug 970334 dealing with that topic, but I didn't find a solution provided. I tried with various compilers and libraries, e.g. /opt/sfw/bin/gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. /usr/local/bin/gcc --version gcc (GCC) 3.3.2 The same result with any of them. I didn't get the solution provided in http://mail.python.org/pipermail/python-list/2005-August/293795.html to work for me, unfortunately. I'd be glad, if you could have a look into this issue. Thanks in advance, Chris -- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 22:01 Message: Logged In: YES user_id=6606 This is a duplicate of issue #970334, which I just submitted a patch to python-dev for. -- Comment By: csmuc (chrschaffer) Date: 2005-09-28 06:54 Message: Logged In: YES user_id=1337267 Hi all, I found a newsgroup posting which adviced to change a line in Include/pyport.h http://mail.python.org/pipermail/patches/2005-February/016881.html ---8<- The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define Py_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h --->8- I did as adviced and the compile worked. I am not sure, if this is a valid solution, but at least it´s a workaround. Thanks to Reinhold Birkenfeld for your hint! Regards, Chris -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 07:03 Message: Logged In: YES user_id=1188172 Looks like HUGE_VAL is defined in a curious way on your platform. Can you find out what header defines HUGE_VAL and to what it expands? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c
Bugs item #970334, was opened at 2004-06-10 12:46
Message generated for change (Comment added) made by dlr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
Status: Closed
Resolution: None
Priority: 5
Submitted By: JD Bronson (lonebandit)
Assigned to: Michael Hudson (mwh)
Summary: 2.3.4 fails build on solaris 10 - complexobject.c
Initial Comment:
this has been an ongoing issue:
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/classobject.o Objects/classobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/cobject.o Objects/cobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:469: error: invalid operands to
binary ==
Objects/complexobject.c:469: error: wrong type
argument to unary minus
Objects/complexobject.c:469: error: invalid operands to
binary ==
Objects/complexobject.c:469: error: wrong type
argument to unary minus
make: *** [Objects/complexobject.o] Error 1
..It fails at that point with no workaround.
Jeff
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 22:02
Message:
Logged In: YES
user_id=6606
Issue #1276509 is a duplicate of this issue. I've just
submitted a patch to the python-dev list for this problem,
which I'll attach below (and expect Tracker to mangle):
Index: configure.in
===
--- configure.in(revision 41772)
+++ configure.in(working copy)
@@ -215,6 +215,17 @@
fi
+# See the #define for Py_HUGE_VAL in pyport.h.
+case $ac_sys_system/$ac_sys_release in
+ SunOS/5.10)
+# Solaris 10's /usr/include/iso/math_c99.h defines
HUGE_VAL as
+# __builtin_huge_val, which causes problems when
defining Py_HUGE_VAL.
+AC_DEFINE(Py_HUGE_VAL, HUGE,
+ Define to a positive double which represents
infinity)
+;;
+esac
+
+
#
# SGI compilers allow the specification of the both the ABI
and the
# ISA on the command line. Depending on the values of
these switches,
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 20:52
Message:
Logged In: YES
user_id=6606
As noted by some other people on the web, defining
Py_HUGE_VAL to some other value (e.g. math.h's HUGE, which
is defined as MAXFLOAT on Solaris), a successful compile can
be achieved. If I explicitly #define Py_HUGE_VAL to
__builtin_huge_val, I get the same compilation error as
reported by this bug. Removing optimization flags does not
help. The HUGE_VAL provided by Solaris 10 doesn't seem to
be a workable value for pyport.h's macro.
My little test proggie was missing yet more args, so I'm
posting both the source and output this time.
--- snip ---
#include
int main(char **argv)
{
#ifdef SOLARIS
printf("SOLARIS=%e\n", SOLARIS);
#endif
printf("MAXFLOAT: e=%e, f=%f\n", MAXFLOAT, MAXFLOAT);
printf("HUGE: e=%e, f=%f\n", HUGE, HUGE);
printf("HUGE_VAL: e=%e, f=%f\n", HUGE_VAL, HUGE_VAL);
}
--- snip ---
Output:
MAXFLOAT: e=3.402823e+38,
f=340282346638528859811704183484516925440.00
HUGE: e=3.402823e+38,
f=340282346638528859811704183484516925440.00
HUGE_VAL: e=Inf, f=Inf
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 19:52
Message:
Logged In: YES
user_id=6606
Oops, forgot an arg -- HUGE_VAL is defined as the following
on Solaris 10:
e=Inf
f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.00
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 19:42
Message:
Logged In: YES
user_id=6606
I'm seeing this exact problem compiling Python 2.4.2 on
Solaris 10. I've got the following gcc-related packages
installed:
SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49
SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49
SUNWgccruntime - runtime libraries (also?),
11.10.0,REV=2005.01.08.05.16
$ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL'
/usr/include/iso/math_c99.h:#undef HUGE_VAL
/usr/include/iso/math_c99.h:#define HUGE_VAL
__builtin_huge_val
A quick
[ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c
Bugs item #970334, was opened at 2004-06-10 07:46
Message generated for change (Comment added) made by lonebandit
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
Status: Closed
Resolution: None
Priority: 5
Submitted By: JD Bronson (lonebandit)
Assigned to: Michael Hudson (mwh)
Summary: 2.3.4 fails build on solaris 10 - complexobject.c
Initial Comment:
this has been an ongoing issue:
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/classobject.o Objects/classobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/cobject.o Objects/cobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:469: error: invalid operands to
binary ==
Objects/complexobject.c:469: error: wrong type
argument to unary minus
Objects/complexobject.c:469: error: invalid operands to
binary ==
Objects/complexobject.c:469: error: wrong type
argument to unary minus
make: *** [Objects/complexobject.o] Error 1
..It fails at that point with no workaround.
Jeff
--
>Comment By: JD Bronson (lonebandit)
Date: 2005-12-19 16:12
Message:
Logged In: YES
user_id=257991
This is too old to deal with any more. I had forgot I
reported this. Using 2.4.2 under Solaris with Studio 11
builds fine out of the box:
Python 2.4.2 (#1, Dec 12 2005, 19:14:42) [C] on sunos5
-JD
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 16:02
Message:
Logged In: YES
user_id=6606
Issue #1276509 is a duplicate of this issue. I've just
submitted a patch to the python-dev list for this problem,
which I'll attach below (and expect Tracker to mangle):
Index: configure.in
===
--- configure.in(revision 41772)
+++ configure.in(working copy)
@@ -215,6 +215,17 @@
fi
+# See the #define for Py_HUGE_VAL in pyport.h.
+case $ac_sys_system/$ac_sys_release in
+ SunOS/5.10)
+# Solaris 10's /usr/include/iso/math_c99.h defines
HUGE_VAL as
+# __builtin_huge_val, which causes problems when
defining Py_HUGE_VAL.
+AC_DEFINE(Py_HUGE_VAL, HUGE,
+ Define to a positive double which represents
infinity)
+;;
+esac
+
+
#
# SGI compilers allow the specification of the both the ABI
and the
# ISA on the command line. Depending on the values of
these switches,
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 14:52
Message:
Logged In: YES
user_id=6606
As noted by some other people on the web, defining
Py_HUGE_VAL to some other value (e.g. math.h's HUGE, which
is defined as MAXFLOAT on Solaris), a successful compile can
be achieved. If I explicitly #define Py_HUGE_VAL to
__builtin_huge_val, I get the same compilation error as
reported by this bug. Removing optimization flags does not
help. The HUGE_VAL provided by Solaris 10 doesn't seem to
be a workable value for pyport.h's macro.
My little test proggie was missing yet more args, so I'm
posting both the source and output this time.
--- snip ---
#include
int main(char **argv)
{
#ifdef SOLARIS
printf("SOLARIS=%e\n", SOLARIS);
#endif
printf("MAXFLOAT: e=%e, f=%f\n", MAXFLOAT, MAXFLOAT);
printf("HUGE: e=%e, f=%f\n", HUGE, HUGE);
printf("HUGE_VAL: e=%e, f=%f\n", HUGE_VAL, HUGE_VAL);
}
--- snip ---
Output:
MAXFLOAT: e=3.402823e+38,
f=340282346638528859811704183484516925440.00
HUGE: e=3.402823e+38,
f=340282346638528859811704183484516925440.00
HUGE_VAL: e=Inf, f=Inf
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 13:52
Message:
Logged In: YES
user_id=6606
Oops, forgot an arg -- HUGE_VAL is defined as the following
on Solaris 10:
e=Inf
f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.00
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 13:42
Message:
Logged In: YES
user_id=6606
I'm seeing this exact problem compiling Python 2.4.2 on
Solaris 10. I've got the following gcc-related packages
in
[ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c
Bugs item #970334, was opened at 2004-06-10 12:46
Message generated for change (Comment added) made by dlr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
Status: Closed
Resolution: None
Priority: 5
Submitted By: JD Bronson (lonebandit)
Assigned to: Michael Hudson (mwh)
Summary: 2.3.4 fails build on solaris 10 - complexobject.c
Initial Comment:
this has been an ongoing issue:
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/classobject.o Objects/classobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/cobject.o Objects/cobject.c
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -
Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:469: error: invalid operands to
binary ==
Objects/complexobject.c:469: error: wrong type
argument to unary minus
Objects/complexobject.c:469: error: invalid operands to
binary ==
Objects/complexobject.c:469: error: wrong type
argument to unary minus
make: *** [Objects/complexobject.o] Error 1
..It fails at that point with no workaround.
Jeff
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 22:19
Message:
Logged In: YES
user_id=6606
But with Python 2.4.2 and GCC 3.4.2 (a perfectly reasonable
combination), the build does still fail on Solaris 10.
--
Comment By: JD Bronson (lonebandit)
Date: 2005-12-19 22:12
Message:
Logged In: YES
user_id=257991
This is too old to deal with any more. I had forgot I
reported this. Using 2.4.2 under Solaris with Studio 11
builds fine out of the box:
Python 2.4.2 (#1, Dec 12 2005, 19:14:42) [C] on sunos5
-JD
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 22:02
Message:
Logged In: YES
user_id=6606
Issue #1276509 is a duplicate of this issue. I've just
submitted a patch to the python-dev list for this problem,
which I'll attach below (and expect Tracker to mangle):
Index: configure.in
===
--- configure.in(revision 41772)
+++ configure.in(working copy)
@@ -215,6 +215,17 @@
fi
+# See the #define for Py_HUGE_VAL in pyport.h.
+case $ac_sys_system/$ac_sys_release in
+ SunOS/5.10)
+# Solaris 10's /usr/include/iso/math_c99.h defines
HUGE_VAL as
+# __builtin_huge_val, which causes problems when
defining Py_HUGE_VAL.
+AC_DEFINE(Py_HUGE_VAL, HUGE,
+ Define to a positive double which represents
infinity)
+;;
+esac
+
+
#
# SGI compilers allow the specification of the both the ABI
and the
# ISA on the command line. Depending on the values of
these switches,
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 20:52
Message:
Logged In: YES
user_id=6606
As noted by some other people on the web, defining
Py_HUGE_VAL to some other value (e.g. math.h's HUGE, which
is defined as MAXFLOAT on Solaris), a successful compile can
be achieved. If I explicitly #define Py_HUGE_VAL to
__builtin_huge_val, I get the same compilation error as
reported by this bug. Removing optimization flags does not
help. The HUGE_VAL provided by Solaris 10 doesn't seem to
be a workable value for pyport.h's macro.
My little test proggie was missing yet more args, so I'm
posting both the source and output this time.
--- snip ---
#include
int main(char **argv)
{
#ifdef SOLARIS
printf("SOLARIS=%e\n", SOLARIS);
#endif
printf("MAXFLOAT: e=%e, f=%f\n", MAXFLOAT, MAXFLOAT);
printf("HUGE: e=%e, f=%f\n", HUGE, HUGE);
printf("HUGE_VAL: e=%e, f=%f\n", HUGE_VAL, HUGE_VAL);
}
--- snip ---
Output:
MAXFLOAT: e=3.402823e+38,
f=340282346638528859811704183484516925440.00
HUGE: e=3.402823e+38,
f=340282346638528859811704183484516925440.00
HUGE_VAL: e=Inf, f=Inf
--
Comment By: Daniel L. Rall (dlr)
Date: 2005-12-19 19:52
Message:
Logged In: YES
user_id=6606
Oops, forgot an arg -- HUGE_VAL is defined as the following
on Solaris 10:
e=Inf
f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.00
---
