Re: [Python-Dev] Type of range object members
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.
No, the penalty gets smaller if there is only a single type.
For example, abstract.c now has
if (res (!PyInt_Check(res) !PyLong_Check(res))) {
PyErr_Format(PyExc_TypeError,
__int__ returned non-int (type
%.200s),
res-ob_type-tp_name);
Py_DECREF(res);
return NULL;
}
Currently, if a long int is returned, it performs two subtype tests.
If the long type is dropped, the second test can go away. In this
specific code, there is no penalty for a representation flag, since
the value is not accessed.
Code that wants to support both int and long and needs the value
often does PyLong_AsLong these days, which will support int as well.
This currently reads
if (vv == NULL || !PyLong_Check(vv)) {
if (vv != NULL PyInt_Check(vv))
return PyInt_AsLong(vv);
PyErr_BadInternalCall();
return -1;
}
Notice that this has two checks if this is an int, and both are subtype
checks. With a single type, this would become
if (vv == NULL || !PyInt_Check(vv)) {
PyErr_BadInternalCall();
return -1;
}
if (!vv-ob_size)
return PyInt_AsLong(vv);
Actually, the implementation of PyInt_AsLong might get inlined;
it currently starts with a third PyInt_Check.
So overall, I would expect that a single type would improve performance,
not decrease it.
As you say, any change is likely not noticeable in performance, though,
either way.
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
Neal Norwitz schrieb: 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. Hmm. I don't see the for the FAST_SUBCLASS bit still. I would set the relevant bit in the type object itself, and then have #define PyInt_CheckExact(op) ((op)-ob_type == PyInt_Type) #define PyInt_Check(op) \ PyType_FastSubclass((op)-ob_type, Py_TPFLAGS_INT_SUBCLASS) Then, in inherit_special, I'd do type-tp_flags |= base-tp_flags Py_TPFLAGS_FAST_SUBCLASS_MASK; So you would have a pointer comparison for the exact check, and the bit mask check for the subtype check. It's likely that the pointer comparison is still more efficient: It does *not*, normally, need to read a global variable to get the address of PyInt_Type. Currently, on x86, with non-PIC code on Linux, the pointer check compiles as cmpl$PyInt_Type, 4(%eax) ; %eax is the object where the linker fills the address of PyInt_Type into the machine instruction. OTOH, the access to the flags compiles as movl4(%eax), %eax ; %eax is the object movl84(%eax), %eax andl$2013265920, %eax cmpl$2013265920, %eax Even with PIC code, the address check is still more efficient: movl[EMAIL PROTECTED](%ecx), %eax cmpl%eax, 4(%edx) ; %edx is the object 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] Benchmarking the int allocator (Was: Type of range object members)
On 8/16/06, Martin v. Löwis [EMAIL PROTECTED] wrote: 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 agrowing list?Or you can expose Py_INCREF to Python code. I'm thinking about that for big-mem tests anyway ;-) -- 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] recently introduced sgmllib regexp bughangs Python
John J Lee wrote: If nobody has time to fix this, perhaps rev 47154 should be reverted? yes please. /F ___ 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 Thursday 17 August 2006 12:13, John J Lee wrote: 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. Well, it's a bit late for the release candidate :-) but I agree - if it can't be fixed before 2.5 final, it should be reverted. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
John J Lee wrote: Looks like revision 47154 introduced a regexp that hangs Python Revision 47155 was a similar change to the 2.4 branch. -- Benji York Senior Software Engineer Zope Corporation ___ 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] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
The release candidate is done - we creep ever closer to 2.5 final. Hoooray! All future 2.5 releases (including 2.5 final!) will now be done from the new release25-maint trunk (svn+ssh://[EMAIL PROTECTED]/python/branches/release25-maint) - so any changes you want to see after 2.5c1 and before 2.5 final will need to be applied to that branch as well as to the trunk. From now until the final release, I think we should say no checkins to the release25-maint branch without either myself or Neal signing off on it - for safety's sake, I'd recommend you email either the list here, or if you have to send private email, send it to both of us. If this policy offends you, please reply and let me know what you'd prefer. Right now, I don't really care about the trunk - although if you break the buildbot, I'm sure Neal will be very cranky at you :-) Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] RELEASED Python 2.5 (release candidate 1)
On behalf of the Python development team and the Python community, I'm happy to announce the first RELEASE CANDIDATE of Python 2.5. This is not yet the final release - it is not suitable for production use. It is being released to solicit feedback and hopefully expose bugs, as well as allowing you to determine how changes in 2.5 might impact you. As a release candidate, this is one of your last chances to test the new code in 2.5 before the final release. *Please* try this release out and let us know about any problems you find. In particular, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows and Universal Mac OSX installers) are available from the 2.5 website: http://www.python.org/2.5/ As of this release, Python 2.5 is now in *feature freeze*. Unless absolutely necessary, no functionality changes will be made between now and the final release of Python 2.5. The plan now is to let the release candidate shake out any last-minute bugs in Python 2.5, leading to a 2.5 final release in early September. PEP 356 includes the schedule and will be updated as the schedule evolves. At this point, any testing you can do would be greatly, greatly appreciated. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New modules added include hashlib, ElementTree, sqlite3, wsgiref, uuid and ctypes. In addition, a new profiling module cProfile was added. Enjoy this new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpC2XcpH5jvO.pgp Description: 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] [Python-checkins] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
Anthony Baxter schrieb: Right now, I don't really care about the trunk - although if you break the buildbot [...] Thanks for reminding me. I just added a buildbot builder for the 2.5 branch (actually, the builder was already there, but I connected it with the web server), so you can now see the status of the 2.5 branch at http://www.python.org/dev/buildbot/2.5/ 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] [Python-checkins] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
On Friday 18 August 2006 00:47, Martin v. Löwis wrote: Anthony Baxter schrieb: Right now, I don't really care about the trunk - although if you break the buildbot [...] Thanks for reminding me. I just added a buildbot builder for the 2.5 branch (actually, the builder was already there, but I connected it with the web server), so you can now see the status of the 2.5 branch at http://www.python.org/dev/buildbot/2.5/ You beat me to it by a couple of minutes - I'd added the entry to the master.cfg file but hadn't updated the apache config yet. Anthoiny -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] Fixing 2.5 windows buildbots
I'd like to fix the two build failures that the Windows buildbots show for the 2.5 trunk. I'm not quite sure what the OpenSSL failure is, yet, but the sqlite error should be fixable with the patch below. Ok to work on this? Martin Index: Tools/buildbot/external.bat === --- Tools/buildbot/external.bat (Revision 51339) +++ Tools/buildbot/external.bat (Arbeitskopie) @@ -28,6 +28,7 @@ cd tk8.4.12\win nmake -f makefile.vc TCLDIR=..\..\tcl8.4.12 nmake -f makefile.vc TCLDIR=..\..\tcl8.4.12 INSTALLDIR=..\..\tcltk install + cd ..\.. ) @rem sqlite ___ 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] Fixing 2.5 windows buildbots
On 8/17/06, Martin v. Löwis [EMAIL PROTECTED] wrote: I'd like to fix the two build failures that the Windows buildbots show for the 2.5 trunk. I'm not quite sure what the OpenSSL failure is, yet, but the sqlite error should be fixable with the patch below. Ok to work on this? Please do. ___ 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] uuid tests failing on Windows
test_uuid1 and test_uuid4 fail consistently on Windows; apparently, the generated universally-unique identifiers aren't even unique within a set of 1000 identifiers. Can somebody please fix that? If not, should we remove the uuid module as being immature? 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] uuid tests failing on Windows
Martin v. Löwis wrote: test_uuid1 and test_uuid4 fail consistently on Windows; apparently, the generated universally-unique identifiers aren't even unique within a set of 1000 identifiers. Can somebody please fix that? If not, should we remove the uuid module as being immature? Patch #1541863 supposedly solves this. 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] [Python-checkins] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
On Thu, Aug 17, 2006 at 09:07:53PM +0200, Georg Brandl wrote: Jack Diederich wrote: Looks good to me. While you are on that page do you want to change l = PyList_New(3); x = PyInt_FromLong(1L); PySequence_SetItem(l, 0, x); Py_DECREF(x); x = PyInt_FromLong(2L); PySequence_SetItem(l, 1, x); Py_DECREF(x); x = PyString_FromString(three); PySequence_SetItem(l, 2, x); Py_DECREF(x); to l = PyList_New(3); x = PyInt_FromLong(1L); PyList_SetItem(l, 0, x); x = PyInt_FromLong(2L); PyList_SetItem(l, 1, x); x = PyString_FromString(three); PyList_SetItem(l, 2, x); The example code causes segfaults and probably always has (at last to 2.2) Interesting! From a naive POV, the docs' example is quite right. The segfault occurs because list_ass_item Py_DECREFs the old item (which segfaults because the old items are NULL in a newly created list). PyList_SetItem does a Py_XDECREF. The docs to PyList_New, however, do not explicitly say that the new list must only be filled using PyList_SetItem. So please, someone, decide what's broken here! The docs, this is from a thread yesterday and today on c.l.py http://groups.google.com/group/comp.lang.python/browse_frm/thread/158c8797ee2dccab/ -Jack ___ 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] uuid tests failing on Windows
Georg Brandl schrieb: Can somebody please fix that? If not, should we remove the uuid module as being immature? Patch #1541863 supposedly solves this. Ah, good. I think it should go in. 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] uuid tests failing on Windows
On Thu, 17 Aug 2006 22:06:24 +0200, \Martin v. Löwis\ [EMAIL PROTECTED] wrote: Georg Brandl schrieb: Can somebody please fix that? If not, should we remove the uuid module as being immature? Patch #1541863 supposedly solves this. Ah, good. I think it should go in. Uh, I may be misunderstanding here, but that patch looks like it changes that part of the test for test_uuid4 to stop calling uuid4 and call uuid1 instead? ___ 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] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
Georg Brandl wrote: The example code causes segfaults and probably always has (at last to 2.2) Interesting! From a naive POV, the docs' example is quite right. except that it doesn't work? the problem is that it's using a *high-level* API to manipulate objects that are not properly initialized. the documentation should be fixed (doctest for the C API, anyone?) /F ___ 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] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
Georg Brandl wrote: Okay, now that I stumbled over and read the c.l.py thread, I think that we should * remove the faulty example (the correct one is already in there) * add a note to PyList_New that the new list must be filled with items before handing it to Python code or using it with abstract APIs such as PySequence_SetItem. a blurb at the beginning of the abstract API section that mentions that the abstract API should only be used on fully initialized Python objects might also be a good idea. /F ___ 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] Sprints next week at Google
This is a reminder (I don't think anyone else sent one, I sure hope not). We are holding 4 days of sprints next week at Google offices in NY city and Mt View, CA. These are open if you'd like to attend. It would be very helpful to pre-register on the wiki as we can notify security and generally make things easier. Of the full-time Googlers, Guido and Alex will be sprinting in CA and Jeremy and I will be sprinting in NY. http://wiki.python.org/moin/GoogleSprint Cheers, 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
Re: [Python-Dev] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
Fredrik Lundh wrote: Georg Brandl wrote: The example code causes segfaults and probably always has (at last to 2.2) Interesting! From a naive POV, the docs' example is quite right. except that it doesn't work? I wanted to say: From looking at the docs only, it should be alright. the problem is that it's using a *high-level* API to manipulate objects that are not properly initialized. The docs for PyList_New don't tell the user that the list object isn't properly initialized, etc. the documentation should be fixed Clearly. I'll do that (if the release managers give permission) 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] uuid tests failing on Windows
[EMAIL PROTECTED] schrieb: Patch #1541863 supposedly solves this. Ah, good. I think it should go in. Uh, I may be misunderstanding here, but that patch looks like it changes that part of the test for test_uuid4 to stop calling uuid4 and call uuid1 instead? You misunderstand indeed: the chunk reads -for u in [uuid.uuid1() for i in range(1000)]: +for u in [uuid.uuid4() for i in range(1000)]: so it currently calls uuid1, and will call uuid4 when patched. test_uuid4 should have never failed, except that it uses uuid1 as the uniqueness test. 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] uuid tests failing on Windows
On Thu, 17 Aug 2006 23:58:27 +0200, \Martin v. Löwis\ [EMAIL PROTECTED] wrote: You misunderstand indeed: the chunk reads (...) it currently calls uuid1, and will call uuid4 when patched. test_uuid4 should have never failed, except that it uses uuid1 as the uniqueness test. Whooops. I must have hit the reverse diff button in Emacs before reading it. Thanks for the correction. ___ 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
Hi Neal, On Wed, Aug 16, 2006 at 10:26:09PM -0700, Neal Norwitz wrote: @@ -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); Without more inspection, I'd say that this looks like it won't do the right thing about nested finally's, as in: ... finally: try: ... finally: ... continue A bientot, Armin ___ 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
High-level remark: this seems to need more unit tests. Perhaps TDD (test-driven design) would be the best approach to obtaining a correct patch? --Guido On 8/17/06, Armin Rigo [EMAIL PROTECTED] wrote: Hi Neal, On Wed, Aug 16, 2006 at 10:26:09PM -0700, Neal Norwitz wrote: @@ -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); Without more inspection, I'd say that this looks like it won't do the right thing about nested finally's, as in: ... finally: try: ... finally: ... continue A bientot, Armin ___ 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/guido%40python.org -- --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
On Fri, Aug 18, 2006 at 12:26:33AM +0200, Armin Rigo wrote:
Without more inspection, I'd say that this looks like it won't do the
right thing about nested finally's, as in:
I guess it'll have to loop back up through the block stack:
for (j=i- 1; j=0; j--) {
switch (c-u-u_fblock[j].fb_type) {
case FINALLY_TRY:
raise error;
case LOOP:
j=0; /* Exit the loop */
break;
default:
break;
}
}
--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] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
Fixing docs is fine - please checkin. ___ 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] uuid tests failing on Windows
On Friday 18 August 2006 06:06, Martin v. Löwis wrote: Georg Brandl schrieb: Can somebody please fix that? If not, should we remove the uuid module as being immature? Patch #1541863 supposedly solves this. Ah, good. I think it should go in. Sounds fine to me. Making buildbot less red == goodness. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
