[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg added the comment: Your microbenchmark is biased towards your patched version. The KEEPALIVE_SIZE_LIMIT will only cut in when you deallocate and then reallocate Unicode objects. The free list used for Unicode objects is also limited to 1024 objects - which isn't all that much. You could tune MAX_UNICODE_FREELIST_SIZE as well. Regarding memory usage: this is difficult to measure in Python, since pymalloc will keep memory chunks allocated even if they are not in use by Python. However, this is a feature of pymalloc and not specific to the Unicode implementation. It can be tuned in pymalloc. To get more realistic memory measurements, you'd have to switch off pymalloc altogether and then create a separate process that consumes lots of memory to force the OS to have it allocate only memory that's really needed to the process you're running for memory measurements. Of course, keeping objects alive in a free list will always use more memory than freeing them altogether and returning the memory to the OS. It's a speed/space tradeoff. The RAM/CPU costs ratio has shifted a lot towards RAM nowadays, so using more RAM is usually more efficient than using more CPU time. Regarding resize: you're right - the string object is a PyVarObject as well and couldn't be changed at the time due to backwards compatibility reasons. You should also note that when I added Unicode to Python 1.6, it was a new and not commonly used type. Codecs were not used much either, so there was no incentive to make resizing strings work better. Later on, other optimizations were added to the Unicode implementation that caused the PyUnicode_Resize() API to also require being able to change the object address. Still, in the common case, it doesn't change the object address. The reason for using an external buffer for the Unicode object was to be able to do further optimizations, such as share buffers between Unicode objects. We never ended up using this, though, but there's still a lot of room for speedups and more memory efficiency because of this design. Like I already mentioned, PyObjects are also easier to extend at C level - adding new variables to the object at the end is easy with PyObjects. It's difficult for PyVarObjects, since you always have to take the current size of the object into account and you always have to use indirection to get at the extra variables due to the undefined offset of the variables. How much speedup do you get when you compare the pybench test with KEEPALIVE_SIZE_LIMIT = 200 compared to your patched version ? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1943 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1944] Documentation for PyUnicode_AsString (et al.) missing.
Changes by Christian Heimes: -- priority: - normal type: - rfe __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1944 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1945] Document back ported C functions
New submission from Christian Heimes: Document the C functions which were back ported from py3k in r60283. -- components: Documentation keywords: easy messages: 61736 nosy: tiran priority: normal severity: normal status: open title: Document back ported C functions type: rfe versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1945 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Mark Dickinson added the comment: I noticed that the ability to type Rational(2.3) has been added (and I think this is a very useful addition). One minor nit: would it make sense to have Rational(2.) and Rational(.3) also work? These strings work for float() and Decimal(), and 2. and .3 work as float literals, so it would seem to make sense to allow this for Rational as well. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Antoine Pitrou added the comment: With KEEPALIVE_SIZE_LIMIT = 200, the pybench runtime is basically the same as with my patched version. stringbench remains a bit faster though (~8%). You say that RAM size is cheaper than CPU power today, which is true but misses one part of the picture: the importance of CPU caches, and thus of working set size. There are also probably people wanting to use Python in memory-constrained environments (embedded). I understand the argument about possible optimizations with an external buffer, but are such optimizations likely to be implemented? (see #1590352 and #1629305). If they really are, then I'm happy with the unicode type remaining a plain PyObject! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1943 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1946] re.search hangs on this
New submission from Israel Tsadok: import re re.search(r'a(b[^b]*b|[^c])*cxxx', 'abbcacacabbcabbcacabbcacac') perl seems to handle this just fine. (The original problem was trying to translate some html to text: re.sub(r'p(?:[^]*|[^])*(.*?)/p', r'\1\n') This hanged on several files. Changing [^] to [^] resolved my problem, but the general case remains.) This might be a dupe of http://bugs.python.org/issue1297193 -- components: Regular Expressions messages: 61739 nosy: itsadok severity: normal status: open title: re.search hangs on this versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1946 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg added the comment: I don't really see the connection with #1629305. An optimization that would be worth checking is hooking up the Py_UNICODE pointer to interned Unicode objects if the contents match (e.g. do a quick check based on the hash value and then a memcmp). That would save memory and the call to the pymalloc allocator. Another strategy could involve a priority queue style cache with the aim of identifying often used Unicode strings and then reusing them. This could also be enhanced using an offline approach: you first run an application with an instrumented Python interpreter to find the most often used strings and then pre-fill the cache or interned dictionary on the production Python interpreter at startup time. Coming from a completely different angle, you could also use the Py_UNICODE pointer to share slices of a larger data buffer. A Unicode sub-type could handle this case, keeping a PyObject* reference to the larger buffer, so that it doesn't get garbage collected before the Unicode slice. Regarding memory constrained environments: these should simply switch off all free lists and pymalloc. OTOH, even mobile phones come with gigabytes of RAM nowadays, so it's not really worth the trouble, IMHO. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1943 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Antoine Pitrou added the comment: All of those proposals are much heavier to implement; they also make the unicode type more complicated and difficult to maintain probably (while turning it into a PyVarObject actually shortens the implementation a bit). In any case, it's not something I want to tackle. The reason that I mentioned #1629305 was that it was such an optimization which complicated the unicode type while bringing very significant speedups. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1943 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1947] Exception exceptions.AttributeError '_shutdown' in module 'threading'
New submission from shore.cloud: Exception exceptions.AttributeError: '_shutdown' in module 'threading' from 'F: \Python25\lib\threading.pyc' ignored -- files: thread1.py messages: 61742 nosy: Mr Shore severity: normal status: open title: Exception exceptions.AttributeError '_shutdown' in module 'threading' Added file: http://bugs.python.org/file9299/thread1.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1947 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg added the comment: Agreed, those optimizations do make the implementation more complicated. It's also not clear whether they would really be worth it. #1629305 only provided speedups for the case where you write s += 'abc'. The usual idiom for this is to use a list and then concatenate in one go. If you want a really fast approach, you'd use cStringIO or perhaps the bufferarray. I don't think that optimizing for just one particular use case warrants making the code more complicated or changing the C interface radically. In your case, I think that closing the door for being able to easily extend the type implement at the C is the main argument against it. The speedups are only marginal and can also be achieved (to some extent) by tuning the existing implementation's parameters. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1943 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1867] patch for pydoc to work in py3k
Georg Brandl added the comment: Done in r60366, thanks! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1867 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1941] 2.6 stdlib using with statement
Benjamin Peterson added the comment: Today, I carefully looked through every change in my patching. I asked myself Does this do the same things in the same order as the original? and Could exceptions cause the code to function differently? They only changes were when the block which used the file was not in a try finally block so if an exception were raised, it the file would be closed. The with statement of course removes this problem. So, I do believe the patch is semantically neutral. I would, however, not mind if another set of eyes examined it. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1941 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1947] Exception exceptions.AttributeError '_shutdown' in module 'threading'
Christian Heimes added the comment: Next time please set type, component and version -- components: +Library (Lib) nosy: +tiran priority: - low type: - behavior versions: +Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1947 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Antoine Pitrou added the comment: I know it's not the place to discuss #1629305, but the join() solution is not always faster. Why? Because 1) there's the list contruction and method call overhead 2) ceval.c has some bytecode hackery to try and make plain concatenations somewhat less slow. As for cStringIO, I actually observed in some experiments that it was slower than the other alternatives, at least for short strings. All in all, choosing between the three idioms is far from obvious and needs case-by-case analysis. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1943 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1948] Cant open python gui using VISTA
New submission from safe alattar: I need help opening the python gui (IDLE). On XP I had no issues. On Vista nothing occurs when I try to open IDLE. If there is a solution to this, please let me know in a user friendly manner (Im new to this!) Thanks. -- messages: 61749 nosy: needhelpasap severity: normal status: open title: Cant open python gui using VISTA __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1948 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1947] Exception exceptions.AttributeError '_shutdown' in module 'threading'
shore.cloud added the comment: I will,sorry 2008/1/28, Christian Heimes [EMAIL PROTECTED]: Christian Heimes added the comment: Next time please set type, component and version -- components: +Library (Lib) nosy: +tiran priority: - low type: - behavior versions: +Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1947 __ Added file: http://bugs.python.org/file9300/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1947 __I will,sorry brbr divspan class=gmail_quote2008/1/28, Christian Heimes lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;:/span blockquote class=gmail_quote style=PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solidbrChristian Heimes added the comment:brbrNext time please set type, component and versionbrbr--br components: +Library (Lib)brnosy: +tiranbrpriority:nbsp;nbsp;-gt; lowbrtype:nbsp;nbsp;-gt; behaviorbrversions: +Python 2.5brbr__brTracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue1947;http://bugs.python.org/issue1947/agt;br__br/blockquote/divbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1949] test_ntpath.py rewriting
New submission from Giampaolo Rodola': Since I noticed that test_ntpath.py (unlike test_genericpath.py, test_macpath.py and test_posixpath.py) does NOT use unittest for doing tests I tried to rewrite it. The patch in attachment does that leaving the original tests unchanged. Tested successfully by having used python 2.6 (current trunk) on Windows XP and Linux Ubuntu. -- components: Tests files: test_ntpath.diff messages: 61750 nosy: giampaolo.rodola severity: normal status: open title: test_ntpath.py rewriting versions: Python 2.6 Added file: http://bugs.python.org/file9301/test_ntpath.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1949 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1949] test_ntpath.py rewriting
Changes by Giampaolo Rodola': Added file: http://bugs.python.org/file9302/test_ntpath.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1949 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1949] test_ntpath.py converted to unittest
Changes by Giampaolo Rodola': -- title: test_ntpath.py rewriting - test_ntpath.py converted to unittest __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1949 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1949] test_ntpath.py rewriting
Christian Heimes added the comment: The patch looks fine but I've no time to review it properly. -- keywords: +easy, patch nosy: +tiran priority: - normal resolution: - accepted type: - rfe __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1949 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1950] Potential Overflow due to incorrect usage of PyUnicode_AsString.
New submission from Alexandre Vassalotti: I have found a few instances of the following pattern in Py3k: char buf[MAX]; len = PyUnicode_GET_SIZE(str); if (len = MAX) /* return error */ strcpy(buf, PyUnicode_AsString(str)); which could overflow if str contains non-ASCII characters. These were probably introduced during the PyString - PyUnicode transition. Anyway, I got a patch that fixes (hopefully) most of these bugs. -- assignee: alexandre.vassalotti components: Interpreter Core files: unicode_string_overflow.patch keywords: patch messages: 61753 nosy: alexandre.vassalotti priority: normal severity: normal status: open title: Potential Overflow due to incorrect usage of PyUnicode_AsString. type: security versions: Python 3.0 Added file: http://bugs.python.org/file9303/unicode_string_overflow.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1950 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.
Changes by Alexandre Vassalotti: -- title: Potential Overflow due to incorrect usage of PyUnicode_AsString. - Potential overflows due to incorrect usage of PyUnicode_AsString. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1950 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1951] test_wave.py converted to unittest
New submission from Giampaolo Rodola': In attachment. -- components: Tests files: test_wave.diff messages: 61754 nosy: giampaolo.rodola severity: minor status: open title: test_wave.py converted to unittest type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9304/test_wave.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1951 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1951] test_wave.py converted to unittest
Giampaolo Rodola' added the comment: Sorry but I realized right now by reading Lib/test/readme.txt that the test scripts are required to have a global test_main() function defined hence the main() function I defined in my patch should be renamed in test_main(). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1951 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1952] test_select.py converted to unittest
New submission from Giampaolo Rodola': In attachment. -- components: Tests files: test_select.diff messages: 61756 nosy: giampaolo.rodola severity: minor status: open title: test_select.py converted to unittest type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9305/test_select.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1952 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1952] test_select.py converted to unittest
Changes by Giampaolo Rodola': Added file: http://bugs.python.org/file9306/test_select.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1952 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Ismail Donmez added the comment: Thanks for the through review! I will add -Wsign-compare and fix new warnings. Btw current state is with the patch -fwrapv is not needed and no regressions. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Neal Norwitz added the comment:
I just added -Wstrict-overflow to the code in sysmodule.c
(sys_getframe) and tried with gcc 4.2.1. It doesn't warn. I wonder
if 4.3 is more picky or warns when it shouldn't?
Unless if I changed the code so it doesn't work:
typedef struct {int ref;} PyObject;
typedef struct { PyObject* f_back; } PyFrameObject;
int PyArg_ParseTuple(PyObject*, const char*, int*);
PyObject *
sys_getframe(PyFrameObject *f, PyObject *self, PyObject *args)
{
int depth = -1;
if (!PyArg_ParseTuple(args, |i:_getframe, depth))
return 0;
while (depth 0 f != 0) {
f = (PyFrameObject*)f-f_back;
--depth;
}
return (PyObject*)f;
}
Compiled with:
gcc-4.2.1-glibc-2.3.2/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-gcc
-Wstrict-overflow -c xx.c
produced no warnings. This is not a stock gcc 4.2.1, so that could
also be an issue. Did I run it correctly. Is there anything else I
need to do? If you run the code above with gcc 4.3, does it produce a
warning?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Guido van Rossum added the comment: Unfortunately I have no time to work on this myself, but in order to make progress I recommend checking in things piecemeal so that the same changes don't get reviewed over and over again. I propose that each submit reference this bug (Partial fix for issue #1621 I'd suggest) and that the submits are recorded here (e.g. fixed filename in rXXX (2.5.2), rYYY (2.6)). Then hopefully only a few hard cases will remain. With Neal, I don't see what the warning in _csv is about. What condition is being turned into a constant? Is the compiler perhaps rearranging the code so as to insert if (field[0] == '\0') goto XXX; in front of the for-loop where XXX jumps into the middle of the condition in the if-statement immediately following the for-loop, and skipping that if-block when breaking of the loop later? That would be clever, and correct, and I'm not sure if making i unsigned is going to help -- in fact it might make the compiler decide it can't use that optimization... __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Ismail Donmez added the comment: To Neal, Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk. To Guido, I'll check _csv.c issue closely. Shall I create the new bug reports or will reviewers will do so and CC me maybe? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Neal Norwitz added the comment: On Jan 27, 2008 6:45 PM, Ismail Donmez [EMAIL PROTECTED] wrote: Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk. I just tried with =1, =2, =3, and no =. All the same result: no warning. Ismail, thanks for going through all this effort. It's very helpful. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Guido van Rossum added the comment: Don't create new bug reports! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Ismail Donmez added the comment: _sre.c case is the most interesting one , compiler says : ./Modules/_sre.c:1002: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1069: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1086: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1143: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1185: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1214: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1238: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1251: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1277: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1291: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1308: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1395: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1408: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c: In function 'sre_umatch': ./Modules/_sre.c:1002: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1069: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1086: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1143: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1185: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1214: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1238: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1251: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1277: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1291: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1308: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1395: warning: assuming signed overflow does not occur when simplifying conditional to constant ./Modules/_sre.c:1408: warning: assuming signed overflow does not occur when simplifying conditional to constant all lines refer to : RETURN_ON_ERROR(ret); My investigation : On line 1002 we got RETURN_ON_ERROR(ret); but ret is already 0 and not set to anything this if will always be false. Same for line 1069, ret is still zero there. Maybe I am missing something here? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Ismail Donmez added the comment: For xmlparse.c compiler says : Modules/expat/xmlparse.c:5337: warning: assuming signed overflow does not occur when simplifying conditional to constant Its impossible for j to overflow here due to name[i] check but I am not sure what gcc is optimizing here. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Guido van Rossum added the comment:
for (i = 0; i strlen(field) ; i++) {
This looks inefficient. Why not
for (i = 0; field[i] != '\0'; i++) {
???
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1926] NNTPS support in nntplib
Ray Chason added the comment: It seems that I, or whoever writes any future test_nntplib.py, would have to understand how existing tests such as test_smtplib.py work. It looks like that one is setting up some kind of miniature mail server and accepting a connection on localhost -- neat trick, binding a server socket to port 0 so it still works if you have a real mail server running. Anyway, getting good coverage isn't something I can bang out in an afternoon. Class NNTPBase and its derivatives (I'm talking post-patch of course) have lots of methods and I want to cover them as well as possible. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1926 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1948] Cant open python gui using VISTA
safe alattar added the comment: I made a search for the hidden folder 'idlerc' and got back no results : ( __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1948 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1953] gc.compact_freelists
New submission from Christian Heimes: The patch implements gc.compact_freelists() which calls PyInt and PyFloat_CompactFreeList(). I've moved the code from the _Fini methods to the _CompactFreeList() methods. The patch also moves the clear type cache function to gc.clear_type_cache(). -- assignee: nnorwitz components: Extension Modules, Interpreter Core files: trunk_compact_freelist.patch keywords: patch messages: 61771 nosy: nnorwitz, tiran priority: normal severity: normal status: open title: gc.compact_freelists type: rfe versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9308/trunk_compact_freelist.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1953 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Ismail Donmez added the comment: Hah strlen in a loop, a nice beginner mistake but its 5.30 AM here so please excuse me, Guido your version of course is way better. But with that version compiler issues Modules/_csv.c:969: warning: assuming signed overflow does not occur when simplifying conditional to constant again, strlen() just fooled that optimization it seems. So there should be another way to optimize this loop. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1952] test_select.py converted to unittest
Changes by Christian Heimes: -- keywords: +patch priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1952 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
