[ python-Bugs-1464978 ] test_urllib2 and test_mimetypes = failure
Bugs item #1464978, was opened at 2006-04-06 00:19 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464978&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.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: test_urllib2 and test_mimetypes = failure Initial Comment: Logging here because I don't have time to look into it at the moment. On Linux at least, "regrtest test_urllib2 test_mimetypes" will fail, because the mimetypes module's global dictionaries get modified by urllib2. The proper fix is to probably edit test_mimetypes to remove the assumptions that it knows what's in the mimetypes dictionary. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:38 Message: Logged In: YES user_id=29957 Fixed in 43688 (trunk) and 43689 (release24-maint) I moved the default setting into a new function, and made test_mimetypes call that to reset things to a known state. module level global dictionaries suck. :-( -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464978&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465554 ] Cygwin installer should create a link to libpython2.5.dll.a
Bugs item #1465554, was opened at 2006-04-06 10:46 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=1465554&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin installer should create a link to libpython2.5.dll.a Initial Comment: Installer should create a link to /usr/lib/python25/config/libpython2.5.dll.a in /usr/lib /usr/lib/python25/config is *not* in the linker path and build extensions using distutils don't work. Create a link in /usr/lib fixes the problem. Another option is to change distutils to add /usr/lib/python25/config to linker path on cygwin platforms. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465554&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465408 ] HP-UX11i installation failure
Bugs item #1465408, was opened at 2006-04-06 09:34 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=29957 If you put a '-' at the start of the line in the Makefile, it should build ok. Make it: $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(ASDLGEN) $(AST_ASDL) Obviously there's some issues with timestamps on the files and it's trying to rebuild the file unnecessarily... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465408 ] HP-UX11i installation failure
Bugs item #1465408, was opened at 2006-04-06 09:34 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:56 Message: Logged In: YES user_id=29957 Right. Python.asdl and the output files that depend on it have the same timestamps in the tarball. This is because they get updated and all checked in in the same svn revision. When the export is done, the timestamps are set to the same time. Possible solutions: - make ignores this failure. Bad, because it might stop _real_ errors. - make catches lack of Python, and skips the step. Ugly, and hard to do in a platform-compatible way. - I change the 'welease.py' script to adjust the timestamps of the files before making the release tarballs. This is so nasty it makes me sick. But I can't see a better option. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=29957 If you put a '-' at the start of the line in the Makefile, it should build ok. Make it: $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(ASDLGEN) $(AST_ASDL) Obviously there's some issues with timestamps on the files and it's trying to rebuild the file unnecessarily... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465408 ] HP-UX11i installation failure
Bugs item #1465408, was opened at 2006-04-06 09:34 Message generated for change (Settings changed) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&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.5 Status: Open Resolution: None >Priority: 7 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:56 Message: Logged In: YES user_id=29957 Right. Python.asdl and the output files that depend on it have the same timestamps in the tarball. This is because they get updated and all checked in in the same svn revision. When the export is done, the timestamps are set to the same time. Possible solutions: - make ignores this failure. Bad, because it might stop _real_ errors. - make catches lack of Python, and skips the step. Ugly, and hard to do in a platform-compatible way. - I change the 'welease.py' script to adjust the timestamps of the files before making the release tarballs. This is so nasty it makes me sick. But I can't see a better option. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=29957 If you put a '-' at the start of the line in the Makefile, it should build ok. Make it: $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(ASDLGEN) $(AST_ASDL) Obviously there's some issues with timestamps on the files and it's trying to rebuild the file unnecessarily... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes
Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Fleming (splitscreen)
Assigned to: Tim Peters (tim_one)
Summary: Python does not check for POSIX compliant open() modes
Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().
According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.
This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 08:15
Message:
Logged In: YES
user_id=849994
splitscreen: your patch was incomplete and could have
overwritten memory.
tim_one: Attaching new patch implementing what I proposed in
my comment below.
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 21:59
Message:
Logged In: YES
user_id=1126061
Ok, uploading latest patch, not quite sure I've hit the mark
here.
Please review.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 20:43
Message:
Logged In: YES
user_id=849994
Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 19:32
Message:
Logged In: YES
user_id=1126061
Ignore my question, it's for "universal newlines", right?
Have I understood your proposal correctly in that you want
to remove the 'U' from the mode?
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 14:14
Message:
Logged In: YES
user_id=1126061
That seems sensible. What does a mode containing 'U' mean
anyway?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:08
Message:
Logged In: YES
user_id=849994
Instead of this patch, I'd rather like check_the_mode to
* remove any 'U' from the mode string
* if 'U' was found:
* error out if the new string begins with 'w' or 'a'
* add a 'r' and 'b' if it isn't already given
* if not:
* error out if the string doesn't begin with 'w', 'r', 'a'
What do you think of it?
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:03
Message:
Logged In: YES
user_id=31435
There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed. I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").
All that said, I'm in favor of this patch ;-). However, if
it goes in two things are needed:
1. The error message should be more informative, like
PyErr_Format(PyExc_ValueError, "mode argument must "
"begin with 'w', 'r', or 'a', not '%.200s'", mode);
2. The Python docs should change to match (i.e., the
manual should document this new restriction on mode
strings).
WRT the test case, it's more natural to write, e.g.,
TESTFN in s
than
s.find(TESTFN) != -1
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465600 ] zipfile - arcname must be encode in cp437
Bugs item #1465600, was opened at 2006-04-06 11:33 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=1465600&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: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile - arcname must be encode in cp437 Initial Comment: In the doc should be a note insert: The arcnames in zipfile must be encoded in cp437 I think it should be insert here: http://docs.python.org/lib/zipfile-objects.html Look the comments in this bug: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=878120 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465600&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465600 ] zipfile - arcname must be encode in cp437
Bugs item #1465600, was opened at 2006-04-06 09:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465600&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: Not a Bug >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile - arcname must be encode in cp437 Initial Comment: In the doc should be a note insert: The arcnames in zipfile must be encoded in cp437 I think it should be insert here: http://docs.python.org/lib/zipfile-objects.html Look the comments in this bug: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=878120 -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 10:03 Message: Logged In: YES user_id=849994 Thanks! Fixed in rev. 43699, 43700. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465600&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465619 ] str.decode('rot13') produces Unicode
Bugs item #1465619, was opened at 2006-04-06 10: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=1465619&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: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.decode('rot13') produces Unicode
Initial Comment:
In 3.8.3 Standard Encodings, the table at the bottom
listing special encodings says that the result of
str.decode('rot13') is a byte string. In Python 2.4.3
it is actually a Unicode string so this table entry
should be changed.
In [40]: 'abc'.decode('rot13')
Out[40]: u'nop'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-878120 ] Zipfile archive name can't be unicode
Bugs item #878120, was opened at 2004-01-16 10:32
Message generated for change (Comment added) made by pylucid
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878120&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: Extension Modules
Group: Python 2.3
Status: Deleted
Resolution: None
Priority: 5
Submitted By: Simon Harrison (ssmmhh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Zipfile archive name can't be unicode
Initial Comment:
In Python 2.3.2, The following code:
import zipfile
z = zipfile.ZipFile( "file.zip", "w" )
z.write( "file.txt", u"file.txt" )
z.close()
Results in this exception:
Traceback (most recent call last):
File "E:\dev\ziptest.py", line 8, in ?
z.write( "file.txt", u"file.txt" )
File "D:\Python23\lib\zipfile.py", line 412, in write
self.fp.write(zinfo.FileHeader())
File "D:\Python23\lib\zipfile.py", line 166, in FileHeader
return header + self.filename + self.extra
UnicodeDecodeError: 'ascii' codec can't decode byte
0xd5 in position 10: ordinal
not in range(128)
The code could be fixed in zipfile.py.
Something along the lines of:
return header + self.filename.encode("utf-8") + self.extra
On Windows ideally the code should figure out the
current locale's codepage and use that to encode the
filename into the correct multibyte sequence.
The example above is pretty easy to spot, but if the
arcname is coming from a COM property (my case) it
takes a while to figure out why zipfile is crashing!
This is bug 705295 resubmitted:
https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=705295&group_id=5470
--
Comment By: Jens Diemer (pylucid)
Date: 2006-04-06 12:39
Message:
Logged In: YES
user_id=1330780
Hm! Which occurs to me straight:
Shouldn't Python make the conversion automaticly?
If the arcname is type unicode, Python should convert it to
cp437.
--
Comment By: Martin v. Löwis (loewis)
Date: 2004-01-18 15:54
Message:
Logged In: YES
user_id=21627
I don't know who the info-zip walker is, but atleast Winzip
will interpret all file names as CP437. This becomes obvious
when you try to unzip a file name with non-ASCII characters
on Windows NT: the resulting Unicode file names are
generated as-if the encoding used is code page 437. I
believe this is the same in pkware.
--
Comment By: Simon Harrison (ssmmhh)
Date: 2004-01-18 12:42
Message:
Logged In: YES
user_id=775521
I would be happy to just see an exception indicating that
the supplied filename mustn't be unicode, to save people
time figuring this one out in the future. I can supply a
patch but I thought this was too trivial for that.
You wrote:
>Names in zip files are stored in code page 437
Correct me if I'm wrong, but won't the info-zip directory
walker just stick whatever it enumerates into the name
field? I don't quite understand what you mean by 'no support'.
--
Comment By: Martin v. Löwis (loewis)
Date: 2004-01-18 00:56
Message:
Logged In: YES
user_id=21627
Using UTF-8 is incorrect. Names in zip files are stored in
code page 437. There is no support for file names outside
this character set.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878120&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465643 ] test_logging hangs on cygwin
Bugs item #1465643, was opened at 2006-04-06 13:44 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=1465643&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging hangs on cygwin Initial Comment: Python 2.5a1, CYGWIN make test test_logging hangs -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465643&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-878120 ] Zipfile archive name can't be unicode
Bugs item #878120, was opened at 2004-01-16 09:32
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878120&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: Extension Modules
Group: Python 2.3
Status: Deleted
Resolution: None
Priority: 5
Submitted By: Simon Harrison (ssmmhh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Zipfile archive name can't be unicode
Initial Comment:
In Python 2.3.2, The following code:
import zipfile
z = zipfile.ZipFile( "file.zip", "w" )
z.write( "file.txt", u"file.txt" )
z.close()
Results in this exception:
Traceback (most recent call last):
File "E:\dev\ziptest.py", line 8, in ?
z.write( "file.txt", u"file.txt" )
File "D:\Python23\lib\zipfile.py", line 412, in write
self.fp.write(zinfo.FileHeader())
File "D:\Python23\lib\zipfile.py", line 166, in FileHeader
return header + self.filename + self.extra
UnicodeDecodeError: 'ascii' codec can't decode byte
0xd5 in position 10: ordinal
not in range(128)
The code could be fixed in zipfile.py.
Something along the lines of:
return header + self.filename.encode("utf-8") + self.extra
On Windows ideally the code should figure out the
current locale's codepage and use that to encode the
filename into the correct multibyte sequence.
The example above is pretty easy to spot, but if the
arcname is coming from a COM property (my case) it
takes a while to figure out why zipfile is crashing!
This is bug 705295 resubmitted:
https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=705295&group_id=5470
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 10:53
Message:
Logged In: YES
user_id=849994
There's no specs that say which encoding the file names
should have. That WinZip uses cp437 is its own choice. Other
sources tell "Zip programs by default assume the filenames
are encoded using the code page of the machine", so it's
better to leave the encoding to the user of zipfile.
--
Comment By: Jens Diemer (pylucid)
Date: 2006-04-06 10:39
Message:
Logged In: YES
user_id=1330780
Hm! Which occurs to me straight:
Shouldn't Python make the conversion automaticly?
If the arcname is type unicode, Python should convert it to
cp437.
--
Comment By: Martin v. Löwis (loewis)
Date: 2004-01-18 14:54
Message:
Logged In: YES
user_id=21627
I don't know who the info-zip walker is, but atleast Winzip
will interpret all file names as CP437. This becomes obvious
when you try to unzip a file name with non-ASCII characters
on Windows NT: the resulting Unicode file names are
generated as-if the encoding used is code page 437. I
believe this is the same in pkware.
--
Comment By: Simon Harrison (ssmmhh)
Date: 2004-01-18 11:42
Message:
Logged In: YES
user_id=775521
I would be happy to just see an exception indicating that
the supplied filename mustn't be unicode, to save people
time figuring this one out in the future. I can supply a
patch but I thought this was too trivial for that.
You wrote:
>Names in zip files are stored in code page 437
Correct me if I'm wrong, but won't the info-zip directory
walker just stick whatever it enumerates into the name
field? I don't quite understand what you mean by 'no support'.
--
Comment By: Martin v. Löwis (loewis)
Date: 2004-01-17 23:56
Message:
Logged In: YES
user_id=21627
Using UTF-8 is incorrect. Names in zip files are stored in
code page 437. There is no support for file names outside
this character set.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878120&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465646 ] test_grp & test_pwd fail
Bugs item #1465646, was opened at 2006-04-06 11:57 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=1465646&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: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465619 ] str.decode('rot13') produces Unicode
Bugs item #1465619, was opened at 2006-04-06 10:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&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: Kent Johnson (kjohnson)
>Assigned to: Walter Dörwald (doerwalter)
Summary: str.decode('rot13') produces Unicode
Initial Comment:
In 3.8.3 Standard Encodings, the table at the bottom
listing special encodings says that the result of
str.decode('rot13') is a byte string. In Python 2.4.3
it is actually a Unicode string so this table entry
should be changed.
In [40]: 'abc'.decode('rot13')
Out[40]: u'nop'
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 10:59
Message:
Logged In: YES
user_id=849994
Walter: Wouldn't make it sense for rot13 to actually output
byte strings?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465619 ] str.decode('rot13') produces Unicode
Bugs item #1465619, was opened at 2006-04-06 12:05
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&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: Kent Johnson (kjohnson)
Assigned to: Walter Dörwald (doerwalter)
Summary: str.decode('rot13') produces Unicode
Initial Comment:
In 3.8.3 Standard Encodings, the table at the bottom
listing special encodings says that the result of
str.decode('rot13') is a byte string. In Python 2.4.3
it is actually a Unicode string so this table entry
should be changed.
In [40]: 'abc'.decode('rot13')
Out[40]: u'nop'
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-06 13:18
Message:
Logged In: YES
user_id=38388
rot 13 returns Unicode because it uses the charmap codec
which works this way.
I don't see much of a reason to change this.
The documentation will have to be updated, though.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 12:59
Message:
Logged In: YES
user_id=849994
Walter: Wouldn't make it sense for rot13 to actually output
byte strings?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465619 ] str.decode('rot13') produces Unicode
Bugs item #1465619, was opened at 2006-04-06 10:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Walter Dörwald (doerwalter)
Summary: str.decode('rot13') produces Unicode
Initial Comment:
In 3.8.3 Standard Encodings, the table at the bottom
listing special encodings says that the result of
str.decode('rot13') is a byte string. In Python 2.4.3
it is actually a Unicode string so this table entry
should be changed.
In [40]: 'abc'.decode('rot13')
Out[40]: u'nop'
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 11:25
Message:
Logged In: YES
user_id=849994
Okay. Fixed docs in rev. 43701, 43702.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-06 11:18
Message:
Logged In: YES
user_id=38388
rot 13 returns Unicode because it uses the charmap codec
which works this way.
I don't see much of a reason to change this.
The documentation will have to be updated, though.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 10:59
Message:
Logged In: YES
user_id=849994
Walter: Wouldn't make it sense for rot13 to actually output
byte strings?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname
Bugs item #1464506, was opened at 2006-04-04 23:14
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&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: Extension Modules
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Thomas Heller (theller)
Summary: ctypes testsuite hardcodes libc soname
Initial Comment:
on Debian alpha-linux and Debian/Ubuntu hppa-linux,
libc's soname is libc.so.6.1. A more portable way to
find about the libc soname might be to check ldd on the
python executable (or any other executable)
$ ldd /bin/ls | awk '/libc\.so/ {print $3}'
/lib/tls/libc.so.6.1
$ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}'
libc.so.6.1
--
>Comment By: Thomas Heller (theller)
Date: 2006-04-06 14:25
Message:
Logged In: YES
user_id=11105
This is fixed now.
--
Comment By: Matthias Klose (doko)
Date: 2006-04-06 00:46
Message:
Logged In: YES
user_id=60903
no, please see
http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0
(that's the last run of current trunk, AFAIK)
--
Comment By: Thomas Heller (theller)
Date: 2006-04-05 16:06
Message:
Logged In: YES
user_id=11105
Actually the bug in in the ctypes test module. nnorwitz's
change helps loading libraries, but not to determine which
libraries should by loaded. doko's method allows to fix this.
I'll commit a patch soon, thanks.
--
Comment By: Matthias Klose (doko)
Date: 2006-04-05 11:02
Message:
Logged In: YES
user_id=60903
no, please see
http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0
(that's the last run of current trunk, AFAIK)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-05 06:38
Message:
Logged In: YES
user_id=33168
Heh, I added ldd support in ctypes/_loader.py _findLib_ld.
Does that address this issue? Or perhaps at least partially
address? It looks like in the current buildbot, this part
of ctypes isn't failing. Maybe this can be closed?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Bugs item #1463043, was opened at 2006-04-02 15:03
Message generated for change (Comment added) made by rptownsend
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&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: Richard Townsend (rptownsend)
Assigned to: Martin v. Löwis (loewis)
Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Initial Comment:
I built Python-2.4.3 from source on SUSE 9.3 and get
the following error for test_minidom.py
/usr/local/src/Python-2.4.3: ./python
Lib/test/test_minidom.py
Failed Test
Test Failed: testAltNewline
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 427, in
testAltNewline
confirm(domstr == str.replace("\n", "\r\n"))
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed testEncodings - encoding EURO SIGN
Test Failed: testEncodings
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 891, in
testEncodings
"testEncodings - encoding EURO SIGN")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed After replaceChild()
Test Failed: testPatch1094164
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 1137, in
testPatch1094164
confirm(e.parentNode is elem, "After replaceChild()")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed Test
Test Failed: testWriteXML
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 420, in
testWriteXML
confirm(str == domstr)
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Check for failures in these tests:
testAltNewline
testEncodings
testPatch1094164
testWriteXML
--
>Comment By: Richard Townsend (rptownsend)
Date: 2006-04-06 13:31
Message:
Logged In: YES
user_id=200117
Interestingly, the error doesn't occur with Python-2.5a1
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 07:27
Message:
Logged In: YES
user_id=33168
Martin maintains PyXML AFAIK. Maybe he has some ideas. I
suspect this might be even worse in 2.5. Element Tree was
added and there was a name change. Some of those things
still need to be addressed.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-03 14:37
Message:
Logged In: YES
user_id=200117
Hi Neal,
I've just built 2.4.3 on a Red Hat Enterpeise Edition WS
V4.2 machine and this gives the same error.
I've had this vague feeling that I've seen something like
this before, but couldn't find anything when I searched the
tracker...
I've now realised that the error is due to a conflict with
PyXML-0.8.4 which was already installed on both machines.
If I rename the ../site_packages/_xmlplus directory to a
different name then the error goes away (on the Red Hat
machine at least, the SUSE machine is at home).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 06:37
Message:
Logged In: YES
user_id=33168
Thanks for letting us know about where the regression
occurred. Can you do a little more debugging to try to find
the cause and some ideas about how to fix it?
I'm not sure that any developer runs on a system that
exhibits this error. So it will probably be very difficult
for us to figure it out since we can't reproduce it.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-02 15:28
Message:
Logged In: YES
user_id=200117
I've just retested with earlier versions.
No error with Python-2.4.1
Similar error with Python-2.4.2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). -- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464658 ] PyList_GetItem() clarification
Bugs item #1464658, was opened at 2006-04-05 03:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464658&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: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: PyList_GetItem() clarification Initial Comment: The PyList_GetItem function is documented at http://docs.python.org/api/listObjects.html as returning "...the object at position pos...". However, even though in python -1 is a valid index, this function expects a 'real' index. 1) I believe it would be worthwhile pointing out in the API docs that in fact a positive value is expected. 2) It would be good to change the function signature to expect an unsigned int instead of an int for the index. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 12:46 Message: Logged In: YES user_id=849994 Thanks! Fixed in rev. 43704, 43705. -- Comment By: Matt Fleming (splitscreen) Date: 2006-04-05 11:59 Message: Logged In: YES user_id=1126061 I agree with these suggestions. It's not impossible for someone to 'just assume' a negative index is handled correctly by PyList_GetItem(). +1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464658&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname
Bugs item #1464506, was opened at 2006-04-04 23:14
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&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: Extension Modules
Group: None
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Thomas Heller (theller)
Summary: ctypes testsuite hardcodes libc soname
Initial Comment:
on Debian alpha-linux and Debian/Ubuntu hppa-linux,
libc's soname is libc.so.6.1. A more portable way to
find about the libc soname might be to check ldd on the
python executable (or any other executable)
$ ldd /bin/ls | awk '/libc\.so/ {print $3}'
/lib/tls/libc.so.6.1
$ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}'
libc.so.6.1
--
>Comment By: Thomas Heller (theller)
Date: 2006-04-06 14:47
Message:
Logged In: YES
user_id=11105
Resolution is 'fixed', not 'duplicate'.
--
Comment By: Thomas Heller (theller)
Date: 2006-04-06 14:25
Message:
Logged In: YES
user_id=11105
This is fixed now.
--
Comment By: Matthias Klose (doko)
Date: 2006-04-06 00:46
Message:
Logged In: YES
user_id=60903
no, please see
http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0
(that's the last run of current trunk, AFAIK)
--
Comment By: Thomas Heller (theller)
Date: 2006-04-05 16:06
Message:
Logged In: YES
user_id=11105
Actually the bug in in the ctypes test module. nnorwitz's
change helps loading libraries, but not to determine which
libraries should by loaded. doko's method allows to fix this.
I'll commit a patch soon, thanks.
--
Comment By: Matthias Klose (doko)
Date: 2006-04-05 11:02
Message:
Logged In: YES
user_id=60903
no, please see
http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0
(that's the last run of current trunk, AFAIK)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-05 06:38
Message:
Logged In: YES
user_id=33168
Heh, I added ldd support in ctypes/_loader.py _findLib_ld.
Does that address this issue? Or perhaps at least partially
address? It looks like in the current buildbot, this part
of ctypes isn't failing. Maybe this can be closed?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464571 ] Changes to generator object's gi_frame attr
Bugs item #1464571, was opened at 2006-04-04 23:44 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: A.M. Kuchling (akuchling) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. -- Comment By: Collin Winter (collinwinter) Date: 2006-04-04 23:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465646 ] test_grp & test_pwd fail
Bugs item #1465646, was opened at 2006-04-06 10:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&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: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 13:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Feature Requests item #1351692, was opened at 2005-11-08 22:29
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hirota (markhirota)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Switch to make pprint.pprint display ints and longs in hex
Initial Comment:
It would be nice to have some sort of switch or hook to
allow 'pretty-printing' of integers and long integers in
hexidecimal. So, for example:
>>> import pprint
>>> pprint.pprint(range(10)) # instead of this:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> pprint.hexint = True
>>> pprint.pprint(range(10)) # you would get this:
[0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9]
>>> pprint.pprint(range(0x1,0x10010)) #
and this:
[0x1L,
0x10001L,
0x10002L,
0x10003L,
0x10004L,
0x10005L,
0x10006L,
0x10007L,
0x10008L,
0x10009L,
0x1000AL,
0x1000BL,
0x1000CL,
0x1000DL,
0x1000EL,
0x1000FL]
>>>
Thanks,
--MH
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2006-04-06 15:02
Message:
Logged In: YES
user_id=89016
Can this still be checked in after 2.5a1 is out the door? It
is a new feature not just a bug fix.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-06 01:11
Message:
Logged In: YES
user_id=6380
What's this waiting for?
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-11-22 21:56
Message:
Logged In: YES
user_id=89016
I think this patch can go in. Any objections from Raymond or
Fred against this?
--
Comment By: Mark Hirota (markhirota)
Date: 2005-11-17 02:04
Message:
Logged In: YES
user_id=1375527
Walter, I agree that there still seems to be an issue with
_format() calling _repr() multiple times, however this
patch seems to enable my feature request using sub-
classing. Can the other issue (which exists presently
also) be ignored for now? Could you submit the patch, or
is that something I should do? Thanks.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-11-16 19:29
Message:
Logged In: YES
user_id=89016
Here's your modified version as a patch against svn HEAD.
(Most of the patch is indentation changes. "svn diff
--diff-cmd diff -x -b Lib/pprint.py" gives this diff:
134d133
< if sepLines:
154a154
> if sepLines:
155a156,157
> else:
> write(', %s: ' % rep)
180a183
> if sepLines:
181a185,186
> else:
> write(', ')
190d194
<
192a197
>
The patch looks good, but it still has a problem that the
original pprint has: For each call to format() the object is
formatted twice, once to determine if it fits on one line
and once for the final output.
--
Comment By: Mark Hirota (markhirota)
Date: 2005-11-14 19:33
Message:
Logged In: YES
user_id=1375527
Did some digging into the code and found that the "if
sepLines:" condition in the PrettyPrinter._format() method
was the source of the limitation.
I've attached a modified version of pprint.py where the "if
sepLines" is more embedded. It gives the following results:
>>> import pprintmod
>>> class MyPrettyPrinter(pprintmod.PrettyPrinter):
def format(self, object, context, maxlevels, level):
if isinstance(object, int):
return hex(object), True,
False
else:
return
pprintmod.PrettyPrinter.format(
self, object,
context, maxlevels, level)
>>> mpp = MyPrettyPrinter()
>>> mpp.pprint(range(10))
[0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9]
>>> mpp.pprint(range(0x1000,0x1010))
[0x1000,
0x1001,
0x1002,
0x1003,
0x1004,
0x1005,
0x1006,
0x1007,
0x1008,
0x1009,
0x100a,
0x100b,
0x100c,
0x100d,
0x100e,
0x100f]
>>>
Would this be an acceptable change? Thanks,
--
Comment By: Mark Hirota (markhirota)
Date: 2005-11-14 18:04
Message:
Logged In: YES
user_id=1375527
Sorry, but maybe I could just interject here. Walter's sub-
classing example works fine, except
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). -- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). -- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465646 ] test_grp & test_pwd fail
Bugs item #1465646, was opened at 2006-04-06 11:57 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&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: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. -- >Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 15:42 Message: Logged In: YES user_id=200117 The test workstation is getting its password and group info from NIS. The test workstation is running Red Hat Linux, but the NIS server is running HPUX 11i. I believe these are the entries causing the errors: lancaster:/etc > ypcat passwd | grep '-' nobody:*:-2:-2::/: lancaster:/etc > ypcat group | grep '-' nogroup:*:-2: -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 14:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError
Bugs item #1446043, was opened at 2006-03-08 19:55
Message generated for change (Comment added) made by osvenskan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&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: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode('foo', '.utf99') does not raise LookupError
Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.
I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.
--
>Comment By: osvenskan (osvenskan)
Date: 2006-04-06 10:45
Message:
Logged In: YES
user_id=1119995
I noticed that the documentation for unicode() says, "if the
encoding is not known, LookupError is raised". Regarding the
3rd parameter ("errors") to unicode(), the docs say, "Error
handling is done according to errors; this specifies the
treatment of characters which are invalid in the input
encoding. If errors is 'strict' (the default), a ValueError
is raised on errors..."
ref: http://docs.python.org/lib/built-in-funcs.html
That makes the code's current behavior doubly confusing
because a the documentation says that a ValueError is
reserved for indicating an undecodable byte sequence, not an
unknown encoding name.
--
Comment By: osvenskan (osvenskan)
Date: 2006-03-09 10:04
Message:
Logged In: YES
user_id=1119995
There are encoding names that contain dots, such as
ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as
reported by iconv). There are none in iconv's list that
begin with a dot.
Please note that the behavior of this function has been
discussed before in Python bugs 513666 and 960874. Apologies
for not referencing them in my original report.
Having stepped through the code, I understand how the
ValueError is getting generated. My frustration with this as
a programmer is that I want to write specific except clauses
for each possible exception that a method can raise, but
that's impractical if any exception is fair game on any
method. So I'm forced to use a catch-all except clause about
which the Python documentation says (wisely, IMHO), "Use
this with extreme caution, since it is easy to mask a real
programming error in this way!" While it is helpful to
document errors that a method is *likely* to raise, my code
needs to handle all possibilities, not just likely ones.
Perhaps the answer is just, "This is how Python works" and
if I feel it is a weakness in the language I need to take it
up on a different level.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 03:16
Message:
Logged In: YES
user_id=849994
Is it possible for an encoding name to contain dots at all?
If not, this would do too:
if '.' in modname: continue
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-03-09 03:12
Message:
Logged In: YES
user_id=89016
The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:
if ".".join(filter(None, modname.split("."))) != modname:
return None
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1437699 ] allow unicode arguments for robotparser.can_fetch
Feature Requests item #1437699, was opened at 2006-02-23 16:07
Message generated for change (Comment added) made by osvenskan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1437699&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: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
Assigned to: Skip Montanaro (montanaro)
Summary: allow unicode arguments for robotparser.can_fetch
Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError.
More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)
I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:
AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8
A suggested solution:
AFAICT, the construction of robots.txt is still defined
by "a consensus on 30 June 1994 on the robots mailing
list" [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
("ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road..." etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character
sets other than "ISO-8859-1" or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.
--
>Comment By: osvenskan (osvenskan)
Date: 2006-04-06 11:34
Message:
Logged In: YES
user_id=1119995
I've also discovered that robotparser can get confused by
files with BOMs (byte order marks). At minimum it should
ignore BOMs, at best it should use them as clues as to the
file's encoding. It does neither, and instead treats the BOM
as character data. That's especially problematic when the
robots.txt file consists of this:
[BOM]User-agent: *
Disallow: /
In that case, robotparser fails to recognize the string
"User-agent", so the disallow rule is ignored, which in turn
means it treats the file as empty and all robots are
permitted everywhere which is the exact opposite of what the
author intended. If the first line is a comment, then
robotparser doesn't get confused regardless of whether or
not there's a BOM.
I created a sample robots.txt file exactly like the one
above; it contains a utf-8 BOM. The example below uses this
file which is on my Web site.
>>> import robotparser
>>> rp=robotparser.RobotFileParser()
>>>
rp.set_url("http://semanchuk.com/philip/boneyard/robots/robots.txt.bom";)
>>> rp.read()
>>> rp.can_fetch("foobot", "/") # should return False
True
>>>
My robot parser module doesn't suffer from the BOM bug
(although it doesn't use BOMs to decode the file, either,
[ python-Bugs-1465646 ] test_grp & test_pwd fail
Bugs item #1465646, was opened at 2006-04-06 10:57 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&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: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. -- Comment By: Matt Fleming (splitscreen) Date: 2006-04-06 15:48 Message: Logged In: YES user_id=1126061 AFAIK getgrgid() doesn't handle negative integers very well (I can't even add a group with a negative gid on my NetBSD machine). -- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 14:42 Message: Logged In: YES user_id=200117 The test workstation is getting its password and group info from NIS. The test workstation is running Red Hat Linux, but the NIS server is running HPUX 11i. I believe these are the entries causing the errors: lancaster:/etc > ypcat passwd | grep '-' nobody:*:-2:-2::/: lancaster:/etc > ypcat group | grep '-' nogroup:*:-2: -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 13:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465408 ] HP-UX11i installation failure
Bugs item #1465408, was opened at 2006-04-05 16:34 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&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.5 Status: Open Resolution: None Priority: 7 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com -- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-04-06 09:16 Message: Logged In: YES user_id=71407 I get a complete build if I touch Include/Python-ast.h Python/Python-ast.c before running configure. If you wait a second after the svn export and then touch these two files I'd expect the tarball to work out of the box. Another idea is to work with MD5 signatures, like SCons does. But if you don't have a Python yet it is probably difficult to find a fully portable solution. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 00:56 Message: Logged In: YES user_id=29957 Right. Python.asdl and the output files that depend on it have the same timestamps in the tarball. This is because they get updated and all checked in in the same svn revision. When the export is done, the timestamps are set to the same time. Possible solutions: - make ignores this failure. Bad, because it might stop _real_ errors. - make catches lack of Python, and skips the step. Ugly, and hard to do in a platform-compatible way. - I change the 'welease.py' script to adjust the timestamps of the files before making the release tarballs. This is so nasty it makes me sick. But I can't see a better option. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 00:48 Message: Logged In: YES user_id=29957 If you put a '-' at the start of the line in the Makefile, it should build ok. Make it: $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(ASDLGEN) $(AST_ASDL) Obviously there's some issues with timestamps on the files and it's trying to rebuild the file unnecessarily... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1
Bugs item #1465834, was opened at 2006-04-06 17:40 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=1465834&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: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465838 ] HP-UX11i: illegal combination of compilation and link flags
Bugs item #1465838, was opened at 2006-04-06 09:53 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=1465838&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i: illegal combination of compilation and link flags Initial Comment: According to Boris Gubenko from the HP-UX compiler development team, it is illegal to link with -lpthread if the sources are not compiled with -mt. However, this is exactly what happens during Python installation, e.g.: cc -Ae -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Python/compile.o Python/compile.c ... aCC -Wl,-E -Wl,+s -o python \ Modules/python.o \ libpython2.5.a -lnsl -lrt -ldld -ldl -lpthread -lm This illegal combination of compilation and link flags eventually results in obscure runtime failures (segfault, abort) while running Boost.Python C++ extensions. These failures go away if Python is installed with, e.g.: env CXX="aCC -mt" BASECFLAGS="-mt" ./configure --without-gcc I suggest changing the configure/make files to always include "-mt" if threading is enabled. BTW: The same issue already exists for Python 2.4. Cheers, Ralf -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Feature Requests item #1351692, was opened at 2005-11-08 16:29
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hirota (markhirota)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Switch to make pprint.pprint display ints and longs in hex
Initial Comment:
It would be nice to have some sort of switch or hook to
allow 'pretty-printing' of integers and long integers in
hexidecimal. So, for example:
>>> import pprint
>>> pprint.pprint(range(10)) # instead of this:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> pprint.hexint = True
>>> pprint.pprint(range(10)) # you would get this:
[0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9]
>>> pprint.pprint(range(0x1,0x10010)) #
and this:
[0x1L,
0x10001L,
0x10002L,
0x10003L,
0x10004L,
0x10005L,
0x10006L,
0x10007L,
0x10008L,
0x10009L,
0x1000AL,
0x1000BL,
0x1000CL,
0x1000DL,
0x1000EL,
0x1000FL]
>>>
Thanks,
--MH
--
>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-06 14:13
Message:
Logged In: YES
user_id=6380
IMO yes. Assigning to Anthony for pronouncement (it's a
pretty small feature as features go). Feature freeze isn't
until beta 1 is shipped (although for bigger features we'd
like to see them in, in rough form, sooner, of course).
Anthony, feel free to assign back to Walter to check it in
if you're ok with that.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-04-06 09:02
Message:
Logged In: YES
user_id=89016
Can this still be checked in after 2.5a1 is out the door? It
is a new feature not just a bug fix.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-05 19:11
Message:
Logged In: YES
user_id=6380
What's this waiting for?
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-11-22 15:56
Message:
Logged In: YES
user_id=89016
I think this patch can go in. Any objections from Raymond or
Fred against this?
--
Comment By: Mark Hirota (markhirota)
Date: 2005-11-16 20:04
Message:
Logged In: YES
user_id=1375527
Walter, I agree that there still seems to be an issue with
_format() calling _repr() multiple times, however this
patch seems to enable my feature request using sub-
classing. Can the other issue (which exists presently
also) be ignored for now? Could you submit the patch, or
is that something I should do? Thanks.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-11-16 13:29
Message:
Logged In: YES
user_id=89016
Here's your modified version as a patch against svn HEAD.
(Most of the patch is indentation changes. "svn diff
--diff-cmd diff -x -b Lib/pprint.py" gives this diff:
134d133
< if sepLines:
154a154
> if sepLines:
155a156,157
> else:
> write(', %s: ' % rep)
180a183
> if sepLines:
181a185,186
> else:
> write(', ')
190d194
<
192a197
>
The patch looks good, but it still has a problem that the
original pprint has: For each call to format() the object is
formatted twice, once to determine if it fits on one line
and once for the final output.
--
Comment By: Mark Hirota (markhirota)
Date: 2005-11-14 13:33
Message:
Logged In: YES
user_id=1375527
Did some digging into the code and found that the "if
sepLines:" condition in the PrettyPrinter._format() method
was the source of the limitation.
I've attached a modified version of pprint.py where the "if
sepLines" is more embedded. It gives the following results:
>>> import pprintmod
>>> class MyPrettyPrinter(pprintmod.PrettyPrinter):
def format(self, object, context, maxlevels, level):
if isinstance(object, int):
return hex(object), True,
False
else:
return
pprintmod.PrettyPrinter.format(
self, object,
context, maxlevels, level)
>>> mpp = MyPrettyPrinter()
>>> mpp.pprint(range(10))
[0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9]
>>> mpp.pprint(range(0x1000,0x1010))
[0x1000,
0x1001,
0x1002,
[ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Feature Requests item #1351692, was opened at 2005-11-08 16:29
Message generated for change (Settings changed) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hirota (markhirota)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Switch to make pprint.pprint display ints and longs in hex
Initial Comment:
It would be nice to have some sort of switch or hook to
allow 'pretty-printing' of integers and long integers in
hexidecimal. So, for example:
>>> import pprint
>>> pprint.pprint(range(10)) # instead of this:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> pprint.hexint = True
>>> pprint.pprint(range(10)) # you would get this:
[0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9]
>>> pprint.pprint(range(0x1,0x10010)) #
and this:
[0x1L,
0x10001L,
0x10002L,
0x10003L,
0x10004L,
0x10005L,
0x10006L,
0x10007L,
0x10008L,
0x10009L,
0x1000AL,
0x1000BL,
0x1000CL,
0x1000DL,
0x1000EL,
0x1000FL]
>>>
Thanks,
--MH
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-06 14:13
Message:
Logged In: YES
user_id=6380
IMO yes. Assigning to Anthony for pronouncement (it's a
pretty small feature as features go). Feature freeze isn't
until beta 1 is shipped (although for bigger features we'd
like to see them in, in rough form, sooner, of course).
Anthony, feel free to assign back to Walter to check it in
if you're ok with that.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-04-06 09:02
Message:
Logged In: YES
user_id=89016
Can this still be checked in after 2.5a1 is out the door? It
is a new feature not just a bug fix.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-05 19:11
Message:
Logged In: YES
user_id=6380
What's this waiting for?
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-11-22 15:56
Message:
Logged In: YES
user_id=89016
I think this patch can go in. Any objections from Raymond or
Fred against this?
--
Comment By: Mark Hirota (markhirota)
Date: 2005-11-16 20:04
Message:
Logged In: YES
user_id=1375527
Walter, I agree that there still seems to be an issue with
_format() calling _repr() multiple times, however this
patch seems to enable my feature request using sub-
classing. Can the other issue (which exists presently
also) be ignored for now? Could you submit the patch, or
is that something I should do? Thanks.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-11-16 13:29
Message:
Logged In: YES
user_id=89016
Here's your modified version as a patch against svn HEAD.
(Most of the patch is indentation changes. "svn diff
--diff-cmd diff -x -b Lib/pprint.py" gives this diff:
134d133
< if sepLines:
154a154
> if sepLines:
155a156,157
> else:
> write(', %s: ' % rep)
180a183
> if sepLines:
181a185,186
> else:
> write(', ')
190d194
<
192a197
>
The patch looks good, but it still has a problem that the
original pprint has: For each call to format() the object is
formatted twice, once to determine if it fits on one line
and once for the final output.
--
Comment By: Mark Hirota (markhirota)
Date: 2005-11-14 13:33
Message:
Logged In: YES
user_id=1375527
Did some digging into the code and found that the "if
sepLines:" condition in the PrettyPrinter._format() method
was the source of the limitation.
I've attached a modified version of pprint.py where the "if
sepLines" is more embedded. It gives the following results:
>>> import pprintmod
>>> class MyPrettyPrinter(pprintmod.PrettyPrinter):
def format(self, object, context, maxlevels, level):
if isinstance(object, int):
return hex(object), True,
False
else:
return
pprintmod.PrettyPrinter.format(
self, object,
context, maxlevels, level)
>>> mpp = MyPrettyPrinter()
>>> mpp.pprint(range(10))
[0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9]
>>> mpp.pprint(range(0x1000,0x1010))
[0x1000,
0x1001,
0x1000
[ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1
Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&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: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". -- >Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465646 ] test_grp & test_pwd fail
Bugs item #1465646, was opened at 2006-04-06 12:57 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&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: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. -- >Comment By: Walter Dörwald (doerwalter) Date: 2006-04-06 20:34 Message: Logged In: YES user_id=89016 I'm prepared to throw out the fancy tests from test_pwd.py and test_grp.py. They don't buy us much anyway and basically test more the OS then the Python modules. (For related bugs see #779218, #962226 and #775964.) -- Comment By: Matt Fleming (splitscreen) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=1126061 AFAIK getgrgid() doesn't handle negative integers very well (I can't even add a group with a negative gid on my NetBSD machine). -- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 16:42 Message: Logged In: YES user_id=200117 The test workstation is getting its password and group info from NIS. The test workstation is running Red Hat Linux, but the NIS server is running HPUX 11i. I believe these are the entries causing the errors: lancaster:/etc > ypcat passwd | grep '-' nobody:*:-2:-2::/: lancaster:/etc > ypcat group | grep '-' nogroup:*:-2: -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 15:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). -- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). -- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? -- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). -- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). -- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). -- You can respond by visiting: https://sourceforge.net/trac
[ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1
Bugs item #1465834, was opened at 2006-04-06 17:40 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&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: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". -- >Comment By: Paul Moore (pmoore) Date: 2006-04-06 21:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 19:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? -- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). -- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). -- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-05 00:14 M
[ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit
Bugs item #1061968, was opened at 2004-11-07 09:30 Message generated for change (Comment added) made by midtoad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&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: Threads Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Mark Hammond (mhammond) Summary: threads: segfault or Py_FatalError at exit Initial Comment: I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing. Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete(). My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release(). The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything. Crash. Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks... Boosted to priority 9 because it looks like it should be fixed before 2.4b3. -- Comment By: Stewart Midwinter (midtoad) Date: 2006-04-06 14:38 Message: Logged In: YES user_id=190543 What's the current status of this bug? Did the bug fix make it into 2.4.3? When I run test13.py (attached to one of the notes for this bug) with Python 2.4.3, it does not crash - does that mean that the bug has been fixed? If not, will it be possible to have the fix included in 2.5? thanks Stewart -- Comment By: Armin Rigo (arigo) Date: 2004-12-04 04:46 Message: Logged In: YES user_id=4771 Yes, I double-checked again and I can confirm that the patch of pystate.c rev 2.38 was back-ported to 2.3. Closing the bug report... -- Comment By: Tim Peters (tim_one) Date: 2004-12-02 09:04 Message: Logged In: YES user_id=31435 I may be wrong, but I'm pretty sure Armin already backported all the thread fixes that went into 2.4 (including this one). -- Comment By: Mark Hammond (mhammond) Date: 2004-12-02 00:34 Message: Logged In: YES user_id=14198 OK, I'll take it on for 2.3, but it might be worth reminding me next you get the smell of a new 2.3 release. -- Comment By: Brett Cannon (bcannon) Date: 2004-12-01 23:30 Message: Logged In: YES user_id=357491 Any chance this can get backported to 2.3? -- Comment By: Armin Rigo (arigo) Date: 2004-11-08 07:12 Message: Logged In: YES user_id=4771 It looks fine and I can't reproduce the problem any more. Thanks for the fix! -- Comment By: Tim Peters (tim_one) Date: 2004-11-07 21:32 Message: Logged In: YES user_id=31435 I may not be able to do anything here on Monday, so I checked in the patch, but will leave the report open until Armin can add more info: Misc/NEWS 1.1186 Python/pystate.c 2.38 -- Comment By: Tim Peters (tim_one) Date: 2004-11-07 18:12 Message: Logged In: YES user_id=31435 Thanks, Mark! It's great to get another set of "been there, done that" eyeballs on thread nasties. The symptoms look the same as the ones Guido reported 4 years ago, and there seems to be a clear reason for why they reappeared, so I'm optimistic that fixing it the same way again will work. -- Comment By: Mark Hammond (mhammond) Date: 2004-11-07 15:51 Message: Logged In: YES user_id=14198 Damn - Tim beat me - I missed his comment and came up with an almost identical patch. I could not provoke the error on my RH8 box, so can't offer any more assurance this fixes the underlying bug -- Comment By: Tim Peters (tim_one) Date: 2004-11-07 15:26 Message: Logged In: YES user_id=31435 Back to Armin -- would you please try the attached patch (gilrelease.txt)? I've never been able to provoke this bug, so I can only verify that other tests don't break. -- Comment By: Tim Peters (tim_one) Date: 2004-11-07 12:48 Message: Logged In: YE
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? -- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). -- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 1
[ python-Feature Requests-1465406 ] Allowing the definition of constants
Feature Requests item #1465406, was opened at 2006-04-05 23:30 Message generated for change (Comment added) made by ciw42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&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: None >Status: Open >Resolution: None Priority: 5 Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? -- >Comment By: Chris Wilson (ciw42) Date: 2006-04-06 21:59 Message: Logged In: YES user_id=1018283 I've re-opened this, as I don't feel it would be difficult to implement or require any fundamental changes to the parser or runtime. In fact, it would be very easy, and potentially very useful beyond the scope of my initial suggestion. Appologies to rhettinger if this seems rude, but I would ask that you give the following some consideration. The addition of a "const" or similar compiler directive would allow the compiler to simply do an on-the-fly substitution for the specified value/string etc. There would be no code analysis required, and adding this type of functionality would carry no real overheads or further complicate the compilation process. There would be no changes required within the runtime. Once substituted, the already incorporated compiler constant folding features would then come into play. I suppose, that what I'm suggesting is effectively a basic pre-compiler macro feature. This in itself may prove useful in many other situations. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-05 23:57 Message: Logged In: YES user_id=80475 Python is too dynamic for this kind of optimization to be done automatically. If those "constants" are defined at the module level, they can be changed by code outside the module. Even within the module, it would take a thorough analysis of the code to determine that nothing was trying to alter the value of the global variable. If the "constant" is defined inside a function, it is still a local variable subject to change by later lines in function. Your best bet is to use the bind_consts recipe at ASPN. It will automatically turn some global references into locals: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277 940 It may be possible to adapt the recipe to go an additional step and fold the globals "constants". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit
Bugs item #1061968, was opened at 2004-11-07 11:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&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: Threads Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Mark Hammond (mhammond) Summary: threads: segfault or Py_FatalError at exit Initial Comment: I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing. Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete(). My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release(). The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything. Crash. Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks... Boosted to priority 9 because it looks like it should be fixed before 2.4b3. -- >Comment By: Tim Peters (tim_one) Date: 2006-04-06 19:58 Message: Logged In: YES user_id=31435 midtoad: This bug was closed in December of 2004. The fix was in 2.4 release candidate 1, also in late 2004. It never existed in 2.5. Move along, folks, nothing to see here ;-) -- Comment By: Stewart Midwinter (midtoad) Date: 2006-04-06 16:38 Message: Logged In: YES user_id=190543 What's the current status of this bug? Did the bug fix make it into 2.4.3? When I run test13.py (attached to one of the notes for this bug) with Python 2.4.3, it does not crash - does that mean that the bug has been fixed? If not, will it be possible to have the fix included in 2.5? thanks Stewart -- Comment By: Armin Rigo (arigo) Date: 2004-12-04 06:46 Message: Logged In: YES user_id=4771 Yes, I double-checked again and I can confirm that the patch of pystate.c rev 2.38 was back-ported to 2.3. Closing the bug report... -- Comment By: Tim Peters (tim_one) Date: 2004-12-02 11:04 Message: Logged In: YES user_id=31435 I may be wrong, but I'm pretty sure Armin already backported all the thread fixes that went into 2.4 (including this one). -- Comment By: Mark Hammond (mhammond) Date: 2004-12-02 02:34 Message: Logged In: YES user_id=14198 OK, I'll take it on for 2.3, but it might be worth reminding me next you get the smell of a new 2.3 release. -- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 01:30 Message: Logged In: YES user_id=357491 Any chance this can get backported to 2.3? -- Comment By: Armin Rigo (arigo) Date: 2004-11-08 09:12 Message: Logged In: YES user_id=4771 It looks fine and I can't reproduce the problem any more. Thanks for the fix! -- Comment By: Tim Peters (tim_one) Date: 2004-11-07 23:32 Message: Logged In: YES user_id=31435 I may not be able to do anything here on Monday, so I checked in the patch, but will leave the report open until Armin can add more info: Misc/NEWS 1.1186 Python/pystate.c 2.38 -- Comment By: Tim Peters (tim_one) Date: 2004-11-07 20:12 Message: Logged In: YES user_id=31435 Thanks, Mark! It's great to get another set of "been there, done that" eyeballs on thread nasties. The symptoms look the same as the ones Guido reported 4 years ago, and there seems to be a clear reason for why they reappeared, so I'm optimistic that fixing it the same way again will work. -- Comment By: Mark Hammond (mhammond) Date: 2004-11-07 17:51 Message: Logged In: YES user_id=14198 Damn - Tim beat me - I missed his comment and came up with an almost identical patch. I could not provoke the error on my RH8 box, so can't offer any more assurance this fixes the underlying bug -- Comment By: Tim Peters (tim_one) Date: 2004-11-07 17:26 Message: Lo
[ python-Bugs-1466065 ] base64 module ignores non-alphabet characters
Bugs item #1466065, was opened at 2006-04-07 10:19 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=1466065&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: None Status: Open Resolution: None Priority: 5 Submitted By: Seo Sanghyeon (sanxiyn) Assigned to: Nobody/Anonymous (nobody) Summary: base64 module ignores non-alphabet characters Initial Comment: See: http://mail.python.org/pipermail/python-dev/2006-April/063504.html base64.b64decode function ignores non-alphabet characters, which contradicts its documentation: see http://docs.python.org/lib/module-base64.html Also, the exception must be ValueError instead of TypeError. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466065&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
