[ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7
Bugs item #1244610, was opened at 2005-07-25 16:31 Message generated for change (Comment added) made by jp3g You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&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: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. -- Comment By: johnnie pittman (jp3g) Date: 2005-08-09 06:34 Message: Logged In: YES user_id=1203137 Hey folks, Also seeing this issue on 3.7. Same setup described above. Loewis, not sure about the first part of your comment. If your asking if those header files exist and are available, yes they are (atleast on my system). -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 12:43 Message: Logged In: YES user_id=21627 So can you tell us whether there are missing prerequisite headers? One would need to have access to your operating system to resolve this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1065456 ] pprint.pformat requires __repr__
Bugs item #1065456, was opened at 2004-11-12 16:36 Message generated for change (Comment added) made by cmoad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&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: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: pprint.pformat requires __repr__ Initial Comment: Not having a __repr__ attribute seem to cause problems for: pprint.pformat in Python 2.4. This problem goes away when I use a Zope instance for Python 2.3. The error message is generated when I try to access a private workspace in the CPS interface. I inserted a bit of debugging code, and I've attached a file that contains the debugging print-out of the data that caused the error and also the traceback. I'm using: CPS-3.2.1 Zope-2.7.3-0 Python 2.4b2 built from source on Linux. I've attached a file containing a bit of debugging information and also the traceback. Dave -- Comment By: Charles Moad (cmoad) Date: 2005-08-08 14:08 Message: Logged In: YES user_id=705459 This problem affects matplotlib still. Here is a short example: import pprint from matplotlib.transforms import unit_bbox b = unit_bbox() pprint.pformat(b) -- Comment By: Walter Dörwald (doerwalter) Date: 2004-11-15 08:53 Message: Logged In: YES user_id=89016 This should be fixed in pprint.py 1.31 in current CVS. Thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1065456 ] pprint.pformat requires __repr__
Bugs item #1065456, was opened at 2004-11-12 22:36 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&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: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: pprint.pformat requires __repr__ Initial Comment: Not having a __repr__ attribute seem to cause problems for: pprint.pformat in Python 2.4. This problem goes away when I use a Zope instance for Python 2.3. The error message is generated when I try to access a private workspace in the CPS interface. I inserted a bit of debugging code, and I've attached a file that contains the debugging print-out of the data that caused the error and also the traceback. I'm using: CPS-3.2.1 Zope-2.7.3-0 Python 2.4b2 built from source on Linux. I've attached a file containing a bit of debugging information and also the traceback. Dave -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-08-09 20:30 Message: Logged In: YES user_id=89016 Which version of Python are you using? Can you post a stack trace? -- Comment By: Charles Moad (cmoad) Date: 2005-08-08 21:08 Message: Logged In: YES user_id=705459 This problem affects matplotlib still. Here is a short example: import pprint from matplotlib.transforms import unit_bbox b = unit_bbox() pprint.pformat(b) -- Comment By: Walter Dörwald (doerwalter) Date: 2004-11-15 14:53 Message: Logged In: YES user_id=89016 This should be fixed in pprint.py 1.31 in current CVS. Thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1065456 ] pprint.pformat requires __repr__
Bugs item #1065456, was opened at 2004-11-12 16:36 Message generated for change (Comment added) made by cmoad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&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: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: pprint.pformat requires __repr__ Initial Comment: Not having a __repr__ attribute seem to cause problems for: pprint.pformat in Python 2.4. This problem goes away when I use a Zope instance for Python 2.3. The error message is generated when I try to access a private workspace in the CPS interface. I inserted a bit of debugging code, and I've attached a file that contains the debugging print-out of the data that caused the error and also the traceback. I'm using: CPS-3.2.1 Zope-2.7.3-0 Python 2.4b2 built from source on Linux. I've attached a file containing a bit of debugging information and also the traceback. Dave -- Comment By: Charles Moad (cmoad) Date: 2005-08-09 13:34 Message: Logged In: YES user_id=705459 This is python 2.4.1 in gentoo linux, compiled from source. Other python 2.4 linux reported the same affect. I don't know how to get a stack trace when python seg faults. We fixed the issue in matplolib's cvs by adding __repr__ support to all the wrapped cxx objects. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-08-09 13:30 Message: Logged In: YES user_id=89016 Which version of Python are you using? Can you post a stack trace? -- Comment By: Charles Moad (cmoad) Date: 2005-08-08 14:08 Message: Logged In: YES user_id=705459 This problem affects matplotlib still. Here is a short example: import pprint from matplotlib.transforms import unit_bbox b = unit_bbox() pprint.pformat(b) -- Comment By: Walter Dörwald (doerwalter) Date: 2004-11-15 08:53 Message: Logged In: YES user_id=89016 This should be fixed in pprint.py 1.31 in current CVS. Thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7
Bugs item #1244610, was opened at 2005-07-25 18:31
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&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: L. Peter Deutsch (lpd)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 build fails on OpenBSD 3.7
Initial Comment:
Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice).
I'm including the logs here because they are short.
"./configure" printed the following:
checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be
compiled
configure: WARNING: curses.h: check for missing
prerequisite headers?
configure: WARNING: curses.h: see the Autoconf
documentation
configure: WARNING: curses.h: section "Present But
Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the
preprocessor's result
configure: WARNING: curses.h: in the future, the
compiler will take precedence
configure: WARNING: ##
##
configure: WARNING: ## Report this to
http://www.python.org/python-bugs ##
configure: WARNING: ##
##
checking for curses.h... yes
This warning was printed for curses.h, ncurses.h,
sys/audioio.h, and sys/lock.h. (The reference to
"Autoconf documentation" is useless, because autoconf
is not used during the configure process, and is not
even installed on the system where I was doing the
build.) Then:
% make
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -I. -I./Include
-DPy_BUILD_CORE -o Modules/python.o Modules/python.c
In file included from /usr/include/sys/select.h:38,
from Include/pyport.h:116,
from Include/Python.h:55,
from Modules/python.c:3:
/usr/include/sys/event.h:53: error: syntax error before
"u_int"
/usr/include/sys/event.h:55: error: syntax error before
"u_short"
*** Error code 1
Stop in /usr/src/Python-2.4.1.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-09 20:40
Message:
Logged In: YES
user_id=21627
Can somebody attach a config.log, or reproduce the fragment
that deals with the curses.h presence?
Does your system require any headers to be included for
curses.h to be usable? I.e. if you do
#include
int main(){}
will that program compile, or do you need additional
('prerequisite') headers?
--
Comment By: johnnie pittman (jp3g)
Date: 2005-08-09 08:34
Message:
Logged In: YES
user_id=1203137
Hey folks,
Also seeing this issue on 3.7. Same setup described above.
Loewis, not sure about the first part of your comment. If
your asking if those header files exist and are available,
yes they are (atleast on my system).
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 14:43
Message:
Logged In: YES
user_id=21627
So can you tell us whether there are missing prerequisite
headers? One would need to have access to your operating
system to resolve this issue.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1254125 ] Python interpreter unnecessarily linked against c++ runtime
Bugs item #1254125, was opened at 2005-08-08 13:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254125&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: None Status: Open Resolution: None Priority: 5 Submitted By: Zak Kipling (zak-k) Assigned to: Nobody/Anonymous (nobody) Summary: Python interpreter unnecessarily linked against c++ runtime Initial Comment: By default, on an ELF-based Linux system with a working g++, the configure script will choose to build a C++ wrapper for main(). This causes the resulting interpreter executable to be linked against libstdc++. However, the comments in bug #224782 suggest that this is not necessary in order to support C++ extension modules on ELF (unlike a.out). Would it be possible for Modules/ccpython.cc to be used only on those systems that don't correctly support dynamically loading C++ code from C executables? I'm currently seeing this with Python 2.4.1, on a Gentoo ~amd64 system. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-09 20:45 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? If you merely look for a way to prevent linkage with libstdc++, please configure --without-cxx. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254125&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1255218 ] "appropriately decorated" is undefined in MultiFile.push doc
Bugs item #1255218, was opened at 2005-08-09 14:07 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=1255218&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: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: "appropriately decorated" is undefined in MultiFile.push doc Initial Comment: At http://docs.python.org/lib/MultiFile-objects.html we read: push( str) Push a boundary string. When an appropriately decorated version of this boundary is found as an input line, it will be interpreted as a section-divider or end-marker. ... But this presumes that "appropriately decorated" is understood, which it won't be until multifile is understood. How about following that sentence with something like: (Appropriate decoration is determined by the section_divider and end_marker methods.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255218&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183972 ] dest parameter in optparse
Bugs item #1183972, was opened at 2005-04-15 15:39 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&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 Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ahmado (ahmado) Assigned to: Greg Ward (gward) Summary: dest parameter in optparse Initial Comment: When using the "callback" action, optparse requires that you STILL specify a "dest" parameter, though it is not required or used by the option parser. In fact, if you do not include the "dest" parameter, your options will still work properly, but optparse will generate an exception when calling the "--help" option. Not specifying a "dest" parameter will result in the following Exception when using the default "--help" or "- h" option: File "c:\Python23\lib\optparse.py", line 229, in format_option_strings metavar = option.metavar or option.dest.upper() AttributeError: 'NoneType' object has no attribute 'upper' by simply adding a bogus bug, the --help / -h option works properly even though the dest isn't actually used. -- >Comment By: Greg Ward (gward) Date: 2005-08-09 20:57 Message: Logged In: YES user_id=14422 ahmado -- please check if this bug is still present in Python 2.4 / Optik 1.5. If you do not respond in a week or two, I will assume that the bug is fixed and close this report. -- Comment By: Greg Ward (gward) Date: 2005-07-21 22:03 Message: Logged In: YES user_id=14422 I'm pretty sure I fixed this in Optik 1.5 / Python 2.4. Can you 1) verify if the bug is still there in Python 2.4 and 2) if so, supply a small script demonstrating the problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1255395 ] float('-inf')
Bugs item #1255395, was opened at 2005-08-10 11: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=1255395&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: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bird (stevenbird)
Assigned to: Nobody/Anonymous (nobody)
Summary: float('-inf')
Initial Comment:
Python 2.4.1 on Windows raises "ValueError: invalid
literal for float(): -inf", though this works just fine
on unix distributions of Python 2.4.1.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255395&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099364 ] raw_input() displays wrong unicode prompt
Bugs item #1099364, was opened at 2005-01-10 11:33
Message generated for change (Settings changed) made by prikryl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&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: Works For Me
>Priority: 7
Submitted By: Petr Prikryl (prikryl)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input() displays wrong unicode prompt
Initial Comment:
I have observed a problem when running
Python 2.4, Windows version (python-2.4.msi)
and using raw_input() with unicode prompt
string in a console program (ran in the DOS window).
I do use the following sitecustomize.py file to set
the default encoding in the English Windows 2000 Server:
sitecustomize.py
=
import sys
sys.setdefaultencoding('cp1250')
=
test.py
=
# -*- coding: cp1250 -*-
s = u'string with accented letters (different than this)'
print s# OK
val = raw_input(s)# s displayed differently (wrong)
=
See the test.png
(captured from screen) and the test.py for the
used string -- inside the attached zip file.
The "type test.py" (result visible on the captured
screen) displays the string
definition also wrongly, because the DOS window
uses different encoding than cp1250. The print
command prints the string correctly, converting
the internal unicode string to the encoding that
the is defined by the output environment. However,
the raw_input() probably does convert the unicode
string to the cp1250 and does not do the same
(more clever) thing that the print does.
I did not use the unicode in older Python (2.3.4),
so I do not know what was the behaviour earlier.
Could you confirm the bug? Sorry if the bug
is well known.
Petr
--
Comment By: Petr Prikryl (prikryl)
Date: 2005-08-08 10:37
Message:
Logged In: YES
user_id=771873
As the patch #1214889 that would have solved the problem
on lower levels was rejected, the problem should be reopened
and the raw_input() internals should be implemented similarly
to print.
Thanks,
Petr
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-28 08:40
Message:
Logged In: YES
user_id=1188172
You'll have to explicitly encode the unicode string using
raw_input(s.encode(sys.stdout.encoding)).
As said, this behaviour will change if the patch mentioned
is accepted.
--
Comment By: Petr Prikryl (prikryl)
Date: 2005-06-28 07:56
Message:
Logged In: YES
user_id=771873
Should I understand it that there is no bug, but I do use it
incorrectly? I cannot agree that this is expected behaviour. (I
am not the only one who found this strange.)
Of course, the sys.stdout.encoding is different for a DOS
window (cp852) than the default encoding (cp1250). Windows
simply behaves this way when working with DOS window
(because of legacy DOS applications).
I do not complain on behaviour of sys.stdout.write() but on
behaviour of raw_input(). The output of raw_input() prompt
should be displayed the same way as the print diplays the
results to the user. The raw_input() is used for building user
interface. Its prompt should not be displayed differently in
windows that use different encoding (i.e. DOS console vs.
say IDLE console).
In other words, how should I use raw_input() to make it
working correctly?
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-26 22:34
Message:
Logged In: YES
user_id=1188172
Actually, your sys.stdout.encoding is set to something
different than cp1250, which is why the result of DOS type
looks the same as the one of print.
This is because print observes sys.stdout.encoding, while
sys.stdout.write uses the system default encoding, which is,
as you set it, cp1250 and is displayed wrong on the console.
Closing this bug, as it is currently expected behaviour (but
will perhaps change when patch #1214889 is accepted).
--
Comment By: Petr Prikryl (prikryl)
Date: 2005-04-14 16:34
Message:
Logged In: YES
user_id=771873
Python 2.4.1 for Windows behaves the same way.
Petr
--
Comment By: Petr Prikryl (prikryl)
Date: 2005-04-14 16:26
Message:
Logged In: YES
user_id=771873
New observation: sys.stdout.write(s) behaves visually on the
screen exactly as the raw_input(s) does. So, print does
something more when displaying on the
