[ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work
Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&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: Tkinter Group: Python 2.5 >Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. Löwis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. -- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-22 12:50 Message: Logged In: YES user_id=1597584 Originator: YES may i open it again? there is a lot of builds on solaris without the core development environment, so assuming it is there is erronous. e.g. we build everything with standard gnu from e.g. sunfreeware.com. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-19 09:15 Message: Logged In: YES user_id=21627 Originator: NO Closing as "won't fix". There are no plans to implement --disable-sunaudiodev --disable-tk options to configure. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-02
[ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically
Bugs item #1600860, was opened at 2006-11-22 01:29
Message generated for change (Comment added) made by marienz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: --enable-shared links extensions to libpython statically
Initial Comment:
python 2.5 tries to link extension modules to libpython2.5 if python is
compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do
this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command
line. -lpython2.5 is fine, however the "config" directory it adds contains a
static libpython2.5.a library. The libpython2.5.so I think it should be linking
to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly)
all of that library, so you get an extension that is over a megabyte in size
where older pythons produce one of a few kilobytes.
There is a comment on the referenced bug saying
"""
You can probably rely on libpythonxy.so ending up in
$(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can
retrieve from the installed Makefile (i.e. through
distutils.config).
"""
so I think the patch that got applied does not do what was intended.
--
>Comment By: Marien Zwart (marienz)
Date: 2006-11-22 14:02
Message:
Logged In: YES
user_id=857292
Originator: YES
I can reproduce this by using either gentoo's python 2.5 or one I
installed temporarily with ./configure --enable-shared --prefix
$HOME/tmp/pytem, using a trivial distutils extension (I used
http://dev.gentooexperimental.org/~marienz/ext.c and
http://dev.gentooexperimental.org/~marienz/setup.py for testing). The
relevant command that is run is:
gcc -pthread -shared build/temp.linux-i686-2.5/ext.o
-L/home/marienz/tmp/pytem/lib/python2.5/config -lpython2.5 -o
build/lib.linux-i686-2.5/ext.so
for the manually-configured python and something similar for gentoo's
python. The code doing the adding was added by r45232 in svn. From the
diff (svn di -r45231:45232
http://svn.python.org/projects/python/trunk/Lib/distutils/command/build_ext.py)
with some extra context added:
-if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos':
+if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos'
or \
+ (sys.platform.startswith('linux') and
+sysconfig.get_config_var('Py_ENABLE_SHARED')):
if string.find(sys.executable, sys.exec_prefix) != -1:
# building third party extensions
self.library_dirs.append(os.path.join(sys.prefix, "lib",
"python" +
get_python_version(),
"config"))
(that is around line 188 of Lib/distutils/command/build_ext.py)
sys.platform on this host is linux2 and as far as I can tell
Py_ENABLE_SHARED is true if --enable-shared is passed to configure.
If you need any more information please ask.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-22 08:09
Message:
Logged In: YES
user_id=21627
Originator: NO
I can't reproduce the problem. Why do you think
-L$PREFIX/lib/python2.5/config is added to the link command line? AFAICT,
it never is.
What operating system are you using?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&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-1185383 ] Make bisect.* functions accept an optional compare function
Feature Requests item #1185383, was opened at 2005-04-18 19:26 Message generated for change (Comment added) made by minmax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&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: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Marcin Ciura (mciura) Assigned to: Nobody/Anonymous (nobody) Summary: Make bisect.* functions accept an optional compare function Initial Comment: The usability of bisect.bisect_right, bisect.bisect_left, bisect.insort_right and bisect.insort_left would increase if they accepted an optional less_than function to compare the keys. Here is my use case: I have a sorted list of reversed words and a parallel list of flags associated with these words (taken from ispell). The list of reversed words is the one searched; the flags are the result of a search. Issue #1: Now I cannot use simply a list of tuples (rev_word,flags) and a custom less_than function that compares only the first elements of two tuples. Issue #2: When a word is not found in the list, I'd like to make an educated guess as to its flags (this makes more sense in non-English languages, where e.g. infinitives have a special ending), using bisect_left and bisect_right: from bisect import * less_than = lambda x,y: x[:3] [...] but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). > Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Which is exactly *why* I'm suggesting the key argument: to save those extra calls to the key function. Since that sounds counter-intuitive, let me explain: one sorts (origkey(item), item) pairs, the bisects with key=itemgetter(0), not calling the expensive origkey. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 01:25 Message: Logged In: YES user_id=80475 Overall, I'm -1 on this RFE. The comparison to nsmallest() and nlargest() is inaccurate. They run start-to-finish in one function call. The other heapq methods do not use key functions because they have to leave the original data structure unmolested between calls; hence, there is no ability to limit the key function calls to one per record. Likewise, with this request, the key function calls get wasted. The sort() method calls key() for every record and tosses the result afterwards. Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Hence, accepting this request would create an API that encourages a wasteful design. -- Comment By: Jonas K�lker (jonaskoelker) Date: 2005-04-28 20:13 Message: Logged In: YES user_id=1153395 In a similar vein, I'd like to see that a `key' keyword argument was added to bisect.* (and perhaps `reversed' too)--it's really annoying to sort something by (not __lt__) and not be able to bsearch it. It got added to min/max and heapq.n(smallest|largest) in 2.5 fwiw ;) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 20:09 Message: Logged In: YES user_id=80475 A few thoughts: * If bisect provided an optional lt argument, it would still not be thread-safe. The code for the lt function can call arbitrary Python code that runs through the eval-loop and is hence subject to a thread-switch. * An advantage of the class wrapper approach is that the prefix function gets computed just once per word. This is not a big deal for the specific case of [:3], but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). * My own approach to the particular use case would be to map prefixes to a list of revwords or (revword, flag) pairs: d = dict(abb=['abbc'], abc=['abcaa', 'abcdd', 'abcss'], abd=['abdf']) This gives O(1) lookup time and limits the calls to the prefix function to once per word. Will leave this request open as it may yet be a good idea. My concern is that it will clutter the code and the API for only a small benefit. Also, I'm looking at a more general purpose solution that would make this feature request moot. This idea is to create a fast comparison decorator class used like this: dwordlist = map(ComparisonDecorator(lambda x: x[:3]), wordlist) lp = bisect_left(dwordlist, given_rev_word) rp = bisect_right(dwordlist, given_rev_word) -- You can respond by visiting: https://sourceforge.net/tr
[ python-Bugs-1571754 ] Building using Sleepycat db 4.5.20 is broken
Bugs item #1571754, was opened at 2006-10-05 21:31 Message generated for change (Comment added) made by juedau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571754&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: 5 Private: No Submitted By: Robert Scheck (robert-scheck) Assigned to: Nobody/Anonymous (nobody) Summary: Building using Sleepycat db 4.5.20 is broken Initial Comment: Using latest Sleepycat db 4.5.20, I'm getting the following result during make of python 2.5: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -fPIC - DPy_BUILD_CORE -I/usr/include/db4 -c ./Modules/_bsddb. c -o Modules/_bsddb.o ./Modules/_bsddb.c: In function 'DBEnv_set_lk_max': ./Modules/_bsddb.c:4142: error: 'DB_ENV' has no member named 'set_lk_max' ./Modules/_bsddb.c: In function 'init_bsddb': ./Modules/_bsddb.c:5838: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:5838: error: (Each undeclared identifier is reported only once ./Modules/_bsddb.c:5838: error: for each function it appears in.) ./Modules/_bsddb.c:5873: error: 'DB_RECORDCOUNT' undeclared (first use in this function) make: *** [Modules/_bsddb.o] Error 1 -- Comment By: sdkfsdf (juedau) Date: 2006-11-22 19:15 Message: Logged In: YES user_id=1627035 Originator: NO Didn't work for me. Sure, _bsddb.so can be linked against db 4.5.20 with your patch, but some of the tests from bsddb/test are crashing. Seems that we have to wait for official support. Tested with Python 2.5. -- Comment By: Robert Scheck (robert-scheck) Date: 2006-10-07 19:11 Message: Logged In: YES user_id=203809 The attached patches are solving the problems for me and should be the correct fix when reading Sleepycat's upgrade documentation... -- Comment By: Robert Scheck (robert-scheck) Date: 2006-10-05 21:34 Message: Logged In: YES user_id=203809 Ah, python 2.4.3 has the same problem plus further errors: ./Modules/_bsddb.c: In function 'DB_length': ./Modules/_bsddb.c:2453: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:2453: error: (Each undeclared identifier is reported only once ./Modules/_bsddb.c:2453: error: for each function it appears in.) ./Modules/_bsddb.c: In function 'DBEnv_set_lk_max': ./Modules/_bsddb.c:3811: error: 'DB_ENV' has no member named 'set_lk_max' ./Modules/_bsddb.c: In function 'init_bsddb': ./Modules/_bsddb.c:5004: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:5039: error: 'DB_RECORDCOUNT' undeclared (first use in this function) make: *** [Modules/_bsddb.o] Error 1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571754&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1601399 ] urllib2 does not close sockets properly
Bugs item #1601399, was opened at 2006-11-23 08:04
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=1601399&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
Private: No
Submitted By: Brendan Jurd (direvus)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 does not close sockets properly
Initial Comment:
Python 2.5 (release25-maint, Oct 29 2006, 12:44:11)
[GCC 4.1.2 20061026 (prerelease) (Debian 4.1.1-18)] on linux2
I first noticed this when a program of mine (which makes a brief HTTPS
connection every 20 seconds) started having some weird crashes. It turned out
that the process had a massive number of file descriptors open. I did some
debugging, and it became clear that the program was opening two file
descriptors for every HTTPS connection it made with urllib2, and it wasn't
closing them, even though I was reading all data from the response objects and
then explictly calling close() on them.
I found I could easily reproduce the behaviour using the interactive console.
Try this while keeping an eye on the file descriptors held open by the python
process:
To begin with, the process will have the usual FDs 0, 1 and 2 open for
std(in|out|err), plus one other.
>>> import urllib2
>>> f = urllib2.urlopen("http://www.google.com";)
Now at this point the process has opened two more sockets.
>>> f.read()
[... HTML ensues ...]
>>> f.close()
The two extra sockets are still open.
>>> del f
The two extra sockets are STILL open.
>>> f = urllib2.urlopen("http://www.python.org";)
>>> f.read()
[...]
>>> f.close()
And now we have a total of four abandoned sockets open.
It's not until you terminate the process entirely, or the OS (eventually)
closes the socket on idle timeout, that they are closed.
Note that if you do the same thing with httplib, the sockets are properly
closed:
>>> import httplib
>>> c = httlib.HTTPConnection("www.google.com", 80)
>>> c.connect()
A socket has been opened.
>>> c.putrequest("GET", "/")
>>> c.endheaders()
>>> r = c.getresponse()
>>> r.read()
[...]
>>> r.close()
And the socket has been closed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601399&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work
Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&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: Tkinter Group: Python 2.5 Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. Löwis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-22 22:53 Message: Logged In: YES user_id=21627 Originator: NO You still haven't demonstrated a problem. Compiling Python produces some error messages, sure, but does the resulting Python binary actually work or not? If it works, what is the problem? That you appreciate not to see error messages does not make it a bug. You cannot build Python *at all* with just the standard gnu from sunfreeware.com. You do need system header files, and those are not provided by GCC. So if you have header files, where did you get them from? -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-22 12:50 Message: Logged In: YES user_id=1597584 Originator: YES may i open it again? there is a lot of builds on solaris without the core development environment, so assuming it is there is erronous. e.g. we build everything with standard gnu from e.g. sunfreeware.com. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-19 09:15 Message: Logged In: YES user_id=21627 Originator: NO Closing as "won't fix". There are no plans to implement --disable-sunaudiodev --disable-tk options to configure. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python?
[ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input
Bugs item #1601501, was opened at 2006-11-23 02:38
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=1601501&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
Private: No
Submitted By: bazwal (bazwal)
Assigned to: Nobody/Anonymous (nobody)
Summary: utf_8_sig decode fails with buffer input
Initial Comment:
when the decode function in encodings.utf_8_sig receives a buffer object, it
fails because it tries to check for a bom using startswith:
>>> unicode('\xef\xbb\xbf', 'utf_8_sig')
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode
if input.startswith(codecs.BOM_UTF8):
AttributeError: 'buffer' object has no attribute 'startswith'
the test should be changed to:
if input[:3] == codecs.BOM_UTF8:
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input
Bugs item #1601501, was opened at 2006-11-23 03:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&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
Private: No
Submitted By: bazwal (bazwal)
Assigned to: Nobody/Anonymous (nobody)
Summary: utf_8_sig decode fails with buffer input
Initial Comment:
when the decode function in encodings.utf_8_sig receives a buffer object, it
fails because it tries to check for a bom using startswith:
>>> unicode('\xef\xbb\xbf', 'utf_8_sig')
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode
if input.startswith(codecs.BOM_UTF8):
AttributeError: 'buffer' object has no attribute 'startswith'
the test should be changed to:
if input[:3] == codecs.BOM_UTF8:
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2006-11-23 05:00
Message:
Logged In: YES
user_id=89016
Originator: NO
Can you provide a test that fails?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input
Bugs item #1601501, was opened at 2006-11-23 03:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&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
Private: No
Submitted By: bazwal (bazwal)
Assigned to: Nobody/Anonymous (nobody)
Summary: utf_8_sig decode fails with buffer input
Initial Comment:
when the decode function in encodings.utf_8_sig receives a buffer object, it
fails because it tries to check for a bom using startswith:
>>> unicode('\xef\xbb\xbf', 'utf_8_sig')
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode
if input.startswith(codecs.BOM_UTF8):
AttributeError: 'buffer' object has no attribute 'startswith'
the test should be changed to:
if input[:3] == codecs.BOM_UTF8:
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2006-11-23 06:04
Message:
Logged In: YES
user_id=89016
Originator: NO
Oops, I missed your stacktrace. Fixed in r52826.
(A better fix might be to add startswith() to buffer).
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-11-23 05:00
Message:
Logged In: YES
user_id=89016
Originator: NO
Can you provide a test that fails?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input
Bugs item #1601501, was opened at 2006-11-23 03:38
Message generated for change (Settings changed) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&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: Accepted
Priority: 5
Private: No
Submitted By: bazwal (bazwal)
Assigned to: Nobody/Anonymous (nobody)
Summary: utf_8_sig decode fails with buffer input
Initial Comment:
when the decode function in encodings.utf_8_sig receives a buffer object, it
fails because it tries to check for a bom using startswith:
>>> unicode('\xef\xbb\xbf', 'utf_8_sig')
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode
if input.startswith(codecs.BOM_UTF8):
AttributeError: 'buffer' object has no attribute 'startswith'
the test should be changed to:
if input[:3] == codecs.BOM_UTF8:
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-11-23 06:04
Message:
Logged In: YES
user_id=89016
Originator: NO
Oops, I missed your stacktrace. Fixed in r52826.
(A better fix might be to add startswith() to buffer).
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-11-23 05:00
Message:
Logged In: YES
user_id=89016
Originator: NO
Can you provide a test that fails?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input
Bugs item #1601501, was opened at 2006-11-23 03:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&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: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: bazwal (bazwal)
Assigned to: Nobody/Anonymous (nobody)
Summary: utf_8_sig decode fails with buffer input
Initial Comment:
when the decode function in encodings.utf_8_sig receives a buffer object, it
fails because it tries to check for a bom using startswith:
>>> unicode('\xef\xbb\xbf', 'utf_8_sig')
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode
if input.startswith(codecs.BOM_UTF8):
AttributeError: 'buffer' object has no attribute 'startswith'
the test should be changed to:
if input[:3] == codecs.BOM_UTF8:
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2006-11-23 06:06
Message:
Logged In: YES
user_id=89016
Originator: NO
Fixed in r52827 for the 2.5 branch
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-11-23 06:04
Message:
Logged In: YES
user_id=89016
Originator: NO
Oops, I missed your stacktrace. Fixed in r52826.
(A better fix might be to add startswith() to buffer).
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-11-23 05:00
Message:
Logged In: YES
user_id=89016
Originator: NO
Can you provide a test that fails?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
