Re: [Python-Dev] Type of range object members
Greg Ewing schrieb: Martin v. Löwis wrote: We had this discussion before; if you use ob_size==0 to indicate that it's an int, this space isn't needed in a long int. What about int subclasses? It's what Guido proposes. It would still leave two types (perhaps three) at the C level, so C code might have to continue making conditional code depending on which of these it is. Also, Python code that dispatches by type still needs to make the distinction. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
Greg Ewing schrieb: Guido van Rossum wrote: I worry that dropping the special allocator will be too slow. Surely there's some compromise that would allow recently-used ints to be kept around, but reclaimed if memory becomes low? Hardly. The efficiency of the special-case allocator also comes from the fact that it doesn't ever have to release memory. Just try changing it to see what I mean. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
Greg Ewing schrieb: There isn't? Actually a lot of APIs currently assumen that. Also it means you'd pay a penalty every time you access it, whereas presumably short ints are the case we want to optimise for speed as well. That penalty is already paid today. Much code dealing with ints has a type test whether it's an int or a long. If int and long become subtypes of each other or of some abstract type, performance will decrease even more because a subtype test is quite expensive if the object is neither int nor long (it has to traverse the entire base type hierarchy to find out its not inherited from int). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote: That penalty is already paid today. Much code dealing with ints has a type test whether it's an int or a long. If int and long become subtypes of each other or of some abstract type, performance will decrease even more because a subtype test is quite expensive if the object is neither int nor long (it has to traverse the entire base type hierarchy to find out its not inherited from int). I was playing around with a little patch to avoid that penalty. It doesn't take any additional memory, just a handful of bits we aren't using. :-) For the more common builtin types, it stores whether it's a subclass in tp_flags, so there's no function call necessary and it's a constant time operation. It was faster when doing simple stuff. Haven't thought much whether this is really worthwhile or not. n Index: Include/stringobject.h === --- Include/stringobject.h (revision 51237) +++ Include/stringobject.h (working copy) @@ -55,8 +55,9 @@ PyAPI_DATA(PyTypeObject) PyBaseString_Type; PyAPI_DATA(PyTypeObject) PyString_Type; -#define PyString_Check(op) PyObject_TypeCheck(op, PyString_Type) #define PyString_CheckExact(op) ((op)-ob_type == PyString_Type) +#define PyString_Check(op) (PyString_CheckExact(op) || \ + PyType_FastSubclass((op)-ob_type, Py_TPFLAGS_STRING_SUBCLASS)) PyAPI_FUNC(PyObject *) PyString_FromStringAndSize(const char *, Py_ssize_t); PyAPI_FUNC(PyObject *) PyString_FromString(const char *); Index: Include/dictobject.h === --- Include/dictobject.h (revision 51237) +++ Include/dictobject.h (working copy) @@ -90,8 +90,9 @@ PyAPI_DATA(PyTypeObject) PyDict_Type; -#define PyDict_Check(op) PyObject_TypeCheck(op, PyDict_Type) #define PyDict_CheckExact(op) ((op)-ob_type == PyDict_Type) +#define PyDict_Check(op) (PyDict_CheckExact(op) || \ + PyType_FastSubclass((op)-ob_type, Py_TPFLAGS_DICT_SUBCLASS)) PyAPI_FUNC(PyObject *) PyDict_New(void); PyAPI_FUNC(PyObject *) PyDict_GetItem(PyObject *mp, PyObject *key); Index: Include/unicodeobject.h === --- Include/unicodeobject.h (revision 51237) +++ Include/unicodeobject.h (working copy) @@ -390,8 +390,9 @@ PyAPI_DATA(PyTypeObject) PyUnicode_Type; -#define PyUnicode_Check(op) PyObject_TypeCheck(op, PyUnicode_Type) #define PyUnicode_CheckExact(op) ((op)-ob_type == PyUnicode_Type) +#define PyUnicode_Check(op) (PyUnicode_CheckExact(op) || \ + PyType_FastSubclass((op)-ob_type, Py_TPFLAGS_UNICODE_SUBCLASS)) /* Fast access macros */ #define PyUnicode_GET_SIZE(op) \ Index: Include/intobject.h === --- Include/intobject.h (revision 51237) +++ Include/intobject.h (working copy) @@ -27,8 +27,9 @@ PyAPI_DATA(PyTypeObject) PyInt_Type; -#define PyInt_Check(op) PyObject_TypeCheck(op, PyInt_Type) #define PyInt_CheckExact(op) ((op)-ob_type == PyInt_Type) +#define PyInt_Check(op) (PyInt_CheckExact(op) || \ + PyType_FastSubclass((op)-ob_type, Py_TPFLAGS_INT_SUBCLASS)) PyAPI_FUNC(PyObject *) PyInt_FromString(char*, char**, int); #ifdef Py_USING_UNICODE Index: Include/listobject.h === --- Include/listobject.h (revision 51237) +++ Include/listobject.h (working copy) @@ -40,8 +40,9 @@ PyAPI_DATA(PyTypeObject) PyList_Type; -#define PyList_Check(op) PyObject_TypeCheck(op, PyList_Type) #define PyList_CheckExact(op) ((op)-ob_type == PyList_Type) +#define PyList_Check(op) (PyList_CheckExact(op) || \ + PyType_FastSubclass((op)-ob_type, Py_TPFLAGS_LIST_SUBCLASS)) PyAPI_FUNC(PyObject *) PyList_New(Py_ssize_t size); PyAPI_FUNC(Py_ssize_t) PyList_Size(PyObject *); Index: Include/object.h === --- Include/object.h (revision 51237) +++ Include/object.h (working copy) @@ -517,6 +517,18 @@ /* Objects support nb_index in PyNumberMethods */ #define Py_TPFLAGS_HAVE_INDEX (1L17) +/* These flags are used to determine if a type is a subclass. */ +/* Uses bits 30-27. */ +#define Py_TPFLAGS_FAST_SUBCLASS_MASK (0x7800) +#define Py_TPFLAGS_FAST_SUBCLASS (1L27) +#define Py_TPFLAGS_INT_SUBCLASS (Py_TPFLAGS_FAST_SUBCLASS | 0x7000) +#define Py_TPFLAGS_LONG_SUBCLASS (Py_TPFLAGS_FAST_SUBCLASS | 0x6000) +#define Py_TPFLAGS_LIST_SUBCLASS (Py_TPFLAGS_FAST_SUBCLASS | 0x5000) +#define Py_TPFLAGS_TUPLE_SUBCLASS (Py_TPFLAGS_FAST_SUBCLASS | 0x4000) +#define Py_TPFLAGS_STRING_SUBCLASS (Py_TPFLAGS_FAST_SUBCLASS | 0x3000) +#define Py_TPFLAGS_UNICODE_SUBCLASS (Py_TPFLAGS_FAST_SUBCLASS | 0x2000) +#define Py_TPFLAGS_DICT_SUBCLASS (Py_TPFLAGS_FAST_SUBCLASS | 0x1000) + #define Py_TPFLAGS_DEFAULT ( \ Py_TPFLAGS_HAVE_GETCHARBUFFER | \
Re: [Python-Dev] no remaining issues blocking 2.5 release
On 8/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
It would be nice if someone could bytecompile Lib using
Tools/compiler/compile.py and then run the test suite. I'd do it
myself but can't spare the time at the moment (I started but ran
into what seems to be a gcc bug along the way).
Has this been done before?
# This code causes python to segfault
def foo(S):
all(x 42 for x in S)
# around Python/ceval.c 2167: x = (*v-ob_type-tp_iternext)(v);
# tp_iternext is NULL
I added the changes below to Lib/compiler/pycodegen.py which are
clearly wrong. It just crashes in a diff place. I think the changes
to genxpr inner may be close to correct. The changes to _makeClosure
and visitGenExpr are clearly wrong. I was just wondering how far it
would go. There are a bunch of differences. Some are the bytecode
optimizations or different ordering, but others are things dealing
with co_names, co_varnames.
Hopefully someone has time to look into this. Otherwise, it will have
to wait for 2.5.1
n
--
Index: Lib/compiler/pycodegen.py
===
--- Lib/compiler/pycodegen.py (revision 51305)
+++ Lib/compiler/pycodegen.py (working copy)
@@ -628,9 +628,9 @@
self.newBlock()
self.emit('POP_TOP')
-def _makeClosure(self, gen, args):
+def _makeClosure(self, gen, args, gen_outer=False):
frees = gen.scope.get_free_vars()
-if frees:
+if frees and not gen_outer:
for name in frees:
self.emit('LOAD_CLOSURE', name)
self.emit('BUILD_TUPLE', len(frees))
@@ -646,7 +646,7 @@
walk(node.code, gen)
gen.finish()
self.set_lineno(node)
-self._makeClosure(gen, 0)
+self._makeClosure(gen, 0, True)
# precomputation of outmost iterable
self.visit(node.code.quals[0].iter)
self.emit('GET_ITER')
@@ -655,6 +655,11 @@
def visitGenExprInner(self, node):
self.set_lineno(node)
# setup list
+after = self.newBlock()
+start = self.newBlock()
+self.setups.push((LOOP, start))
+self.emit('SETUP_LOOP', after)
+self.nextBlock(start)
stack = []
for i, for_ in zip(range(len(node.quals)), node.quals):
@@ -676,8 +681,12 @@
self.startBlock(cont)
self.emit('POP_TOP')
self.nextBlock(skip_one)
+self.emit('POP_TOP')
self.emit('JUMP_ABSOLUTE', start)
self.startBlock(anchor)
+self.emit('POP_BLOCK')
+self.setups.pop()
+self.nextBlock(after)
self.emit('LOAD_CONST', None)
def visitGenExprFor(self, node):
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 404 open ( +2) / 3376 closed (+16) / 3780 total (+18) Bugs: 860 open ( -1) / 6131 closed (+17) / 6991 total (+16) RFE : 229 open ( +1) / 235 closed ( +1) / 464 total ( +2) New / Reopened Patches __ option to leave tempfile.NamedTemporaryFile around on close (2006-08-10) http://python.org/sf/1537850 opened by djmdjm Patch to fix __index__() clipping (2006-08-11) CLOSED http://python.org/sf/1538606 opened by Travis Oliphant Patch cElementTree to export CurrentLineNumber (2006-08-11) http://python.org/sf/1538691 opened by Robin Bryce Replace unicode.__eq__ exceptions with a warning (2006-08-11) CLOSED http://python.org/sf/1538956 opened by M.-A. Lemburg Add readinto method to StringIO and cStringIO (2006-08-12) http://python.org/sf/1539381 opened by Alexander Belopolsky Backports from trunk to release24-maint (2006-08-15) http://python.org/sf/1540329 opened by flub tarfile __slots__ addition (2006-08-14) http://python.org/sf/1540385 opened by Brian Harring Patches for OpenBSD 4.0 (2006-08-15) http://python.org/sf/1540470 opened by djmdjm Use Py_ssize_t for rangeobject members (2006-08-15) http://python.org/sf/1540617 opened by Alexander Belopolsky except too broad (2006-08-15) http://python.org/sf/1540849 opened by Jim Jewett with is now a blockopener (2006-08-15) CLOSED http://python.org/sf/1540851 opened by Jim Jewett IOBinding overly broad except (2nd try) (2006-08-15) CLOSED http://python.org/sf/1540856 opened by Jim Jewett except too broad (2006-08-15) CLOSED http://python.org/sf/1540857 opened by Jim Jewett IOBinding broad except - try 3 (2006-08-15) CLOSED http://python.org/sf/1540859 opened by Jim Jewett CodeContext visibility (2006-08-15) http://python.org/sf/1540869 opened by Jim Jewett broken shortcut keys (2006-08-15) http://python.org/sf/1540874 opened by Jim Jewett make IDLE honor the quit() builtin (2006-08-15) CLOSED http://python.org/sf/1540892 opened by Jim Jewett Patches Closed __ Add notes on locale module changes to whatsnew25.tex (2006-08-03) http://python.org/sf/1534027 closed by akuchling Build ctypes on OpenBSD x86_64 (2006-08-08) http://python.org/sf/1536908 closed by theller Fix __index__() clipping really big numbers (2006-07-29) http://python.org/sf/1530738 closed by ncoghlan PyShell.recall - fix indentation logic (2006-07-25) http://python.org/sf/1528468 closed by kbk Patch to fix __index__() clipping (2006-08-11) http://python.org/sf/1538606 closed by nnorwitz Replace unicode.__eq__ exceptions with a warning (2006-08-11) http://python.org/sf/1538956 closed by lemburg Replace the ctypes internal '_as_parameter_' mechanism (2006-08-02) http://python.org/sf/1532975 closed by theller writelines() in bz2 module does not raise check for errors (2006-08-06) http://python.org/sf/1535500 closed by gbrandl trace.py on win32 has problems with lowercase drive names (2006-08-07) http://python.org/sf/1536071 closed by gbrandl Give Cookie.py its own _idmap (2006-07-13) http://python.org/sf/1521882 closed by gbrandl socket.gethostbyaddr fix for machines with incomplete DNS (2006-06-23) http://python.org/sf/1511317 closed by gbrandl with is now a blockopener (2006-08-15) http://python.org/sf/1540851 closed by kbk IOBinding overly broad except (2nd try) (2006-08-15) http://python.org/sf/1540856 closed by jimjjewett except too broad (2006-08-15) http://python.org/sf/1540857 closed by jimjjewett IOBinding broad except - try 3 (2006-08-15) http://python.org/sf/1540859 closed by jimjjewett make IDLE honor the quit() builtin (2006-08-15) http://python.org/sf/1540892 closed by kbk New / Reopened Bugs ___ 2nd issue with need for speed patch (2006-08-09) http://python.org/sf/1537167 opened by Robin Bryce Missing platform information in subprocess documentation (2006-08-09) CLOSED http://python.org/sf/1537195 opened by Aaron Bingham urllib2 httplib _read_chunked timeout (2006-08-09) http://python.org/sf/1537445 opened by devloop Installation on Windows Longhorn (2006-08-10) http://python.org/sf/1537601 opened by O.R.Senthil Kumaran import on cElementTree on Windows (2006-08-09) http://python.org/sf/1537685 reopened by thomasbhickey import on cElementTree on Windows (2006-08-09) http://python.org/sf/1537685 opened by Thomas B Hickey indent changes when copying command (2006-08-10) CLOSED http://python.org/sf/1538445 opened by mjd__ PyThreadState_SetAsyncExc bug (2006-08-11) http://python.org/sf/1538556 opened by ganges master pyo's are not overwritten by different optimization levels (2006-08-11)
[Python-Dev] Making 'python -t' the default.
Can I suggest making 'python -t' the default, in 2.6? It makes python warn about mixing tabs and spaces in indentation. In Py3k, '-tt' (the error-raising version) will be the default, instead. I see too many newsbies with problems they can't figure out because they mix tabs and spaces (usually not even consciously, but just because their editor isn't playing along.) There probably should be an option to turn the warning off again (although I won't fight for it ;) -- but I don't know what that option should be. -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making 'python -t' the default.
Thomas Wouters wrote: Can I suggest making 'python -t' the default, in 2.6? It makes python warn about mixing tabs and spaces in indentation. +1. In Py3k, '-tt' (the error-raising version) will be the default, instead. Or disallow tabs altogether. I see too many newsbies with problems they can't figure out because they mix tabs and spaces (usually not even consciously, but just because their editor isn't playing along.) There probably should be an option to turn the warning off again (although I won't fight for it ;) -- but I don't know what that option should be. Perhaps -T. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] no remaining issues blocking 2.5 release
On Tue, Aug 15, 2006 at 10:44:40PM -0400, Kurt B. Kaiser wrote: It would be nice if the key IDLE changes could make it to the What's New in Python X.X. If Andrew is interested, I could draft something for him. Sure! I can try to look through the IDLE NEWS file, but you'd certainly have a better idea of which changes are most significant to IDLE users. (You can commit your changes to whatsnew25.tex, module Anthony's trunk freeze in 12 hours or so, or just write plain text and let me add the LaTeX markup.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making 'python -t' the default.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 16, 2006, at 7:37 AM, Thomas Wouters wrote: Can I suggest making 'python -t' the default, in 2.6? It makes python warn about mixing tabs and spaces in indentation. In Py3k, '- tt' (the error-raising version) will be the default, +1. We even have Subversion hooks in our repository to reject any commits that have tabs in them (except for Makefiles and a few whitelisted 3rd-party apps that we don't want to reformat). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBROMUEXEjvBPtnXfVAQJSuQQAlU/FqiDhVUXKiIIaH91s0iyyd8/NgHMn fuA5fO06vcpAWxDvZtpmF8xAqGbN9AUh87iISDEEYUdpe1xrs1hly2QEJ5xIBnmB rF+3FfDZI+YKCkCHzHhG01jJBH6j/4pW0ZxUs4DAKz5os0o1xor7Yiy1sI/t1cVR Ra0m8ByDssE= =D4hn -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
Guido I worry that dropping the special allocator will be too slow. Greg Surely there's some compromise that would allow recently-used ints Greg to be kept around, but reclaimed if memory becomes low? Martin Hardly. The efficiency of the special-case allocator also comes Martin from the fact that it doesn't ever have to release memory. Just Martin try changing it to see what I mean. Wouldn't use of obmalloc offset much of that? Before obmalloc was available, the int free list was a huge win. Is it likely to be such a huge win today? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Greg Ewing schrieb: Martin v. Löwis wrote: We had this discussion before; if you use ob_size==0 to indicate that it's an int, this space isn't needed in a long int. What about int subclasses? It's what Guido proposes. It would still leave two types (perhaps three) at the C level, so C code might have to continue making conditional code depending on which of these it is. Also, Python code that dispatches by type still needs to make the distinction. I'm not sure that subclassing ints gives us much. We could make int and long final types, and then all we have to do is tweak type() and __class__ so that they always return the 'int' type. Alternatively, yes, there would be some minimal awareness of the two types in Python -- but nothing like we currently have; dispatching on exact type (which we discourage anyway) would be the only case. Would that be so bad? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
Neal Norwitz wrote: On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote: That penalty is already paid today. Much code dealing with ints has a type test whether it's an int or a long. If int and long become subtypes of each other or of some abstract type, performance will decrease even more because a subtype test is quite expensive if the object is neither int nor long (it has to traverse the entire base type hierarchy to find out its not inherited from int). I was playing around with a little patch to avoid that penalty. It doesn't take any additional memory, just a handful of bits we aren't using. :-) For the more common builtin types, it stores whether it's a subclass in tp_flags, so there's no function call necessary and it's a constant time operation. It was faster when doing simple stuff. Haven't thought much whether this is really worthwhile or not. This might als be helpful when exceptions have to inherit from BaseException in Py3k. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
[EMAIL PROTECTED] schrieb: Guido I worry that dropping the special allocator will be too slow. Greg Surely there's some compromise that would allow recently-used ints Greg to be kept around, but reclaimed if memory becomes low? Martin Hardly. The efficiency of the special-case allocator also comes Martin from the fact that it doesn't ever have to release memory. Just Martin try changing it to see what I mean. Wouldn't use of obmalloc offset much of that? Before obmalloc was available, the int free list was a huge win. Is it likely to be such a huge win today? That's my theory: it isn't a huge win. Guido has another theory: it's still faster. Only benchmarking can tell. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
Guido van Rossum schrieb: I'm not sure that subclassing ints gives us much. We could make int and long final types, and then all we have to do is tweak type() and __class__ so that they always return the 'int' type. I don't think this can work - there would be too many ways for the real types to leak, anyway. People would come up with hacks like reload(sys), and then complain that they have to use such hacks. Alternatively, yes, there would be some minimal awareness of the two types in Python -- but nothing like we currently have; dispatching on exact type (which we discourage anyway) would be the only case. Would that be so bad? I thought it was the ultimate goal of PEP 237 to unify int and long, in all respects. I'll do some benchmarking. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.4 2.5 beta 3 crash
We've been working on fixing some exception handling bugs in IronPython where we differ from CPython. Along the way we ran into this issue which causes CPython to crash when the code below is run. It crashes on both 2.4 and 2.5 beta 3. The code's technically illegal, but it probably shouldn't crash either :) def test(): for abc in range(10): try: pass finally: try: continue except: pass test() ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking the int allocator (Was: Type of range object members)
[EMAIL PROTECTED] schrieb:
Wouldn't use of obmalloc offset much of that? Before obmalloc was
available, the int free list was a huge win. Is it likely to be such a huge
win today?
I have now some numbers. For the attached t.py, the unmodified svn
python gives
Test 1 3.25420880318
Test 2 1.86433696747
and the one with the attached patch gives
Test 1 3.45080399513
Test 2 2.09729003906
So there apparently is a performance drop on int allocations of about
5-10%.
On this machine (P4 3.2GHz) I could not find any difference in pystones
from this patch.
Notice that this test case is extremely focused on measuring int
allocation (I just noticed I should have omitted the for loop in
the second case, though).
Regards,
Martin
import time
s = time.time()
i = 0
while i 1000:
i+=1
print Test 1,time.time()-s
s = time.time()
i = 0
for i in range(1000):
pass
print Test 2,time.time()-s
Index: Objects/intobject.c
===
--- Objects/intobject.c (Revision 51320)
+++ Objects/intobject.c (Arbeitskopie)
@@ -13,54 +13,8 @@
/* Integers are quite normal objects, to make object handling uniform.
(Using odd pointers to represent integers would save much space
but require extra checks for this special case throughout the code.)
- Since a typical Python program spends much of its time allocating
- and deallocating integers, these operations should be very fast.
- Therefore we use a dedicated allocation scheme with a much lower
- overhead (in space and time) than straight malloc(): a simple
- dedicated free list, filled when necessary with memory from malloc().
-
- block_list is a singly-linked list of all PyIntBlocks ever allocated,
- linked via their next members. PyIntBlocks are never returned to the
- system before shutdown (PyInt_Fini).
-
- free_list is a singly-linked list of available PyIntObjects, linked
- via abuse of their ob_type members.
*/
-#define BLOCK_SIZE 1000/* 1K less typical malloc overhead */
-#define BHEAD_SIZE 8 /* Enough for a 64-bit pointer */
-#define N_INTOBJECTS ((BLOCK_SIZE - BHEAD_SIZE) / sizeof(PyIntObject))
-
-struct _intblock {
- struct _intblock *next;
- PyIntObject objects[N_INTOBJECTS];
-};
-
-typedef struct _intblock PyIntBlock;
-
-static PyIntBlock *block_list = NULL;
-static PyIntObject *free_list = NULL;
-
-static PyIntObject *
-fill_free_list(void)
-{
- PyIntObject *p, *q;
- /* Python's object allocator isn't appropriate for large blocks. */
- p = (PyIntObject *) PyMem_MALLOC(sizeof(PyIntBlock));
- if (p == NULL)
- return (PyIntObject *) PyErr_NoMemory();
- ((PyIntBlock *)p)-next = block_list;
- block_list = (PyIntBlock *)p;
- /* Link the int objects together, from rear to front, then return
- the address of the last int object in the block. */
- p = ((PyIntBlock *)p)-objects[0];
- q = p + N_INTOBJECTS;
- while (--q p)
- q-ob_type = (struct _typeobject *)(q-1);
- q-ob_type = NULL;
- return p + N_INTOBJECTS - 1;
-}
-
#ifndef NSMALLPOSINTS
#define NSMALLPOSINTS 257
#endif
@@ -96,14 +50,9 @@
return (PyObject *) v;
}
#endif
- if (free_list == NULL) {
- if ((free_list = fill_free_list()) == NULL)
- return NULL;
- }
- /* Inline PyObject_New */
- v = free_list;
- free_list = (PyIntObject *)v-ob_type;
- PyObject_INIT(v, PyInt_Type);
+ v = PyObject_NEW(PyIntObject, PyInt_Type);
+ if (v == NULL)
+ return NULL;
v-ob_ival = ival;
return (PyObject *) v;
}
@@ -127,19 +76,13 @@
static void
int_dealloc(PyIntObject *v)
{
- if (PyInt_CheckExact(v)) {
- v-ob_type = (struct _typeobject *)free_list;
- free_list = v;
- }
- else
- v-ob_type-tp_free((PyObject *)v);
+ v-ob_type-tp_free((PyObject *)v);
}
static void
int_free(PyIntObject *v)
{
- v-ob_type = (struct _typeobject *)free_list;
- free_list = v;
+ PyObject_Del(v);
}
long
@@ -1138,12 +1081,8 @@
int ival;
#if NSMALLNEGINTS + NSMALLPOSINTS 0
for (ival = -NSMALLNEGINTS; ival NSMALLPOSINTS; ival++) {
- if (!free_list (free_list = fill_free_list()) == NULL)
- return 0;
- /* PyObject_New is inlined */
- v = free_list;
- free_list = (PyIntObject *)v-ob_type;
- PyObject_INIT(v, PyInt_Type);
+ v = PyObject_NEW(PyIntObject, PyInt_Type);
+ if (!v) return 0;
v-ob_ival = ival;
small_ints[ival + NSMALLNEGINTS] = v;
}
@@ -1154,14 +1093,8 @@
void
PyInt_Fini(void)
{
- PyIntObject *p;
- PyIntBlock *list, *next;
- int i;
- unsigned int ctr;
- int bc, bf; /* block
Re: [Python-Dev] IDLE patches - bugfix or not?
python.org/sf/1540874 -- broken shortcut keys. On windows, only one entry per menu can be reached with the same shortcut letter, so advertising others is just an attractive nuisance. I'm not sure that other systems wouldn't be able to use the hidden shortcuts. On 8/15/06, Anthony Baxter [EMAIL PROTECTED] wrote: Tough call. I guess it depends on the other systems - I will try this on Linux at least, and see if it works there. If it's broken everywhere, then changing it would seem the least offensive choice. Thank you. Kurt Kaiser: I would have been inclined to make the other choice, i.e. 'p' as the hotkey for print, rather than the rarely used save copy as. The existing functionality (at least on windows) is that p brings up a Path Browser window; print and save copy are *both* masked. I agree that p *should* be for print, but I didn't want to remove an existing (working) shortcut this late. So I just stopped advertising the (unusable) shortcut on print. I did add the (currently unused) 'y' for save copy as, which I suppose might be considered a feature. Simply removing the claimed but broken shortcut would indeed fix the attractive nuisance problem. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] no remaining issues blocking 2.5 release
Neal Norwitz [EMAIL PROTECTED] wrote: On 8/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote: It would be nice if someone could bytecompile Lib using Tools/compiler/compile.py and then run the test suite. Has this been done before? Obviously not. :-) # This code causes python to segfault def foo(S): all(x 42 for x in S) Hmm, it seems to work for me. The bytecode generated by Lib/compiler is the same as the normal compiler. Do you have a full test case? Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking the int allocator (Was: Type of range object members)
On 8/16/06, Martin v. Löwis [EMAIL PROTECTED] wrote: I have now some numbers. For the attached t.py, the unmodified svn python gives Test 1 3.25420880318 Test 2 1.86433696747 and the one with the attached patch gives Test 1 3.45080399513 Test 2 2.09729003906 So there apparently is a performance drop on int allocations of about 5-10%. On this machine (P4 3.2GHz) I could not find any difference in pystones from this patch. Notice that this test case is extremely focused on measuring int allocation (I just noticed I should have omitted the for loop in the second case, though). I think the test isn't hardly focused enough on int allocation. I wonder if you could come up with a benchmark that repeatedly allocates 100s of 1000s of ints and then deletes them? What if it also allocates other small objects so the ints become more fragmented? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 2.5 beta 3 crash
Dino Viehland [EMAIL PROTECTED] wrote: We've been working on fixing some exception handling bugs in IronPython where we differ from CPython. Along the way we ran into this issue which causes CPython to crash when the code below is run. It crashes on both 2.4 and 2.5 beta 3. The code's technically illegal, but it probably shouldn't crash either :) def test(): for abc in range(10): try: pass finally: try: continue except: pass test() It also reliably crashes 2.3, though I don't see anything in there as being illegal, but maybe I don't understand the langauge as well as I think I do. Note that there is another segfaulting bug in CPython with regards to threads that was recently closed, but which is still a problem: http://python.org/sf/780714 Does IronPython survive in that case? - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 2.5 beta 3 crash
Josiah Carlson wrote: Dino Viehland [EMAIL PROTECTED] wrote: We've been working on fixing some exception handling bugs in IronPython where we differ from CPython. Along the way we ran into this issue which causes CPython to crash when the code below is run. It crashes on both 2.4 and 2.5 beta 3. The code's technically illegal, but it probably shouldn't crash either :) def test(): for abc in range(10): try: pass finally: try: continue except: pass test() It also reliably crashes 2.3, though I don't see anything in there as being illegal, but maybe I don't understand the langauge as well as I think I do. continue is not supported inside a finally clause. If you put the continue directly there or into the except clause, the compiler will tell you. It looks like nobody thought about that corner case when writing the compiler check for continue. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
On 8/15/06, Neal Norwitz [EMAIL PROTECTED] wrote: I was playing around with a little patch to avoid that penalty. It doesn't take any additional memory, just a handful of bits we aren't using. :-) For the more common builtin types, it stores whether it's a subclass in tp_flags, so there's no function call necessary and it's a constant time operation. It was faster when doing simple stuff. Haven't thought much whether this is really worthwhile or not. I like it! I wonder if you should use another bit for inherits from BaseException. That would make catching and raising exceptions a bit faster. It applies cleanly to py3k -- perhaps you should just check it in there? +1 from me! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
At 11:46 PM 8/15/2006 -0700, Neal Norwitz wrote: On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote: That penalty is already paid today. Much code dealing with ints has a type test whether it's an int or a long. If int and long become subtypes of each other or of some abstract type, performance will decrease even more because a subtype test is quite expensive if the object is neither int nor long (it has to traverse the entire base type hierarchy to find out its not inherited from int). I was playing around with a little patch to avoid that penalty. It doesn't take any additional memory, just a handful of bits we aren't using. :-) For the more common builtin types, it stores whether it's a subclass in tp_flags, so there's no function call necessary and it's a constant time operation. It was faster when doing simple stuff. Haven't thought much whether this is really worthwhile or not. It seems to me that you could drop the FAST_SUBCLASS bit, since none of the other bits will be set if it is not a subclass of a builtin. That would free up one flag bit -- perhaps usable for that BaseException flag Guido wants. :) (Of course, if you can't inherit from both BaseException and one of the other builtin types, it can just be another enumeration value within the bit mask.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking the int allocator (Was: Type of range object members)
Guido van Rossum schrieb: I think the test isn't hardly focused enough on int allocation. I wonder if you could come up with a benchmark that repeatedly allocates 100s of 1000s of ints and then deletes them? The question is: where to store them? In a pre-allocated list, or in a growing list? def t3(): m = [0]*10 s = time.time() i = 0 for i in xrange(100): for k in xrange(10): m[k] = k print Test 3,time.time()-s def t4(): s = time.time() i = 0 for i in xrange(100): m = [] for k in xrange(10): m.append(k) print Test 4,time.time()-s This is 100s of 1000s of ints in the inner loop; test 3 puts them into a pre-allocated list, test 4 discards the list each time and lets it grow. What if it also allocates other small objects so the ints become more fragmented? This allocator doesn't bother much about fragmentation: it's constant-time most of the time on allocation, and often on deallocation (especially when the memory is fragmented). Also, it's hard to find an object that is as small as an int; I think a one-element tuple applies: def t5(): s = time.time() i = 0 for i in xrange(100): m = [] for k in xrange(10): m.append((k,)) print Test 5,time.time()-s The timings, for the best of three runs: Py2.5 +obmalloc-for-intslowdown Test 3 1.8s 2.1s 15% Test 4 3.6s 3.8s 5% test 5 7.5s 7.5s 0 Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 2.5 beta 3 crash
def test(): for abc in range(10): try: pass finally: try: pass except: pass test() does not raise a segmentation fault. On Wed, 16 Aug 2006, Josiah Carlson wrote: Dino Viehland [EMAIL PROTECTED] wrote: We've been working on fixing some exception handling bugs in IronPython where we differ from CPython. Along the way we ran into this issue which causes CPython to crash when the code below is run. It crashes on both 2.4 and 2.5 beta 3. The code's technically illegal, but it probably shouldn't crash either :) def test(): for abc in range(10): try: pass finally: try: continue except: pass test() It also reliably crashes 2.3, though I don't see anything in there as being illegal, but maybe I don't understand the langauge as well as I think I do. Note that there is another segfaulting bug in CPython with regards to threads that was recently closed, but which is still a problem: http://python.org/sf/780714 Does IronPython survive in that case? - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/allison%40shasta.stanford.edu -- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
Neal Norwitz schrieb: I was playing around with a little patch to avoid that penalty. It doesn't take any additional memory, just a handful of bits we aren't using. :-) There are common schemes that allow constant-time issubclass tests, although they do require more memory: 1. give each base class a small unique number, starting with 1 (0 means no number has been assigned). Give each class a bitmap of all base classes, plus a field for the maximum-numbered base class. Then, def issubclass(C, B): return B.classnum and (B.classnum C.maxbasenum) and\ bit_set(C.basenums, B.classnum) Supports multiple inheritance, space requirement linear with the number of classes that are used as base classes. Numbering should recycle class numbers when a class is gced. 2. restrict optimization to single-inheritance. Give each class a depth (distance from object, 0 for object and multiply-inherited classes). Also give each class an array of bases, ordered by depth. Then, def issubclass(C, B): if not C.depth: return expensive_issubclass(C, B) return B.depth C.depth and (C.bases[B.depth] is B) Space requirement is linear with the depth of the class (but I think tp_mro could be used, if the formula is changed to (C.bases[C.depth-B.depth] is B)) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 2.5 beta 3 crash
Yeah, continue inside the finally block is illegal. If you don't have the extra try/except nesting then continue is detected as a syntax error. -Original Message- From: Dennis Allison [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 16, 2006 10:22 AM To: Josiah Carlson Cc: Dino Viehland; python-dev@python.org Subject: Re: [Python-Dev] 2.4 2.5 beta 3 crash def test(): for abc in range(10): try: pass finally: try: pass except: pass test() does not raise a segmentation fault. On Wed, 16 Aug 2006, Josiah Carlson wrote: Dino Viehland [EMAIL PROTECTED] wrote: We've been working on fixing some exception handling bugs in IronPython where we differ from CPython. Along the way we ran into this issue which causes CPython to crash when the code below is run. It crashes on both 2.4 and 2.5 beta 3. The code's technically illegal, but it probably shouldn't crash either :) def test(): for abc in range(10): try: pass finally: try: continue except: pass test() It also reliably crashes 2.3, though I don't see anything in there as being illegal, but maybe I don't understand the langauge as well as I think I do. Note that there is another segfaulting bug in CPython with regards to threads that was recently closed, but which is still a problem: http://python.org/sf/780714 Does IronPython survive in that case? - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/allison%40shasta.sta nford.edu -- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 2.5 beta 3 crash
IronPython actually enables / disables stack overflow checking through either a command line option or by calling sys.setrecursionlimit. By default we have no recursion limit. Without those command line options we'll end up having the CLR throw an unrecoverable stack overflow exception (and the process will be terminated). It's a little bit better than a seg fault, but not much. With stack overflow checking enabled we'll actually catch the recursion for this and throw a RuntimeError stating maximum recursion depth reached. -Original Message- From: Josiah Carlson [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 16, 2006 10:11 AM To: Dino Viehland; python-dev@python.org Subject: Re: [Python-Dev] 2.4 2.5 beta 3 crash Dino Viehland [EMAIL PROTECTED] wrote: We've been working on fixing some exception handling bugs in IronPython where we differ from CPython. Along the way we ran into this issue which causes CPython to crash when the code below is run. It crashes on both 2.4 and 2.5 beta 3. The code's technically illegal, but it probably shouldn't crash either :) def test(): for abc in range(10): try: pass finally: try: continue except: pass test() It also reliably crashes 2.3, though I don't see anything in there as being illegal, but maybe I don't understand the langauge as well as I think I do. Note that there is another segfaulting bug in CPython with regards to threads that was recently closed, but which is still a problem: http://python.org/sf/780714 Does IronPython survive in that case? - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
Martin v. Löwis wrote: Neal Norwitz schrieb: I was playing around with a little patch to avoid that penalty. It doesn't take any additional memory, just a handful of bits we aren't using. :-) There are common schemes that allow constant-time issubclass tests, although they do require more memory: 1. give each base class a small unique number, starting with 1 (0 means no number has been assigned). Give each class a bitmap of all base classes, plus a field for the maximum-numbered base class. Then, def issubclass(C, B): return B.classnum and (B.classnum C.maxbasenum) and\ bit_set(C.basenums, B.classnum) Supports multiple inheritance, space requirement linear with the number of classes that are used as base classes. Numbering should recycle class numbers when a class is gced. 2. restrict optimization to single-inheritance. Give each class a depth (distance from object, 0 for object and multiply-inherited classes). Also give each class an array of bases, ordered by depth. Then, def issubclass(C, B): if not C.depth: return expensive_issubclass(C, B) return B.depth C.depth and (C.bases[B.depth] is B) Space requirement is linear with the depth of the class (but I think tp_mro could be used, if the formula is changed to (C.bases[C.depth-B.depth] is B)) Two more: 3. Use a global cache of class objects that caches the issubclass() lookups. This is only amortized constant time, but easy to implement and has a few other nice features such as e.g. enabling traversal of the complete class inheritance forest (or tree if you just have new-style classes). Use weak references to the classes if you want to be able to GC them. 4. Freeze classes after they are constructed, meaning that all attributes from base-classes get bound to the inheriting class. This also speeds up method lookups considerably. Works great with classic classes, I'm not sure about new-style classes using e.g. staticmethods, slots and the like. mxTools has an implementation for classic classes called freeze(). If you add special attributes such as ._issubclass_XYZ in the process, issubclass() would then be a single attribute lookup which is constant time. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 16 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] no remaining issues blocking 2.5 release
A.M. Kuchling [EMAIL PROTECTED] writes:
On Tue, Aug 15, 2006 at 10:44:40PM -0400, Kurt B. Kaiser wrote:
It would be nice if the key IDLE changes could make it to the What's New
in Python X.X. If Andrew is interested, I could draft something for him.
Sure! I can try to look through the IDLE NEWS file, but you'd
certainly have a better idea of which changes are most significant to
IDLE users.
(You can commit your changes to whatsnew25.tex, module Anthony's trunk
freeze in 12 hours or so, or just write plain text and let me add the
LaTeX markup.)
%=
\subsection{The IDLE Integrated Development Environment}
Calltips have been greatly improved and a class attribute listbox
provides completions.
When the Shell cursor is on a previous command, Enter retrieves
that command. But instead of replacing the input line, the previous
command is appended, preserving indentation. If there is an active
selection, the selection will be appended to the input line.
IDLE does a tabnanny and syntax check before every F5/Run.
A number of changes were made to improve Mac OSX compatibility.
The advanced keybinding dialog was enabled, allowing multiple
complex key combinations to be bound to a given IDLE event.
A number of improvements were made to the colorizer.
The 'with' statement is now a Code Context block opener.
IDLE honors the new quit() and exit() functions.
Keybindings were added for del-word-left and del-word-right.
%
--
KBK
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
Martin v. Löwis wrote: Greg Ewing schrieb: Also it means you'd pay a penalty every time you access it That penalty is already paid today. You'd still have that penalty, *plus* the overhead of bit masking to get at the value. Maybe that wouldn't be noticeable among all the other overheads, though. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making 'python -t' the default.
Georg Brandl wrote: Or disallow tabs altogether. -1. I'd be annoyed if Python started telling me I wasn't allowed to write my source the way my preferred editor (BBEdit) works best. Very annoyed. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5: recently introduced sgmllib regexp bug hangs Python
Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C
won't kill the process, CPU usage sits near 100%) under some
circumstances. There's a test case here:
http://python.org/sf/1541697
The problem isn't seen if you read the whole file at once (or almost the
whole file at once). (But that doesn't make it a non-bug, AFAICS.)
I'm not sure what the problem is, but presumably the relevant part of the
patch is this:
+starttag = re.compile(r'[a-zA-Z][-_.:a-zA-Z0-9]*\s*('
+r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*'
+r'(\'[^\']*\'|[^]*|[-a-zA-Z0-9./,:;+*%?!$\(\)[EMAIL PROTECTED]'
+r'[][\-a-zA-Z0-9./,:;+*%?!$\(\)_#=~\'@]*(?=[\s/])))?'
+r')*\s*/?\s*(?=[])')
The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a
regression introduced by his recent sgmllib patches, and has not yet been
applied) does NOT fix the problem.
If nobody has time to fix this, perhaps rev 47154 should be reverted?
commit message for -r47154:
SF bug #1504333: sgmlib should allow angle brackets in quoted values
(modified patch by Sam Ruby; changed to use separate REs for start and end
tags to reduce matching cost for end tags; extended tests; updated to
avoid
breaking previous changes to support IPv6 addresses in unquoted attribute
values)
John
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [wwwsearch-general] 2.5: recently introduced sgmllib regexp bug hangs Python
On Thu, 17 Aug 2006, John J Lee wrote: [...] If nobody has time to fix this, perhaps rev 47154 should be reverted? I should have put it more strongly: I think it *should* in fact be reverted if nobody has time to fix it before the release candidate / final release of 2.5. The revision in question is the most recent commit to sgmllib.py and certainly appears completely localised to that module. And a hung interpreter is worse than failing to parse some HTML, IMHO. [...] commit message for -r47154: SF bug #1504333: sgmlib should allow angle brackets in quoted values (modified patch by Sam Ruby; changed to use separate REs for start and end tags to reduce matching cost for end tags; extended tests; updated to avoid breaking previous changes to support IPv6 addresses in unquoted attribute values) [...] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 2.5 beta 3 crash
Thanks Dino.
The attached patch should fix the problem. Once RC1 is cut, I'll
check this in unless someone beats me to it. Since the compiler
changed, I can't backport this. If someone wants to make a similar
fix for 2.4 go for it.
n
--
On 8/16/06, Dino Viehland [EMAIL PROTECTED] wrote:
We've been working on fixing some exception handling bugs in IronPython where
we differ from CPython. Along the way we ran into this issue which causes
CPython to crash when the code below is run. It crashes on both 2.4 and 2.5
beta 3. The code's technically illegal, but it probably shouldn't crash either
:)
def test():
for abc in range(10):
try: pass
finally:
try:
continue
except:
pass
test()
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
Index: Python/compile.c
===
--- Python/compile.c (revision 51334)
+++ Python/compile.c (working copy)
@@ -143,7 +143,8 @@
PyFutureFeatures *c_future; /* pointer to module's __future__ */
PyCompilerFlags *c_flags;
- int c_interactive; /* true if in interactive mode */
+ unsigned int c_in_finally : 1; /* true if in finally clause */
+ unsigned int c_interactive : 1; /* true if in interactive mode */
int c_nestlevel;
struct compiler_unit *u; /* compiler state for current block */
@@ -2288,10 +2289,16 @@
compiler_continue(struct compiler *c)
{
static const char LOOP_ERROR_MSG[] = 'continue' not properly in loop;
+ static const char IN_FINALLY_ERROR_MSG[] =
+ 'continue' not supported inside 'finally' clause;
int i;
if (!c-u-u_nfblocks)
return compiler_error(c, LOOP_ERROR_MSG);
+
+ if (c-c_in_finally)
+ return compiler_error(c, IN_FINALLY_ERROR_MSG);
+
i = c-u-u_nfblocks - 1;
switch (c-u-u_fblock[i].fb_type) {
case LOOP:
@@ -2306,8 +2313,8 @@
ADDOP_JABS(c, CONTINUE_LOOP, c-u-u_fblock[i].fb_block);
break;
case FINALLY_END:
- return compiler_error(c,
- 'continue' not supported inside 'finally' clause);
+ /* XXX(nnorwitz): should have already been handled above. */
+ return compiler_error(c, IN_FINALLY_ERROR_MSG);
}
return 1;
@@ -2367,7 +2374,9 @@
compiler_use_next_block(c, end);
if (!compiler_push_fblock(c, FINALLY_END, end))
return 0;
+ c-c_in_finally = 1;
VISIT_SEQ(c, stmt, s-v.TryFinally.finalbody);
+ c-c_in_finally = 0;
ADDOP(c, END_FINALLY);
compiler_pop_fblock(c, FINALLY_END, end);
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 2.5 beta 3 crash
On Aug 17, 2006, at 1:26 AM, Neal Norwitz wrote: Thanks Dino. The attached patch should fix the problem. Once RC1 is cut, I'll check this in unless someone beats me to it. Since the compiler changed, I can't backport this. If someone wants to make a similar fix for 2.4 go for it. The attached patch is incorrect. It breaks the following perfectly valid code. Probably what would be right is to move (with appropriate changes) the while loop in the FINALLY_TRY case to outside the entire switch statement. Thus, if LOOP is reached, yay, add the jump, return success. If the FINALLY_END is reached first, boo, fail. If it's a FINALLY_TRY or EXCEPT, continue the loop. def test(): try: pass finally: for abc in range(10): continue James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
On 8/16/06, Phillip J. Eby [EMAIL PROTECTED] wrote: It seems to me that you could drop the FAST_SUBCLASS bit, since none of the other bits will be set if it is not a subclass of a builtin. That would free up one flag bit -- perhaps usable for that BaseException flag Guido wants. :) :-) Right, I'm not using the bit currently. I was thinking that it would be interesting to change the CheckExact versions to also use this. It's a little more work, but you lose the second comparison for Check. I expect that it would be slower, but I was just curious. So with the patch we currently have: #define PyInt_CheckExact(op) ((op)-ob_type == PyInt_Type) #define PyInt_Check(op) (PyInt_CheckExact(op) || \ PyType_FastSubclass((op)-ob_type, Py_TPFLAGS_INT_SUBCLASS)) But we could have something like: #define PyInt_CheckExact(op) (PyType_FastClass(op,Py_TPFLAGS_INT_CLASS)) #define PyInt_Check(op) (PyType_FastSubclass(op,Py_TPFLAGS_INT_SUBCLASS)) It would change the CheckExact()s from: op-ob_type == global-variable, to: op-ob_type CONSTANT == CONSTANT. Check would be the same as the CheckExact, just with different constants. The Check version would then drop the || condition. I might play with this at the sprint next week. It does seem to make sense to do BaseException too. It will take 4 or 5 bits to handle the current ones plus BaseException, which we can easily spare in tp_flags. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
