[issue1910] Document that with is slower than try/finally
Changes by Jeffrey Yasskin: -- nosy: +jyasskin __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so
Eh Tan added the comment: According to gdbm NEW, the dbm/ndbm compatibility routines was moved to libgdbm_compat in v1.8.1, which was released in late 2002. The patch works for gdbm-1.8.1+. But I am afraid that the patch will cause build error with gdbm-1.8.0 and earlier version. A more sophisticated approach is needed. The approach will do the following: 1. find gdbm library and gdbm/ndbm.h header 2. check the presence of dbm_open() function in gdbm library 3. if present, link with gdbm 4. if not, link with gdbm_compat Step 1 and 3 are already in setup.py. The patch adds step 4, but step 2 is missing. I don't have enough skill in distutil to implement it though... -- nosy: +tan2 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1167 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Eh Tan added the comment: The problem is at line 890, setup.py, r60970. sqlite_libfile = self.compiler.find_library_file( sqlite_dirs_to_check + lib_dirs, 'sqlite3') sqlite_libdir = [os.path.abspath(os.path.dirname(sqlite_libfile))] self.compiler.find_library_file() will return None if the library is not found. The code passes None to os.path.dirname and cause the error. -- nosy: +tan2 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706863 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2168] gdbm needs to be iterable
Changes by Thomas Herve: -- keywords: +patch Added file: http://bugs.python.org/file9531/dbm.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2168 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Raymond Hettinger added the comment: FWIW, we don't usually document relative speeds (or even O(n) performance). Those things are implementation dependent and can vary across releases. In the case of the with-statement, it would seem self-evident that with does everything try/finally does and adds function call overhead, the __enter__/__exit dance, and possibly introducing a locally scoped variable with the as clause. -- status: pending - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2168] gdbm needs to be iterable
Changes by Thomas Herve: Added file: http://bugs.python.org/file9532/gdbm.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2168 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2168] gdbm needs to be iterable
Thomas Herve added the comment: Attached files add contains method to dbm and gdbm objects. It fixes failures with test_shelve. I'm ready to add more tests for this, but #1960 should probably go in first (it converts the tests to unittest, and add some coverage). Please review! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2168 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2168] gdbm needs to be iterable
Raymond Hettinger added the comment: The patch looks good to my eye, but I can't test it directly. Will apply and see what the buildbots think about it. -- nosy: +rhettinger priority: - high __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2168 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2168] gdbm needs to be iterable
Changes by Raymond Hettinger: -- assignee: - rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2168 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2173] Pyton fails silently on bad locale
New submission from Michael Otteneder: Python seems to fail silently when LANG enviroment variable is set to a bad value. In Mac OS X Leopard it is set too UTF-8 for instance which does not seem to be valid. Python fails building the modules during make and the generated python.exe is unable to output anything. Setting the LANG variable to C or some other valid value fixes the problem. But I suppose python should fail more verbose in case of a bad locale,or maybe it should fallback to a standard locale. -- components: Interpreter Core messages: 62892 nosy: motteneder severity: normal status: open title: Pyton fails silently on bad locale type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2173 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Virgil Dupras added the comment: The documentation doesn't say anything about dircmp being supposed to support pattern matching. This ticket is a feature request rather than a bug. -- components: +Library (Lib) -None nosy: +vdupras type: behavior - feature request __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1738 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue841728] urllib and cookie module improvements
John J Lee added the comment: This should be closed. Tracker [EMAIL PROTECTED] http://bugs.python.org/issue841728 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Antoine Pitrou added the comment: Hi Alexander, 5% is a lot and IIRC os.times is used by some standard python profilers and 5% slowdown will affect people. Profiled runs are always slower than non-profiled runs, so I'm not convinced it is very important. You use profiling only when you need it, not in normal production conditions. However, fetching the value only once and then caching it is a valid approach, so you can produce an updated patch for that if you want :-) _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1729305] test_doctest fails when run in verbose mode
Mike Beachy added the comment: The basic issue here is that running in verbose mode echoes back the expected values from the file, so the results from non-ascii doctest files must be encoded before printing. It looks to me like the DocTestRunner class must grow an '_encoding' attribute to keep track of how to encode any verbose output. I've attached a patch that does this. Happy post bug day! Mike -- keywords: +patch nosy: +mbeachy Added file: http://bugs.python.org/file9533/doctest.patch _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1729305 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1729305] test_doctest fails when run in verbose mode
Mike Beachy added the comment: Here's a patch for test_doctest.py that checks the problem has been fixed. Added file: http://bugs.python.org/file9534/test_doctest.patch _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1729305 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Rafael Zanella added the comment: According to the documentation (http://docs.python.org/dev/library/functions.html) The arguments must be plain integers, so I think the wrong thing here is to run the object's __int__() under the range()'s hood. I think the right thing to do would be to explicitly invoke int() on passing an non-int argument as parameter. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1533 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1657] [patch] epoll and kqueue wrappers for the select module
Christian Heimes added the comment: I've updated the patch. The latest patch didn't contain the unit tests and it failed to apply cleanly, too. Added file: http://bugs.python.org/file9535/trunk_select_epoll_kqueue9.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1657] [patch] epoll and kqueue wrappers for the select module
Changes by Christian Heimes: Removed file: http://bugs.python.org/file9019/trunk_select_epoll_kqueue5.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1657] [patch] epoll and kqueue wrappers for the select module
Changes by Christian Heimes: Removed file: http://bugs.python.org/file9029/trunk_select_epoll_kqueue7.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1657] [patch] epoll and kqueue wrappers for the select module
Changes by Christian Heimes: Removed file: http://bugs.python.org/file9027/trunk_select_epoll_kqueue6.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1657] [patch] epoll and kqueue wrappers for the select module
Changes by Christian Heimes: Removed file: http://bugs.python.org/file9241/trunk_select_epoll_kqueue8.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2174] xml.sax.xmlreader does not support the InputSource protocol
New submission from Yitz Gale: In the documentation for xml.sax.xmlreader.InputSource objects (section 8.12.4 of the Library Reference) we find that users of InputSource objects should use the following sequence to get their input data: 1. If the InputSource has a character stream, use that. 2. Otherwise, if the InputSource has a byte stream, use that. 3. Otherwise, open a URI connection to the system ID. The parse() method of IncrementalParser skips step 1. In addition, we need to add a method getSourceEncoding() to the XMLReader interface; if non-null, it will indicate to the parser that the input is a byte stream in the given encoding. The documentation should indicate what the parser should do if the XML itself announces that its encoding is something else. I propose that the parser should be required to raise an error in that case. See also #1483. -- components: Documentation, Library (Lib), XML messages: 62900 nosy: ygale severity: normal status: open title: xml.sax.xmlreader does not support the InputSource protocol type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2174 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2175] Expat sax parser silently ignores the InputSource protocol
New submission from Yitz Gale: The expat sax parser in xml.sax.expatreader does not fully support the InputSource protocol in xml.sax.xmlreader. It only accepts byte streams. It ignores the encoding indicated in the InputStream object and only uses the encoding read from the XML or defaults to UTF-8. Rather than silently doing the wrong thing, it should raise an error when fed a character stream, or when given an encoding, via the InputSource interface. And most importantly, these limitations should be mentioned in the documentation. -- components: Documentation, Extension Modules, Library (Lib), Unicode, XML messages: 62901 nosy: ygale severity: normal status: open title: Expat sax parser silently ignores the InputSource protocol type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2175 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2176] Undocumented lastrowid attribute i sqlite3 cursor class
Changes by Jakub Fedyczak: -- components: Documentation nosy: bukaj severity: normal status: open title: Undocumented lastrowid attribute i sqlite3 cursor class versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2176 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2175] Expat sax parser silently ignores the InputSource protocol
Yitz Gale added the comment: See also: #1483 and #2174. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2175 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2174] xml.sax.xmlreader does not support the InputSource protocol
Yitz Gale added the comment: See also: #1483 and #2175. -- components: +Unicode __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2174 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1306] Embedded python reinitialization
Christian Heimes added the comment: I've fixed the bug in Python 3.0 a few weeks ago. I'm not sure about the stackless bug but this is the wrong place to report it. Please contact the other Christian. -- resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1306 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2176] Undocumented lastrowid attribute i sqlite3 cursor class
New submission from Jakub Fedyczak: con = sqlite3.connect(file) c = con.cursor() c.execute(INSERT INTO .) last_id = c.lastrowid --- nothing about it in the docs __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2176 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2174] xml.sax.xmlreader does not support the InputSource protocol
Yitz Gale added the comment: Hmm. When getSourceEncoding() is None, there needs to be some way for the parser to distinguish between the cases where it is getting pre-decoded Unicode through a character stream, or where it is getting a byte stream with an unspecified encoding. In the latter case, it will have to look in the XML for an encoding declaration, or use UTF-8 by default). Note that expat only can handle the latter case. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2174 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue839159] iterators broken for weak dicts
Virgil Dupras added the comment: I made a patch to fix the problem. The cleaning up of they weakref keys or values will be held until all references to iterators created by the weakdict are dead. I also couldn't resist removing code duplication of code in items(), keys() and values(). At first, I couldn't understand why this whole remove(), _remove() and selfref() mechanism was in place. I had removed them and replaced them with methods, and the tests still passed. Then I realized it was to make sure keys and values didn't prevent the weak dicts from being freed. I added tests for this. -- keywords: +patch nosy: +vdupras type: - behavior versions: +Python 2.6 Added file: http://bugs.python.org/file9537/weakref_dict_iter.diff Tracker [EMAIL PROTECTED] http://bugs.python.org/issue839159 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2174] xml.sax.xmlreader does not support the InputSource protocol
Yitz Gale added the comment: So I think there are two possibilities: 1. Use a special value for getSourceEnconding(), like unicode, to indicate that this is a unicode character stream and not a byte stream. 2. Provide yet another method in the XMLReader interface: sourceIsCharacterStream(), returning a bool. There is a more drastic option: 3. Since expat doesn't support this stuff anyway, and perhaps not too many people have written parsers that do support it, dumb down the InputSource interface. Specifically, deprecate setCharacterStream(), getCharacterStream(), setEncoding() and getEncoding(), none of which are used by expat. Parsers should read the XML from the byte stream and use that to determine the encoding. That may upset some implementors of XML libraries though. They would each have to go to some trouble to provide their own proprietary and possibly incompatible mechanisms for this, if they need it. Perhaps a compromise fourth path would be to have subclasses of InputSource for the two cases of character stream and byte stream. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2174 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: Alexander, speed-wise your patch is worse than the original one on systems where HZ isn't predefined, because it calls sysconf 5 times in each call to os.times, rather than only once per call. If you worry about speed, the approach outlined in Antoine's last message makes most sense to me. Doing this in the configure script appears dangerous to me; it is well possible that the clock tick value changes over time on the same machine (e.g. after a kernel upgrade), so this should be determined upon process initialization, not before compilation. Also, I don't think that the HZ value should be preferred to the sysconf value if both are available, as all times man pages I could check mention sysconf as the correct way to do this, not HZ. (Some of them state that HZ is used on older systems.) Finally, your patch assumes that HAVE_TIMES implies HAVE_SYSCONF; is that guaranteed? In particular, it's not clear to me what happens on Windows (see comment at the top of the file). I also have no idea how any of the earlier patches behaves on Windows, unfortunately. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Christian Heimes added the comment: I suggest that you define static int hz and assign a value to the var in INITFUNC(). #ifdef HZ hz = HZ; #elif defined(HAVE_SYSCONF) hz = sysconf(_SC_CLK_TCK); #else hz = 60; /* It's 50Hz in Europe */ #endif -- nosy: +tiran _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: Tiran, that's the general approach we should follow, yes. But the people who discussed this on #python-dev all felt a bit queasy about the 60 fallback -- this is what caused the bug in the first place on Guido's and my machine. (A value of 60 was assumed; 100 would have been correct.) Having no such fallback would be preferable, unless it's necessary. You use Windows, right? Can you test if that fallback is necessary there? As far as I can tell, it should not be necessary on a more UNIX-ish system. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: Never mind, on Windows a different code path is chosen. I'm now working on a patch that computes the hz value during module initialization. So should I keep the 60 magic value? What is the justification? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Christian Heimes added the comment:
I don't *use* Windows except for some computer games. But I'm doing some
development for Python on Windows in a VMWare box. I'm going to check HZ
for you. Give me a couple of minutes to boot the image.
How do you like this idea. Since HZ is only used in posix_times it's
fine to cache it in a local static var.
static PyObject *
posix_times(PyObject *self, PyObject *noargs)
{
static int hz = -1;
struct tms t;
clock_t c;
if (hz == -1) {
/* Py_HZ may call sysconf(), cache the value */
hz = Py_HZ;
}
errno = 0;
...
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1040026
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2177] Update compiler module to handle class decorators
New submission from Thomas Herve: The attached patch (tries to?) updates compiler to handle class decorators, and also to handle the new way decorated function are handled. I had a weird bug because it seems that ast.py was modified at hand last time (r51330). This fixes the recent failures in the buildbot slaves. Please review! -- components: Library (Lib) files: compiler.diff keywords: patch messages: 62915 nosy: therve severity: normal status: open title: Update compiler module to handle class decorators versions: Python 2.6 Added file: http://bugs.python.org/file9538/compiler.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2177 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2110] Implement __format__ for Decimal
Mark Dickinson added the comment: Here's a first attempt at Decimal.__format__; the patch is against the trunk, and should be forward ported as usual to 3.0, with obvious minor changes related to str/unicode. It still needs some cleanup and some more tests, but I'm posting it now in the hope of getting some feedback. I'm adding Raymond Hettinger and Eric Smith to the nosy list in case they want to comment. Some points of interest: * I decided to make plain 'e', 'f' and 'g' formats (without an explicit precision) do no rounding: they return a string that captures the exact value of the Decimal instance (though it can lose information about significant zeros). So format(x, 'e') is basically a way to say 'give me str(x), but always include an exponent', and format(x, 'f') gives a way to print the value without ever including an exponent. format(x, 'g') is identical to str(x), except that it always uses the character 'e' for an exponent (instead of using 'e' or 'E' depending on the context). There are other possible options here (have a default precision; use the precision from the context), but this one seemed to make most sense. I'd appreciate opinions. * the integer format specifiers are not supported. After noticing that the integer format specifiers aren't supported for floats either, I think this is the right thing to do. * the 'n' format specifier is not supported either; it's supposed to use the current locale. I can't find any easy way to do this---it seems as though the only real option is to manually fix the decimal point character, figure out where to place thousands separators, etc. This would add quite a lot of not-really-Decimal-related code to decimal.py, and I'm reluctant to do that. The right solution probably involves writing some support code and putting it somewhere else in the std. lib. * on the subject of not-really-Decimal-related code, it would be great if the parse_format_specifier and format_align functions (near the end of decimal.py) could be moved somewhere else. I'm planning to reuse these functions for Fraction.__format__. -- keywords: +patch nosy: +eric.smith, rhettinger versions: +Python 2.6 Added file: http://bugs.python.org/file9539/decimal_format.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2110 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: Here is an updated patch (os_times4.PATCH) that incorporates Christian's suggestions. The patch includes the new unit test, so test_posix?.PATCH need not be applied separately. I again made the unit test a bit more lenient to allow an absolute error of 0.02 seconds, as there may be systems where the clock tick granularity is only 1/60 seconds, and then the old tolerance of 0.015 seconds would be too low. This patch prefers sysconf where it is available; this is what man 2 times asks to do. If sysconf is available but produces an error, that error is raised. (Errors should never pass silently.) HZ is only used if sysconf is not available. If neither sysconf nor HZ is available, a compile-time error is raised -- in that case, HAVE_TIMES shouldn't have been defined in the first place. I also timed this; there is no discernible change compared to the old behaviour. The patch fixes the buggy behaviour on my 64-bit Linux box and makes no difference on my 32-bit Linux box. The new unit test passes on both machines. Added file: http://bugs.python.org/file9540/os_times4.PATCH _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Alexander Belopolsky added the comment: I'd prefer a noisy compile error .. That would be fine if you could verify that none of the currently supported platforms will be affected. I would still feel uneasy about refusing to build python simply because os.times is not ported to a platform. HAVE_TIMES shouldn't have been #defined in the first place. (That is, I'd see that as a bug in the configure script.) No, defined HAVE_TIMES only tell you that the system has 'times' function in the C library. It is not intended to mean that os.times is implementable. Personally, I would still prefer a one-line change that I proposed above. It is obviously better than the current smiley code and if it happens to fix the platforms where errant behavior was observed, it is worth applying even if theoretically it may be wrong. In any case, there is plenty of material here for a developer to step in and close the issue. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Antoine Pitrou added the comment: IMO, if there is no available way to compute HZ, a NotImplementedError should be raised rather than using the 60 magic value. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: I'd prefer a noisy compile error .. That would be fine if you could verify that none of the currently supported platforms will be affected. I would still feel uneasy about refusing to build python simply because os.times is not ported to a platform. Unless I'm missing something, your suggested one-line change fails to compile in exactly the same cases -- if HAVE_TIMES is defined, but HZ and sysconf unavailable -- but with a worse error message. HAVE_TIMES shouldn't have been #defined in the first place. (That is, I'd see that as a bug in the configure script.) No, defined HAVE_TIMES only tell you that the system has 'times' function in the C library. It is not intended to mean that os.times is implementable. Sure, but if times is in the standard library, but its output is uninterpretable, then there's something wrong going on that needs to be fixed rather than swept under the rug. Personally, I would still prefer a one-line change that I proposed above. It is obviously better than the current smiley code and if it happens to fix the platforms where errant behavior was observed, it is worth applying even if theoretically it may be wrong. You complained in msg62869 about the original patch that calling sysconf on every call leads to an unacceptable slowdown. Your one-line patch calls sysconf five times on each call when HZ is not defined. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Antoine Pitrou added the comment: but I will oppose any changes that affect x86_64 linux performance. Alexander, as I said I'm really curious about any situation where os.times() is so performance-critical that a 5% slowdown for that function call is unacceptable. Even when a profiler is involved, os.times() is not the only overhead added by profiling, there is also all the bookkeeping needed for recording various statistics... Perhaps by profiling the profiler we would have an answer :) _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: Alexander, your one-line patch *does* affect performance on my 64-bit Linux machine in a worse way than any other proposed patch by calling sysconf five times. HZ may be defined on your machine, but it isn't on my (Xeon) machine. I checked man pages on four different Linuxes (32 bit and 64 bit; SuSE, Fedora, Ubuntu; recent or six years old). All of them state that using the sysconf value is the right thing to do. This is also stated in the man page excerpt in Guido's original bug report. Neither your latest patch (posixmodule.diff) not my latest patch (os_times4.PATCH) affects performance; they both only call sysconf once and then used a cached value. I'm perfectly fine with your posixmodule.diff, which also meets Antoine's criteria. I suggest we apply that patch, along with the unit test from os_times4.PATCH, and be done with it. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: Antoine, none of the recently proposed patches uses the 60 magic value. Alexander's patch doesn't define times in that case (leading to an AttributeError when trying to call os.times) while my patch complains about the bogus environment during compilation. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Antoine Pitrou added the comment: I think it's better to make it a runtime error (upon invocation of os.times()), rather than a compile-time error. But it's quite theoretical until we find a system where the error does occur, anyway :) _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: s/standard library/system library/, of course. Also, the original code is wrong in preferring HZ over the sysconf value. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Alexander Belopolsky added the comment: HZ may be defined on your machine, but it isn't on my (Xeon) machine. Are you sure? Please note that HZ will not show up in grep -w HZ /usr/include because the right header file further up the tree. On Solaris: /usr/include/sys/param.h:#defineHZ ((clock_t)_sysconf(_SC_CLK_TCK)) On 32-bit Linux: /usr/include/asm-i386/param.h:#define HZ sysconf(_SC_CLK_TCK) On 64-bit Linux: /usr/include/asm-x86_64/param.h:#define HZ 100 Did you try to run posixmodule.c through gcc -E on your system? I should not play devil's advocate and argue against my own patch, but there are two issues: 1. If a system provides non-standard HZ, is it to be preferred to sysconf(..)? Are there systems with correct HZ but no sysconf? 2. Is the added complexity of #ifdef dance justified for the performance improvements on some platforms? I know it looks like I am flip-flopping here, but I just don't want to change anything on the platforms where os.times is not broken and use a solution that is know to work on some platforms to fix the bug where it shows up. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: If I remove the #define 60 line in an unmodified posixmodule.c from trunk, I get the following compiler error: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function posix_times: ./Modules/posixmodule.c:5964: error: HZ undeclared (first use in this function) So yes, HZ isn't available there. It sure is defined *somewhere* (grep shows a definition in /usr/include/asm-x86_64/param.h), but it isn't anywhere Python would pick it up. And I don't really see why it should when the man pages all argue that using HZ for times is for older system (this is a man page from 2002, no less!). Can you measure a performance difference between your patch and the old buggy behaviour? I couldn't, on any machine, and I'd be very surprised if it existed. There is no significant difference between dividing by a constant and diving by a static module variable, and, as Antoine rightly suggests, any such difference would be completely lost in the noise considering the hefty cost of the other operations. Regarding your two issues: 1. Yes, the sysconf value should take precedence over HZ, since this is what man 2 times says you should use. 2. Personally, I'd be just as fine with the original patch that doesn't have the code complexity of the value caching, but I'm fine with anything that fixes the bug. Keeping the old behaviour where possible for old time's sake seems a bad idea -- there were at least two broken platforms (Mac OS and Xeon), and there may be others. Using the documented behaviour (sysconf) where available is a much better solution; honestly, sticking to using HZ as a default without support for that from any documentation has a cargo-cult programming smell to me. I don't know if there are platforms that have times, but neither sysconf nor HZ. That sounds very strange to me, but of course I can't rule it out. But if there are, it is likely that os.times was broken before on these platforms -- it was broken on two platforms that I wouldn't consider minor. In that case, it will still be broken, but at least now we have a unit tests that detects this. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: In the first line of my previous message, I mean #define HZ 60, of course. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Christian Heimes added the comment: Guys, please don't waste too much time on this issue! The tracker still has more than 1,700 open issues for to debate on. While I enjoy the fact, that you three are enthusiastic, I strongly feel the urge to re-route your men power. This bug isn't important enough to waste your precious time on it. My opinion as junior core developer is: sysconf(_SC_CLK_TCK) is the winner and it should be used instead of HZ when available. A default value should not be used because it will lead to wrong data. Wrong results are worse than no results. Since calls to sysconf seem to cost several CPU cycles clk_tck should be cached somehow. I prefer a local static variable in the function but a static var on file level is fine, too. The compilation of Python must not fail. When neither HZ nor sysconf is available but HAVE_TIMES is defined then the function must not be included. Either you skip the function plus undef HAVE_TIMES or you add some code to configure.in that does it earlier. The C89 standard doesn't define #warn so that not an option, too. But configure is allowed fail for a broken system. Christian _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1230540] sys.excepthook doesn't work in threads
Tiago Alves added the comment: I don't see it as a problem or as the threading module trying to be clever. It clearly was a design choice to make the module have its own exception treatment in order to make it clear in which thread the exception occurred. IMHO the decision here should be to implement per thread excepthook's. -- nosy: +tiagoaoa _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1230540 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: Christian, I agree on all points. Alexander's patch posixmodule.diff satisfies those requirements. I suggest also adding the unit test from os_times4.PATCH (but not the changes to posixmodule.c in that patch), as this will help identify misbehaving platforms in the future. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Alexander Belopolsky added the comment: Thanks Cristian for your intervention. This bug is clearly an aberration: how many GvR reported bugs do you know that stayed open for 3+ years? I think posixmodule.diff satisfies all your requirements and was not opposed by anyone except yours truly. Do you need anything else to be done before you can accept the patches. It looks like test_posix4.PATCH + posixmodule.diff should be enough. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Alexander Belopolsky added the comment: This is related to issue1540617 and issue1546078. issue1540617 contains a simple patch that extend acceptable range of argument to +/-2**63 issue1546078 contains a complete long integer support implementation and was accepted in Py3k. It looks like all three issues can be closed by either accepting or rejecting issue1540617 patch for 2.6 and marking issue1546078 patch as accepted for Py3k. -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1533 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2178] Problems with Belarusian Latin locale
New submission from Ihar Hrachyshka: There is a glibc locale: [EMAIL PROTECTED] If my locale environment is set to this locale then all i18n-ed programs are shown with proper translation, except Python-based ones where I see POSIX (?) locale translation (all in English). Though if I set locale as [EMAIL PROTECTED] then all goes well. Please fix the behavior of Python programs in my locale. Affected programs: Sonata MPD client, GnoCHM, Gajim and possibly other. -- components: None messages: 62939 nosy: booxter severity: normal status: open title: Problems with Belarusian Latin locale type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2178 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Christian Heimes added the comment: I'm -10 on the patch in issue1540617 ( +/-2**63). Reason: It's a good thing that the range of range is limited since it returns a list of integers. range(2**32) allocates (2**32)*16 bytes + small overhead for ints plus the space for the list (probably (2**32)*sizeof(ptr) which is 4 or 8 bytes). So far the memory for the ints is *never* returned to the system. I'm working on the problem. -- nosy: +tiran __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1533 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040026] os.times() is bogus
Malte Helmert added the comment: Great, we're approaching closure! :-) One final small thing: As said somewhere above, the allowed discrepancy in test_posix4.PATCH is a bit too low for machines with only 60 ticks per second. I uploaded a slightly more generous test_posix5.PATCH instead. So posixmodule.diff + test_posix5.PATCH. This is the same as what I mentioned above (posixmodule.diff + only the unit test from os_times4.PATCH). Added file: http://bugs.python.org/file9542/test_posix5.PATCH _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2174] xml.sax.xmlreader does not support the InputSource protocol
Yitz Gale added the comment: Subclass of XMLReader would be needed, not InputStream. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2174 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1524] os.system() fails for commands with multiple quoted file names
Rafael Zanella added the comment: I don't have access to a Windows machine, but is it really necessary to quote the command part? I mean, on GNU/Linux if you pass a command wich has spaces , say e.g.: ls -lah, quoted it fails too, but if passed without quotes it runs just fine. -- nosy: +zanella __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1524 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Alexander Belopolsky added the comment: Christian, I was probably a bit sloppy using range instead of xrange, but issue1540617 is limited to xrange only. Are you still -10 on extending xrange on 64-bit platforms to +/- 2**63? If so, what is your position on backporting py3k's unlimited range implementation? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1533 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1858] Make .pypirc handle multiple servers
Tarek Ziadé added the comment: for the -r option, is has to be catched by both register and upload when the command is called like this : $ python setup.py register sdist upload -r my-pypi without the args lookup, register will get an empty value for -r. This option seems to me quite global to distutils. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1858 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Alexander Belopolsky added the comment: So far the memory for the ints is *never* returned to the system. I'm working on the problem. Christian, Are you working on the memory problem or on this issue? I think I have a solution to OP's problem, but don't want to duplicate your effort. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1533 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1986] io.StringIO allows any parameter
Rafael Zanella added the comment: oops, stupid me, this a 3.0 issue..., well seems the str() conversion is done as well on the 3.0 io module: class StringIO(TextIOWrapper): def __init__(self, initial_value=, encoding=utf-8, errors=strict, newline=\n): super(StringIO, self).__init__(BytesIO(), encoding=encoding, errors=errors, newline=newline) if initial_value: if not isinstance(initial_value, str): initial_value = str(initial_value) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1986 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1986] io.StringIO allows any parameter
Rafael Zanella added the comment: I believe you're referring to StringIO, if so, it changes the parameter received to a string: class StringIO: def __init__(self, buf = ''): # Force self.buf to be a string or unicode if not isinstance(buf, basestring): buf = str(buf) -- nosy: +zanella __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1986 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1986] io.StringIO allows any parameter
Christian Heimes added the comment: In Python 2.x StringIO.StringIO calls str() on its arguments: StringIO.StringIO(1).read() '1' StringIO.StringIO(object).read() type 'object' str(object) type 'object' io.StringIO has the same behavior: io.StringIO(1).read() '1' io.StringIO(object).read() type 'object' Georg, what's the bug here? -- nosy: +tiran __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1986 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Christian Heimes added the comment: I'm working on the memory problem. See #2039 and #2013. xrange is a totally different story. I'm +0 on changing xrange. Is Python 3.0's range function compatible with xrange? If the answer is yes, we may reuse the code for an unlimited xrange. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1533 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533] Bug in range() function for large values
Alexander Belopolsky added the comment: Attached patch addresses OP's issue: $ ./python.exe bad_range.py [8, 9, 10, 11, 12, 13, 14, 15, 16, 17] here [18446744073709551616L, 18446744073709551617L, 18446744073709551618L, 18446744073709551619L, 18446744073709551620L, 18446744073709551621L, 18446744073709551622L, 18446744073709551623L, 18446744073709551624L, 18446744073709551625L] [18446744073709551616L, 18446744073709551617L, 18446744073709551618L, 18446744073709551619L, 18446744073709551620L, 18446744073709551621L, 18446744073709551622L, 18446744073709551623L, 18446744073709551624L, 18446744073709551625L] The only existing test that fails is range(1e100, 1e101, 1e101) producing a TypeError. It will now produce range(1e100, 1e101, 1e101) __main__:1: DeprecationWarning: integer argument expected, got float [1159028911097599180468360808563945281389781327557747838 772170381060813469985856815104L] Note that range(1e100, 1e101) would still fail: range(1e100, 1e101) Traceback (most recent call last): File stdin, line 1, in module OverflowError: range() result has too many items An alternative solution would be to disallow non-ints regardless of their value, but that is more likely to break someone's code. -- keywords: +patch Added file: http://bugs.python.org/file9543/bltinmodule.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1533 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2179] with should be as fast as try/finally
New submission from Jeffrey Yasskin: Currently, 'with' costs about .2us over try/finally: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'lock.acquire()' 'try: pass' 'finally: lock.release()' 100 loops, best of 3: 0.617 usec per loop $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'with lock: pass' 100 loops, best of 3: 0.774 usec per loop Since it's doing the same thing (and calling the same C functions to do the lock manipulation), it shouldn't take more time. The bytecodes associated with the two options look like: 2)with lock: 3) pass 2 0 LOAD_GLOBAL 0 (lock) 3 DUP_TOP 4 LOAD_ATTR1 (__exit__) 7 STORE_FAST 0 (_[1]) 10 LOAD_ATTR2 (__enter__) 13 CALL_FUNCTION0 16 POP_TOP 17 SETUP_FINALLY4 (to 24) 3 20 POP_BLOCK 21 LOAD_CONST 0 (None) 24 LOAD_FAST0 (_[1]) 27 DELETE_FAST 0 (_[1]) 30 WITH_CLEANUP 31 END_FINALLY 32 LOAD_CONST 0 (None) 35 RETURN_VALUE 6)lock.acquire() 7)try: 8) pass 9)finally: 10) lock.release() 6 0 LOAD_GLOBAL 0 (lock) 3 LOAD_ATTR1 (acquire) 6 CALL_FUNCTION0 9 POP_TOP 7 10 SETUP_FINALLY4 (to 17) 8 13 POP_BLOCK 14 LOAD_CONST 0 (None) 1017 LOAD_GLOBAL 0 (lock) 20 LOAD_ATTR2 (release) 23 CALL_FUNCTION0 26 POP_TOP 27 END_FINALLY 28 LOAD_CONST 0 (None) 31 RETURN_VALUE The major difference I see is the extra local variable (_[1]) used by with. It looks like the compiler ought to be able to save that on the stack instead, and save 3 opcodes. Neal Norwitz suggested that, if that optimization is impossible, WITH_CLEANUP could be modified to take the variable as a parameter, which would let it absorb the LOAD_FAST and DELETE_FAST instructions. I've added everyone on the previous bug to the nosy list. Sorry if you don't care. :) -- components: Interpreter Core messages: 62951 nosy: amaury.forgeotdarc, benjamin.peterson, jyasskin, nnorwitz, rhettinger, tiran severity: normal status: open title: with should be as fast as try/finally type: feature request versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2179 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Jeffrey Yasskin added the comment: I've filed issue 2179 to see if it's possible to make with as fast as try/finally. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1394] simple patch, improving unreachable bytecode removing
Alexander Belopolsky added the comment: I am not sure what this patch would accomplish. I tried $ cat t.py def f(): return 1 1+2 from dis import dis print dis(f) Both with and without patch I get $ ./python.exe -O t.py 2 0 LOAD_CONST 1 (1) 3 RETURN_VALUE 3 4 LOAD_CONST 1 (1) 7 LOAD_CONST 2 (2) 10 BINARY_ADD 11 POP_TOP None I am sure I am missing something, but it is hard to tell what without any use cases provided. -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1394 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1772673] Replacing char* with const char*
Alexander Belopolsky added the comment: Douglas Greiman submitted many similar changes with his issue2135 patch. His patch also amends documentation, which is missing here. I am adding dgreiman to the nosy list here to avoid duplication of effort. I am -0 on the idea. -- nosy: +belopolsky, dgreiman _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1772673 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2179] with should be as fast as try/finally
Changes by Collin Winter: -- nosy: +collinwinter __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2179 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1766304] improve xrange.__contains__
Alexander Belopolsky added the comment: Do we really need another way to spell a = x b? Have you got a real-world use case in mind for the version with step 1? I'm at most lukewarm; I'd be willing to look at a patch to the C code in the py3k-struni branch, plus unit tests though. -- GvR at http://thread.gmane.org/gmane.comp.python.python- 3000.devel/8732 I read this as a rejection for 2.x series. For py3k, this is a premature optimization. Current py3k implementation is likely to be optimized for regular size integers at some point. This patch will only introduce more code to be changed then. If this is not ready to be rejected for 2.x, let's wait for resolution of issue1540617 since it may result in backporting of py3k range implementation. -- nosy: +belopolsky _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1766304 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
Changes by Jared Grubb: -- components: Extension Modules nosy: jaredgrubb severity: minor status: open title: tokenize: mishandles line joining type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2180 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
New submission from Jared Grubb: tokenize does not handle line joining properly, as the following string fails the CPython tokenizer but passes the tokenize module. Example 1: s = if 1:\n \\\n #hey\n print 1 exec s Traceback (most recent call last): File stdin, line 1, in module File string, line 3 #hey ^ SyntaxError: invalid syntax tokenize.tokenize(StringIO(s).readline) 1,0-1,2:NAME'if' 1,3-1,4:NUMBER '1' 1,4-1,5:OP ':' 1,5-1,6:NEWLINE '\n' 2,0-2,2:INDENT ' ' 3,2-3,6:COMMENT '#hey' 3,6-3,7:NEWLINE '\n' 4,2-4,7:NAME'print' 4,8-4,9:NUMBER '1' 5,0-5,0:DEDENT '' 5,0-5,0:ENDMARKER '' __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2180 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2181] optimize out local variables at end of function
New submission from Neal Norwitz: This patch optimizes code like: x = any_expression return x to: return any_expression Currently it only optimizes out the local variable if there is a return because it can't determine if this is the last use of the variable or not. This shouldn't change behaviour under normal circumstances, but would change behaviour with a debugger. Perhaps this optimization should only be performed if -O is passed on the command line? This optimization saves two trips around the eval loop (STORE_FAST and LOAD_FAST) and 6 bytes in the byte code. -- components: Interpreter Core files: opt-out-local-var.patch keywords: patch, patch messages: 62957 nosy: nnorwitz severity: normal status: open title: optimize out local variables at end of function type: resource usage Added file: http://bugs.python.org/file9544/opt-out-local-var.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2181 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2181] optimize out local variables at end of function
Neal Norwitz added the comment: I forgot to mention that if another loop was added to PyCode_Optimize that kept track of the # of times each local variable was LOAD_FAST/STORE_FAST/DELETE_FAST and that the count was 2, we could perform a similar optimization without requiring the return. Bonus points for other cases like if it was the last use inside a list comprehension or the variable is otherwise unaccessible. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2181 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
New submission from Jared Grubb:
tokenize recognizes '\n' and '\r\n' as newlines, but does not tolerate '\r':
s = print 1\nprint 2\r\nprint 3\r
open('temp.py','w').write(s)
exec(open('temp.py','r'))
1
2
3
tokenize.tokenize(open('temp.py','r').readline)
1,0-1,5:NAME'print'
1,6-1,7:NUMBER '1'
1,7-1,8:NEWLINE '\n'
2,0-2,5:NAME'print'
2,6-2,7:NUMBER '2'
2,7-2,9:NEWLINE '\r\n'
3,0-3,5:NAME'print'
3,6-3,7:NUMBER '3'
3,7-3,8:ERRORTOKEN '\r'
4,0-4,0:ENDMARKER ''
--
components: Extension Modules
messages: 62959
nosy: jaredgrubb
severity: minor
status: open
title: tokenize: does not allow CR for a newline
type: behavior
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2182
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
Jared Grubb added the comment:
CPython allows \ at EOF, but tokenize does not.
s = 'print 1\\\n'
exec s
1
tokenize.tokenize(StringIO(s).readline)
1,0-1,5:NAME'print'
1,6-1,7:NUMBER '1'
Traceback (most recent call last):
File stdin, line 1, in module
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py,
line 153, in tokenize
tokenize_loop(readline, tokeneater)
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py,
line 159, in tokenize_loop
for token_info in generate_tokens(readline):
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py,
line 283, in generate_tokens
raise TokenError, (EOF in multi-line statement, (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (2, 0))
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2180
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2183] optimize list comprehensions
New submission from Neal Norwitz: Optimize list comprehensions by using the list on the stack, rather than storing in a (local/global) variable. This reduces the size of the stack by one pointer, reduces the bytecode size by 8, and reduces the iterations in the eval loop by 2 + # of iterations to create the new list. It also eliminates internal variables in varnames. List comps in module/class scope execute faster by avoiding more costly dict lookups in globals. For this source code: def f(): return [x for x in s] Byte code before change: 1 0 BUILD_LIST 0 3 DUP_TOP 4 STORE_FAST 0 (_[1]) 7 LOAD_GLOBAL 1 (s) 10 GET_ITER 11 FOR_ITER13 (to 27) 14 STORE_FAST 1 (x) 17 LOAD_FAST0 (_[1]) 20 LOAD_FAST1 (x) 23 LIST_APPEND 24 JUMP_ABSOLUTE 11 27 DELETE_FAST 0 (_[1]) 30 RETURN_VALUE New byte code: 1 0 BUILD_LIST 0 3 LOAD_GLOBAL 0 (s) 6 GET_ITER 7 FOR_ITER12 (to 22) 10 STORE_FAST 0 (x) 13 LOAD_FAST0 (x) 16 LIST_APPEND 2 19 JUMP_ABSOLUTE7 22 RETURN_VALUE DUP_TOP/STORE_FAST are eliminated before the loop. One LOAD_FAST is eliminated inside the loop. LIST_APPEND is changed to reference the value on the stack. Is it a problem to change the opcode of LIST_APPEND? This might make debugging harder. I'm not sure how debuggers work with list comps. A similar optimization could probably be done to eliminate all uses of the temporary variables (WITH_CLEANUP at least). This patch still needs to update docs and the compiler package implemented in Python. -- components: Interpreter Core files: list-comp-opt2.patch keywords: patch, patch messages: 62961 nosy: nnorwitz severity: normal status: open title: optimize list comprehensions type: resource usage versions: Python 2.6 Added file: http://bugs.python.org/file9545/list-comp-opt2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2183 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2181] optimize out local variables at end of function
Neal Norwitz added the comment: I forgot to mention that if another loop was added to PyCode_Optimize that kept track of the # of times each local variable was LOAD_FAST/STORE_FAST/DELETE_FAST and that the count was 2, we could perform a similar optimization without requiring the return. Bonus points for other cases like if it was the last use inside a list comprehension or the variable is otherwise unaccessible. -- versions: +Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2181 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2184] Speed up Thread.start()
New submission from Jeffrey Yasskin: Thread.start() used sleep(0.01) to make sure it didn't return before the new thread had started. At least on my MacBook Pro, that wound up sleeping for a full 10ms (probably 1 jiffy). By using an Event instead, we can be absolutely certain that the thread has started, and return more quickly (217us). Before: $ ./python.exe -m timeit -s 'from threading import Thread' 't = Thread(); t.start(); t.join()' 100 loops, best of 3: 10.3 msec per loop $ ./python.exe -m timeit -s 'from threading import Thread; t = Thread()' 't.isAlive()' 100 loops, best of 3: 0.47 usec per loop After: $ ./python.exe -m timeit -s 'from threading import Thread' 't = Thread(); t.start(); t.join()' 1000 loops, best of 3: 217 usec per loop $ ./python.exe -m timeit -s 'from threading import Thread; t = Thread()' 't.isAlive()' 100 loops, best of 3: 0.86 usec per loop To be fair, the 10ms isn't CPU time, and other threads including the spawned one get to run during it. There are also some slightly more complicated ways to get back the .4us in isAlive() if we want. -- components: Library (Lib) files: faster_thread_startup.diff keywords: patch, patch messages: 62963 nosy: jyasskin severity: normal status: open title: Speed up Thread.start() type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9546/faster_thread_startup.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2184 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1394] simple patch, improving unreachable bytecode removing
Neal Norwitz added the comment: It would be great to see test cases with this change. That would help answer Alexander's question too. -- nosy: +nnorwitz __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1394 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2185] code objects should conserve memory
New submission from Neal Norwitz: Various bits are often duplicated in code objects. For example, sometimes names and varnames are equal. In this case, we don't need two objects since they are both const. This patch implements a trivial fix for this case. However, there are more cases. We should profile where the memory is being used and do simple/cheap consolidations where possible. Another example would be a 1-element tuple containing: (None,) for consts. Some (all?) of these sorts of optimizations should probably be done in the code object itself. -- files: marshal-mem.patch keywords: patch, patch messages: 62965 nosy: nnorwitz severity: normal status: open title: code objects should conserve memory type: resource usage versions: Python 2.6 Added file: http://bugs.python.org/file9547/marshal-mem.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2185 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2181] optimize out local variables at end of function
Neal Norwitz added the comment: Guido says to do it only with -O. http://mail.python.org/pipermail/python-dev/2008-February/077193.html __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2181 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2186] map and filter shouldn't support None as first argument (in Py3k only)
New submission from Guido van Rossum: There are other ways of getting the same effects now (list() or zip() for map(None, ...)). -- keywords: easy messages: 62967 nosy: gvanrossum severity: normal status: open title: map and filter shouldn't support None as first argument (in Py3k only) versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2186 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2186] map and filter shouldn't support None as first argument (in Py3k only)
Changes by Guido van Rossum: -- components: +Interpreter Core type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2186 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2187] map and filter objects shouldn't call themselves itertools.imap and itertools.ifilter objects
New submission from Guido van Rossum: Probably ifilter and imap should go (moving the code over to bltinmodule.c). -- components: Interpreter Core keywords: easy messages: 62968 nosy: gvanrossum severity: normal status: open title: map and filter objects shouldn't call themselves itertools.imap and itertools.ifilter objects type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2187 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve error msg
Neal Norwitz added the comment: Christian, Could you clean this patch up? Specifically: * Put everything into one patch * Eliminate unnecessary changes (changing variable name or whitespace) * Conform to the style in the file * Verify all the tests run with regrtest.py -u all when built --without-pydebug * Verify it runs faster _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1691070 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2186] map and filter shouldn't support None as first argument (in Py3k only)
Alexander Belopolsky added the comment:
In the absence of an identity function, map accepting None is useful in
the cases like this:
converters = {..}
y = map(converters.get(c), x)
That will now have to be rewritten as
conv = converters.get(c)
if conv is None:
y = list(x)
else:
y = map(conv, x)
and subtle bugs will be introduced if x is used instead of list(x) in
the None case.
Another alternative,
y = map(converters.get(c, lambda x:x), x)
will be much slower.
Take my opinion with a grain of salt because I also believe None should
be callable with None(x) - x and None(x,y,..) - (x,y,..).
--
nosy: +belopolsky
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2186
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1740] use unittest for test_logging
Brett Cannon added the comment: I am attaching a reviewed version of the patch. It had some major PEP 8 violations that I had to clean up. I also moved over to the usage of test.test_support.captured_stdout(). Otherwise it looks good. I am going to wait a little while in hopes someone else can at least take a look to make sure that the tests are proper and thorough since it is a complete rewrite. Added file: http://bugs.python.org/file9548/test_logging.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1740 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1540617] Use Py_ssize_t for rangeobject members
Martin v. Löwis added the comment: I fail to see the need for this, from more than an academic point of you. What specific event triggered your working on this? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1540617 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
Hye-Shik Chang added the comment: I'll take this. -- assignee: lemburg - hyeshik.chang nosy: +hyeshik.chang __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1276 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
