[ python-Feature Requests-1491485 ] str.startswith/endswith could take a tuple?
Feature Requests item #1491485, was opened at 2006-05-19 05:24
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.startswith/endswith could take a tuple?
Initial Comment:
In the same way that exceptions can have a tuple of
types specified and isinstance can take a tuple of
types, str.startswith and endswith could take a tuple
of possible prefixes/suffixes.
One use-case::
if filename.endswith(('jpg', 'gif', 'png')):
# ...
vs:
if (filename.endswith('jpg') or filename.endswith
('gif') or
filename.endswith('png')):
#...
Obviously it's not a huge improvement in clarity, but
it does seem to be an improvement to me.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-06-05 11:33
Message:
Logged In: YES
user_id=80475
The previous comment was just information. I am +1 on the
proposal because the use case is so common and the proposed
form is concise, clear, and natural.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-19 15:58
Message:
Logged In: YES
user_id=80475
FWIW, in Py2.5, this would be written:
if any(filename.startswith(s) for s in suffixes):
. . .
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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-1501108 ] Add write buffering to gzip
Feature Requests item #1501108, was opened at 2006-06-05 11:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1501108&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: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add write buffering to gzip Initial Comment: A series of write() calls is dog slow compared to building-up a pool of data and then writing it in larger batches. The attached script demonstrates the speed-up potential. It compares a series of GzipFile.write() calls to an alternate approach using cStringIO.write() calls followed by a GzipFile.write(sio.getvalue()). On my box, there is a three-fold speed-up. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1501108&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501122 ] Lang ref '<' description in 5.9 not consistent with __lt__
Bugs item #1501122, was opened at 2006-06-05 12:10 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=1501122&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: Andy Harrington (andyharrington) Assigned to: Nobody/Anonymous (nobody) Summary: Lang ref '<' description in 5.9 not consistent with __lt__ Initial Comment: >From the reference manual section 5.9: "The operators <, >, ==, >=, <=, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, objects of different types always compare unequal, and are ordered consistently but arbitrarily." The last sentence may apply to built-in types, but '<' may be evaluated via __lt__ for user defined types, and there are no such restrictions as I read the documentation. If this section is only referring to built-in types it shuld be clearly stated. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501122&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470026 ] distutils.core: link to list of Trove classifiers
Bugs item #1470026, was opened at 2006-04-13 15:13 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470026&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ansel Halliburton (anseljh) >Assigned to: A.M. Kuchling (akuchling) Summary: distutils.core: link to list of Trove classifiers Initial Comment: In 10.1 (distutils.core), it would be nice to have a link to the full list of Trove classifiers. There is already a place for such a link in the table for the setup() method; search for "XXX link to better definition". Here is the link to add: http://www.python.org/pypi?:action=list_classifiers I would say "a list of strings; see http://www.python.org/pypi?:action=list_classifiers for a list of all possible values" -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-05 15:10 Message: Logged In: YES user_id=11375 Thanks for pointing this out. I've added a link to the classifier list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470026&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501223 ] Possible buffer overflow in Python/sysmodule.c
Bugs item #1501223, was opened at 2006-06-05 13:45 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=1501223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Possible buffer overflow in Python/sysmodule.c Initial Comment: Line 1070 (along with lines 1075 and 1080) have sprintf() calls that store "cp%d" into a buffer that is 10 characters long. But an unsigned int could be 32 bits, which means 10 digits on its own. Add in the need for a null byte and the "cp" part and it would seem the buffer is 3 characters short. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501223 ] Possible buffer overflow in Python/sysmodule.c
Bugs item #1501223, was opened at 2006-06-05 16:45 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Possible buffer overflow in Python/sysmodule.c Initial Comment: Line 1070 (along with lines 1075 and 1080) have sprintf() calls that store "cp%d" into a buffer that is 10 characters long. But an unsigned int could be 32 bits, which means 10 digits on its own. Add in the need for a null byte and the "cp" part and it would seem the buffer is 3 characters short. -- >Comment By: Tim Peters (tim_one) Date: 2006-06-05 17:02 Message: Logged In: YES user_id=31435 So make it bigger ;-) In reality, I don't believe any Windows "code page" needs more than 5 digits, so there are actually a couple bytes to spare, but boosting the buffer size wouldn't hurt. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1493322 ] bsddb: db never opened for writing forgets its size
Bugs item #1493322, was opened at 2006-05-22 19:30 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Gregory P. Smith (greg) Summary: bsddb: db never opened for writing forgets its size Initial Comment: See the attached program; on my machine, its output is as described therein. That is: if a bsddb hash database is opened read-only, and has never been opened for writing (except when first created), then calling len() on the database object returns the correct value the first time, but zero on the second and later calls. Opening the database for writing once seems to eliminate the problem; even when it is opened read-only later, len() behaves as expected. My machine runs Linux 2.6.16, glibc 2.3.4, Python 2.4.3, and Berkeley DB 4.3.28. -- >Comment By: Gregory P. Smith (greg) Date: 2006-06-05 14:49 Message: Logged In: YES user_id=413 this sounds the same as pybsddb bug 1184012. i'm looking into it. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-22 22:47 Message: Logged In: YES user_id=33168 Greg, is this a known issue? Any ideas? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended ascii
Bugs item #1501291, was opened at 2006-06-05 16:34
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=1501291&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: UnixOps (unixops1234)
Assigned to: Nobody/Anonymous (nobody)
Summary: python/ncurses bug in 2.4.3 with extended ascii
Initial Comment:
There is a problem displaying extended ascii characters
in ncurses through python, which does not exist in
versions prior to 2.4.2. I am running RedHat Enterprise
Linux WS 3 with updated patches, using the system
version of ncurses (ncurses-5.3-9.4 and devel). When
building a vanilla python 2.4.3 from source, printing
extended ascii characters in ncurses fails:
$ cat test.py
import curses
screen = curses.initscr()
screen.addstr("\x80")
screen.getch()
curses.endwin()
$ python test.py
Traceback (most recent call last):hon test.py
File "test.py", line 5, in ?
screen.addstr("\x80")
_curses.error: addstr() returned ERR
This should produce a blank ncurses screen, rather than
the addstr() error. I've been able to confirm that it
works with python 2.4.2 and earlier.
To ensure that ncurses was able to display the
character, I wrote this test C program:
$ cat test.c
#include
int main()
{
initscr();
int rtn = addstr("\x80");
getch();
endwin();
printf("The return value was %d.\n",rtn);
return 0;
}
$ gcc test.c -o test -lncurses
$ ./test
This works just fine, so I think the problem lies
somewhere in the python interface to ncurses. Python
can print this character without errors when not using
ncurses. Perhaps ncurses is expecting different
initialization than python is providing.
I've also tested this on a RedHat WS 4 machine, where
it works just fine. This system is running
ncurses-5.4-13 and ncurses-devel-5.4-13. It seems the
newer release of python has changed something that the
older versions of ncurses are unable to handle.
Can this be fixed in _cursesmodule.c?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501223 ] Possible buffer overflow in Python/sysmodule.c
Bugs item #1501223, was opened at 2006-06-05 13:45 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Possible buffer overflow in Python/sysmodule.c Initial Comment: Line 1070 (along with lines 1075 and 1080) have sprintf() calls that store "cp%d" into a buffer that is 10 characters long. But an unsigned int could be 32 bits, which means 10 digits on its own. Add in the need for a null byte and the "cp" part and it would seem the buffer is 3 characters short. -- >Comment By: Brett Cannon (bcannon) Date: 2006-06-05 16:58 Message: Logged In: YES user_id=357491 OK, I will! =) Just had to wait until I had time at work to do it. HEAD for rev. 46682 and for 2.4 there is rev. 46683 has the buffer increase. -- Comment By: Tim Peters (tim_one) Date: 2006-06-05 14:02 Message: Logged In: YES user_id=31435 So make it bigger ;-) In reality, I don't believe any Windows "code page" needs more than 5 digits, so there are actually a couple bytes to spare, but boosting the buffer size wouldn't hurt. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1493322 ] bsddb: db never opened for writing forgets its size
Bugs item #1493322, was opened at 2006-05-22 19:30 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&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.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Gregory P. Smith (greg) Summary: bsddb: db never opened for writing forgets its size Initial Comment: See the attached program; on my machine, its output is as described therein. That is: if a bsddb hash database is opened read-only, and has never been opened for writing (except when first created), then calling len() on the database object returns the correct value the first time, but zero on the second and later calls. Opening the database for writing once seems to eliminate the problem; even when it is opened read-only later, len() behaves as expected. My machine runs Linux 2.6.16, glibc 2.3.4, Python 2.4.3, and Berkeley DB 4.3.28. -- >Comment By: Gregory P. Smith (greg) Date: 2006-06-05 17:00 Message: Logged In: YES user_id=413 fixed in python svn rev 46684. i'll backport this one to python 2.4 as well. -- Comment By: Gregory P. Smith (greg) Date: 2006-06-05 14:49 Message: Logged In: YES user_id=413 this sounds the same as pybsddb bug 1184012. i'm looking into it. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-22 22:47 Message: Logged In: YES user_id=33168 Greg, is this a known issue? Any ideas? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1477450 ] test_bsddb skipped -- Failed to load on HP-UX 11.2i
Bugs item #1477450, was opened at 2006-04-27 00:07 Message generated for change (Settings changed) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&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.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) >Summary: test_bsddb skipped -- Failed to load on HP-UX 11.2i Initial Comment: Hi , Iam building Python-2.4.3 on HP-UX 11.2i , while testing its npt able import the _bsddb.sl module and hence that is skipped . In previous versions the test is passing. what can be done to pass the test?. Thanks, shashi -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-27 21:45 Message: Logged In: YES user_id=33168 Support for db-4.4 was added late. I believe the only thing you need to do to enable it is modify setup.py, line 496 (proabably that line) should be: max_db_ver = (4, 4) >From what I've seen, you are much better off with newer versions of bdb. As for the seg faults, I wonder if your ulimits are too low. What is the output of: ulimit -a Also, can you attach the output of ./python Lib/test/regrtest.py -v -u bsddb test_subprocess and do the same for test_bsddb3 (or test_bsddb whichever is crashing). -- Comment By: shashi (shashikala) Date: 2006-04-27 21:35 Message: Logged In: YES user_id=1506183 Hi, I am having db-4.4.20 installed, It looks like Python doesn't support 4.4.20 version , hence i built 4.2.52 , now I am getting segmentation fault (memory fault) and its dumping core . I want to know the versions of the dependent libraries Python-2.4.3 supports and also while testing the Python test_subprocess.py is also dumping core. I am sending out the outputs of test_bsddb and test_subprocess. Thanks, shashi -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-27 20:11 Message: Logged In: YES user_id=33168 The test can't pass without being able to import _bsddb.sl. Why can't this file be imported? When you build python it should print out what version of bsddb is found. It will look something like this: running build running build_ext db.h: found (4, 1) in /usr/include db lib: using (4, 1) db-4.1 What version of bsddb was found on your box? Are there compile errors when building bsddb? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&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-1497532 ] C API to retain GIL during Python Callback
Feature Requests item #1497532, was opened at 2006-05-30 14:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1497532&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: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: C API to retain GIL during Python Callback Initial Comment: [Split off from closed 1453341, which desired a Python- level API. This request is for a C API, to be used in C extensions that call back into Python.] I think it would be very useful to have an API that would tell Python not to release the GIL during call backs to Python code, until it is told again (back in C code) that it is ok to do so. I'd like to quote Tim Peters, who explains it better than me (private conversation, June 2005): -- It would be more feasible to patch Python, introducing a way to tell the interpreter not to allow other _Python_ threads to run. It has such a mechanism already (the GIL -- the global interpreter lock), but as soon as C code calls back into Python, the interpreter may release the GIL and give ownership of it to a different thread. I think it would be pretty easy to introduce a Python C API to say "don't allow other Python threads to run until I tell you otherwise". -- The Use Case arose with a multi-threading problem in ZODB's Connection, where the C code must ensure that no other thread runs Python code accessing an object BUT the own thread needs to call back into Python. Any other mechanism that came to my mind would either require to halt *all* others threads, or run into race conditions. Best regards, Martin Gfeller -- >Comment By: Martin v. Löwis (loewis) Date: 2006-06-05 12:52 Message: Logged In: YES user_id=21627 Would you like to work on a patch for that? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1497532&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501330 ] failure of test_ossaudiodev; elapsed time .1 sec faster
Bugs item #1501330, was opened at 2006-06-05 17:23 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=1501330&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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: failure of test_ossaudiodev; elapsed time .1 sec faster Initial Comment: I am getting a consistent failure of test_ossaudiodev on Ubuntu Hoary on an HP xw4300 Workstation. The failure is that the test is printing out "elapsed time: 3.0 sec" while the test expects 3.1 sec. I don't know anything about sound recordings so I don't know if there is any way to calculate the expected length of the test sound file and thus know that this is a true error or the test is just working faster than normally expected. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&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-1491485 ] str.startswith/endswith could take a tuple?
Feature Requests item #1491485, was opened at 2006-05-19 05:24
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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: Tom Lynn (tlynn)
>Assigned to: Georg Brandl (gbrandl)
Summary: str.startswith/endswith could take a tuple?
Initial Comment:
In the same way that exceptions can have a tuple of
types specified and isinstance can take a tuple of
types, str.startswith and endswith could take a tuple
of possible prefixes/suffixes.
One use-case::
if filename.endswith(('jpg', 'gif', 'png')):
# ...
vs:
if (filename.endswith('jpg') or filename.endswith
('gif') or
filename.endswith('png')):
#...
Obviously it's not a huge improvement in clarity, but
it does seem to be an improvement to me.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-06-05 19:30
Message:
Logged In: YES
user_id=80475
Georg, would you like to implement this one?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-06-05 11:33
Message:
Logged In: YES
user_id=80475
The previous comment was just information. I am +1 on the
proposal because the use case is so common and the proposed
form is concise, clear, and natural.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-19 15:58
Message:
Logged In: YES
user_id=80475
FWIW, in Py2.5, this would be written:
if any(filename.startswith(s) for s in suffixes):
. . .
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
