Re: [Python-Dev] int/float freelists vs pymalloc
On 2008-02-13 08:02, Andrew MacIntyre wrote: Christian Heimes wrote: Andrew MacIntyre wrote: I tried a LIFO stack implementation (though I won't claim to have done it well), and found it slightly slower than no freelist at all. The advantage of such an approach is that the known size of the stack makes deallocating excess objects easy (and thus no need for sys.compact_free_list() ). I've tried a single linked free list myself. I used the ob_type field to daisy chain the int and float objects. Although the code was fairly short it was slightly slower than an attempt without a free list at all. pymalloc is fast. It's very hard to beat it though. I'm speculating that CPU cache effects can make these differences. The performance of the current trunk float freelist is depressing, given that the same strategy works so well for ints. I seem to recall Tim Peters paying a lot of attention to cache effects when he went over the PyMalloc code before the 2.3 release, which would contribute to its performance. A fixed size LIFO array like PyFloatObject *free_list[PyFloat_MAXFREELIST] increased the speed slightly. IMHO a value of about 80-200 floats and ints is realistic for most apps. More objects in the free lists could keep too many pymalloced areas occupied. I tested the updated patch you added to issue 2039. With the int freelist set to 500 and the float freelist set to 100, its about the same as the no-freelist version for my tests, but PyBench shows the simple float arithmetic to be about 10% better. I'm inclined to set the int LIFO a bit larger than you suggest, simply as ints are so commonly used - hence the value of 500 I used. Floats are much less common by comparison. Even an int LIFO of 500 is only going to tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant enough that I can't see a need for a compaction routine. A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on 64bit). It is difficult to tell what good limits for free lists should be. This depends a lot on the application focus, e.g. a financial application is going to need lots of floats, while a word processor or parser will need more integers. I think the main difference between the current free list implementation and Christian's patches is that the current implementation bypasses pymalloc altogether and allocates the objects directly using the system malloc(). The objects in the free list then cannot keep artificially keep pymalloc pools alive. Furthermore, the current free list implementation works by allocating 1k chunks of memory for more than just one object whenever it finds that the free list is empty. Christian's patches and your free list removal patch, cause all allocations to be done via pymalloc. Christian's free list can also result in nearly empty pymalloc pools to stay alive due to the use of a linked list rather than an array of objects. Finally (and I don't know if you've missed that), the integer implementation uses sharing for small integers. In the current implementation all integers between -5 and 257 are only ever allocated once and then reused whenever an integer in this range is needed. The shared integers are not subject to any of the extra free list handling or pymalloc overhead. This results in a significant boost, since integers in this range are *very* common and also causes the comparison between integers and floats to become biased - floats don't have this optimization. I still think that dropping the free lists can be worthwhile, but pymalloc would need to get further optimizations to give better performance for often requested size classes (the 16 byte class on 32bit architectures, the 24 byte class on 64bit architectures). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 13 2008) 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,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] int/float freelists vs pymalloc
Christian Heimes wrote: Andrew MacIntyre wrote: I tested the updated patch you added to issue 2039. With the int freelist set to 500 and the float freelist set to 100, its about the same as the no-freelist version for my tests, but PyBench shows the simple float arithmetic to be about 10% better. I'm inclined to set the int LIFO a bit larger than you suggest, simply as ints are so commonly used - hence the value of 500 I used. Floats are much less common by comparison. Even an int LIFO of 500 is only going to tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant enough that I can't see a need for a compaction routine. A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on 64bit). I added some profiling code to lists and dicts. Increasing the free list size didn't make a difference for lists and dicts. I used 200 instead of 80 for the free list size and the ratio of reuse / allocation increased minimal. Every entry in the free list costs 4 bytes for the pointer and 16 bytes for the int or float object on 32bit including padding on 8byte address boundaries. For 500 objects that's about 9kb which isn't a big deal nowadays. But - andere there is always a but - every object may keep a 4kb arena alive. The 4kB entities are pools (for allocation size classes); arenas are the 256kB chunks of memory PyMalloc gets from the platform malloc. One active allocation in any size class from a pool in an arena will prevent release of an arena. Unless a program is creating and destroying lots of ints at once a larger number doesn't make a performance difference. I'd stick to 80, maybe 120 for ints for now. My thinking was that the price ( I was forgetting that the 12 byte int object still gets a 16 byte allocation) was small enough that being generous minimises surprises in production code; after all, we've been doing this research with synthetic microbenchmarks. When you get right down to it, the object freelist offers such a small gain that its real value is in the noise in many cases despite being measurable. After all, PyMalloc is nothing but a highly optimised package of freelists with the malloc()/realloc()/free() API... It just does a bit more book-keeping than the simple freelists used for ints and floats (which predate PyMalloc being added to the source tree, let alone being enabled by default). I'm not that interested in debating the detail of exactly how big the prospective LIFO freelists are - I just want to see the situation resolved with maximum utilisation of memory for minimum performance penalty. To that end, +1 from me for accepting your revised patch against issue 2039. In addition, unless there are other reasons to retain it, I would be suggesting that the freelist compaction infrastructure you introduced in r60567 be removed for lack of practical utility (assuming acceptance of your patch). Cheers, Andrew. -- - Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ 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] Why is there to Lib/test/test_int.py?
I want to add test cases for int.__format__(), and I went looking for Lib/test/test_int.py. I've added tests into Lib/test/test_long.py, so I assumed there was an int version, but no. Is there any particular reason for that, and are there int tests elsewhere? If not, I'll add test_int.py, but I want to make sure that's the right thing to do. Thanks. Eric. ___ 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] int/float freelists vs pymalloc
On 2008-02-13 12:56, Andrew MacIntyre wrote: I'm not that interested in debating the detail of exactly how big the prospective LIFO freelists are - I just want to see the situation resolved with maximum utilisation of memory for minimum performance penalty. To that end, +1 from me for accepting your revised patch against issue 2039. In addition, unless there are other reasons to retain it, I would be suggesting that the freelist compaction infrastructure you introduced in r60567 be removed for lack of practical utility (assuming acceptance of your patch). If we're down to voting, here's my vote: +1 on removing the freelists from ints and floats, but not the small int sharing optimization +1 on focusing on improving pymalloc to handle int and float object allocations even better -1 on changing the freelist implementations to use pymalloc for allocation of the freelist members instead of malloc, since this would potentially lead to pools (and arenas) being held alive by just a few objects - in the worst case a whole arena (256kB) for just one int object (14 bytes on 32bit platforms). Eventually, all freelists should be removed, unless there's a significant performance loss. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 13 2008) 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,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] Adding __format__ to classic classes
When backporting PEP 3101, do we want to add __format__ to classic classes? If so, could someone give me a pointer on how to implement this? I don't see where to hook it up. Thanks. Eric. ___ 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] Mutable sequence .sort() signature
On Tue, Feb 12, 2008 at 08:19:27PM -0800, Guido van Rossum wrote: [on the 'What's New in 3.0' document] I think that's a good start. Andrew Kuchling can always move it later if that section becomes too crowded or uneven. I won't be able to work on the 3.0 document in time for 3.0 final (assuming that's in the next year) because I'm too busy with work, 2.x tasks, applications, conference-related things, etc. If someone wants to take it over for 3.0, now's your chance! --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] int/float freelists vs pymalloc
M.-A. Lemburg wrote: On 2008-02-13 12:56, Andrew MacIntyre wrote: I'm not that interested in debating the detail of exactly how big the prospective LIFO freelists are - I just want to see the situation resolved with maximum utilisation of memory for minimum performance penalty. To that end, +1 from me for accepting your revised patch against issue 2039. In addition, unless there are other reasons to retain it, I would be suggesting that the freelist compaction infrastructure you introduced in r60567 be removed for lack of practical utility (assuming acceptance of your patch). If we're down to voting, here's my vote: +1 on removing the freelists from ints and floats, but not the small int sharing optimization +1 on focusing on improving pymalloc to handle int and float object allocations even better -1 on changing the freelist implementations to use pymalloc for allocation of the freelist members instead of malloc, since this would potentially lead to pools (and arenas) being held alive by just a few objects - in the worst case a whole arena (256kB) for just one int object (14 bytes on 32bit platforms). Eventually, all freelists should be removed, unless there's a significant performance loss. Sigh... things are never as simple as they seem... Prompted by your comment about the small int sharing, which I was aware of and was not addressing because I was assuming that its value was unimpeachable, I've been doing some more testing with this and the freelists. I don't have time to write it up tonight, but I've concluded that my original test scripts and other tests weren't showing the real performance of the various approaches. Platform (architecture, compiler etc) oddities differences complicate life too... Cheers, Andrew. - Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ 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] int/float freelists vs pymalloc
M.-A. Lemburg wrote: +1 on removing the freelists from ints and floats, but not the small int sharing optimization +1 on focusing on improving pymalloc to handle int and float object allocations even better -1 on changing the freelist implementations to use pymalloc for allocation of the freelist members instead of malloc, since this would potentially lead to pools (and arenas) being held alive by just a few objects - in the worst case a whole arena (256kB) for just one int object (14 bytes on 32bit platforms). Eventually, all freelists should be removed, unless there's a significant performance loss. The small ints (and small longs in py3k) should definitely stay. They make a huge speed impact and they reduce the memory usage a tiny bit, too. I like to keep the free lists for basic types, too. They bring a measurable speedup. My profiling has shown that the small free lists safe about 70% malloc and PyObject_INIT() calls for lists. In Python 3.0 the long free list increases the general speed of int operations by 10%+. +1 on replacing int's and float's block allocation schema with pymalloc +1 on keeping small int optimization +1 on focusing on improving pymalloc to handle int and float object allocations even better +1 on adding a small int, float and long (py3k only) free list with about 80 to 160 objects each +1 for MvL's idea to compact all free lists during a full gc sweep. Every type with a free list gets a new function PySpam_ClearFreeList() which frees all items in the type's free list. The latter counteracts the potential issue with arenas. By the way objects are always aligned at 8 byte address boundaries. A 12 or 4 bytes object occupies 16 bytes. Christian ___ 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] Adding __format__ to classic classes
On Feb 13, 2008 5:28 AM, Eric Smith [EMAIL PROTECTED] wrote: When backporting PEP 3101, do we want to add __format__ to classic classes? If so, could someone give me a pointer on how to implement this? I don't see where to hook it up. You just have to get the '__format__' attribute and call it if it exists. Isn't that how you do it for new-style classes too? -- --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] Why is there to Lib/test/test_int.py?
I think most int tests are probably in test_types.py. If you were to create test_int.py now it would probably interfere with the renaming of test_long.py to test_int.py in the py3k branch (eventually). On Feb 13, 2008 4:12 AM, Eric Smith [EMAIL PROTECTED] wrote: I want to add test cases for int.__format__(), and I went looking for Lib/test/test_int.py. I've added tests into Lib/test/test_long.py, so I assumed there was an int version, but no. Is there any particular reason for that, and are there int tests elsewhere? If not, I'll add test_int.py, but I want to make sure that's the right thing to do. -- --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] Adding __format__ to classic classes
Guido van Rossum wrote:
On Feb 13, 2008 5:28 AM, Eric Smith [EMAIL PROTECTED] wrote:
When backporting PEP 3101, do we want to add __format__ to classic
classes? If so, could someone give me a pointer on how to implement
this? I don't see where to hook it up.
You just have to get the '__format__' attribute and call it if it
exists. Isn't that how you do it for new-style classes too?
I'm thinking that I need to add a __format__ to the most base old
style class, similar to how I added it for object itself (in
object_methods[]). As I currently have it in 2.6, I can call __format__
on a new style class, but not a classic class:
$ ./python.exe
Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
class newstyle(object): pass
...
class oldstyle: pass
...
newstyle().__format__('')
'__main__.newstyle object at 0x3d4d90'
oldstyle().__format__('')
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: oldstyle instance has no attribute '__format__'
So my question is, to what do I need to add __format__ so that classic
classes will have a default implementation?
My knowledge of how classic classes are implemented is weak, so I don't
know where to add this.
Eric.
___
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] Small configure typo?
With zsh when I try to autocomplete the ./configure options I get this: _arguments:comparguments:303: invalid option definition: --enable-universalsdk[SDKDIR][Build against Mac OS X 10.4u SDK (ppc/i386)] Should this be: --enable-universalsdk[=SDKDIR] ? (Note the = ) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ For wouldst thou not carve at my Soul with thine sword of Supreme Truth? ___ 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] Adding __format__ to classic classes
On Feb 13, 2008 9:48 AM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 5:28 AM, Eric Smith [EMAIL PROTECTED] wrote:
When backporting PEP 3101, do we want to add __format__ to classic
classes? If so, could someone give me a pointer on how to implement
this? I don't see where to hook it up.
You just have to get the '__format__' attribute and call it if it
exists. Isn't that how you do it for new-style classes too?
I'm thinking that I need to add a __format__ to the most base old
style class, similar to how I added it for object itself (in
object_methods[]). As I currently have it in 2.6, I can call __format__
on a new style class, but not a classic class:
$ ./python.exe
Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
class newstyle(object): pass
...
class oldstyle: pass
...
newstyle().__format__('')
'__main__.newstyle object at 0x3d4d90'
oldstyle().__format__('')
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: oldstyle instance has no attribute '__format__'
So my question is, to what do I need to add __format__ so that classic
classes will have a default implementation?
My knowledge of how classic classes are implemented is weak, so I don't
know where to add this.
Ah, I see.
There is no root class of the classic class hierarchy (that's why
we're nixing it in 3.0 :-).
The customary pattern, used everywhere from len() to setattr(), is to
first check for an (instance) attribute with a special name
(__format__), and if that isn't found, to use a hard-coded fallback
implementation. For len() the fallback raises an exception; for
setattr() it puts the value in the instance __dict__.
--
--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] __new__ deprecation
What __new__ deprecation warning? On Feb 13, 2008 11:50 AM, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote: People, where can I find rationale/background on the __new__ deprecation warning in 2.6 (and I assume it's totally different in 3.0)? I could not find anything about it in http://docs.python.org/dev/3.0/whatsnew/3.0.html or http://docs.python.org/dev/whatsnew/2.6.html Cheers, -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Teachers open the door, but you must enter by yourself. -Chinese Proverb ___ 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
[Python-Dev] 2.5.2 freeze upcoming
The 2.5 maintenance branch will be frozen tomorrow (Thursday) around 7:00 UTC. Please don't make any changes to the branch after that point unless you are directly involved in the release process. If there are any issues that you think should be considered before the 2.5.2 release, please assign them to me with high priority. 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] Mutable sequence .sort() signature
On Feb 12, 2008 8:39 PM, Kurt B. Kaiser [EMAIL PROTECTED] wrote: I'd say in PEP3100. Here's a patch: http://bugs.python.org/issue2092 The suggested patch does not actually point to any discussion or rationale for why this change was made; it just contains a pointer to this thread (which is not very useful). So, while I hate to open a can of worms: but what's the rationale here? Without the cmp argument, what's the concise way to spell something like sort a list of floats by absolute value? It'd be nice to have a stock example to help users rewrite their code to work with 3.0. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ 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] Small configure typo?
On Feb 13, 2008 9:24 AM, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote: With zsh when I try to autocomplete the ./configure options I get this: _arguments:comparguments:303: invalid option definition: --enable-universalsdk[SDKDIR][Build against Mac OS X 10.4u SDK (ppc/i386)] Should this be: --enable-universalsdk[=SDKDIR] ? (Note the = ) Thanks, Jeroen! That bug has been bothering me for ages but I could never figure out what was upsetting zsh. Figures it was something simple. =) Fixed in r60765 on the trunk and r60766 for 2.5. -Brett -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ For wouldst thou not carve at my Soul with thine sword of Supreme Truth? ___ 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/brett%40python.org ___ 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] __new__ deprecation
People, where can I find rationale/background on the __new__ deprecation warning in 2.6 (and I assume it's totally different in 3.0)? I could not find anything about it in http://docs.python.org/dev/3.0/whatsnew/3.0.html or http://docs.python.org/dev/whatsnew/2.6.html Cheers, -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Teachers open the door, but you must enter by yourself. -Chinese Proverb ___ 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] Py3k and asyncore/asynchat
A while back, I volunteered to update asyncore and asynchat for py3k. I posted a patch, and in response to feedback posted a more complicated patch+modification. Both versions have been languishing at http://bugs.python.org/issue1563 for a couple of months now without any further feedback or action. I need some more experienced member of the community to take some sort of action: reviews and suggestions are welcome, as is advice about which version I should continue on with. Committing the patch would also be acceptable :) ___ 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] Mutable sequence .sort() signature
On Feb 13, 2008 12:09 PM, Daniel Stutzbach [EMAIL PROTECTED] wrote: Without the cmp argument, what's the concise way to spell something like sort a list of floats by absolute value? It'd be nice to have a stock example to help users rewrite their code to work with 3.0. L.sort(key=abs) -- --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] Adding __format__ to classic classes
Guido van Rossum wrote:
On Feb 13, 2008 9:48 AM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 5:28 AM, Eric Smith [EMAIL PROTECTED] wrote:
When backporting PEP 3101, do we want to add __format__ to classic
classes? If so, could someone give me a pointer on how to implement
this? I don't see where to hook it up.
You just have to get the '__format__' attribute and call it if it
exists. Isn't that how you do it for new-style classes too?
I'm thinking that I need to add a __format__ to the most base old
style class, similar to how I added it for object itself (in
object_methods[]). As I currently have it in 2.6, I can call __format__
on a new style class, but not a classic class:
$ ./python.exe
Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
class newstyle(object): pass
...
class oldstyle: pass
...
newstyle().__format__('')
'__main__.newstyle object at 0x3d4d90'
oldstyle().__format__('')
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: oldstyle instance has no attribute '__format__'
So my question is, to what do I need to add __format__ so that classic
classes will have a default implementation?
My knowledge of how classic classes are implemented is weak, so I don't
know where to add this.
Ah, I see.
There is no root class of the classic class hierarchy (that's why
we're nixing it in 3.0 :-).
The customary pattern, used everywhere from len() to setattr(), is to
first check for an (instance) attribute with a special name
(__format__), and if that isn't found, to use a hard-coded fallback
implementation. For len() the fallback raises an exception; for
setattr() it puts the value in the instance __dict__.
Much to my surprise, this already works:
format(oldstyle(), '+^50s')
'+__main__.oldstyle instance at 0x3d91f8+'
So I guess it's a moot point. I'm using the same code as I use in 3.0,
where I call:
meth = _PyType_Lookup(Py_TYPE(value), format_str);
where format_str is __format__ interned. And I'm getting a value back
for old style classes.
Eric.
___
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] Adding __format__ to classic classes
On Feb 13, 2008 12:07 PM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 9:48 AM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 5:28 AM, Eric Smith [EMAIL PROTECTED] wrote:
When backporting PEP 3101, do we want to add __format__ to classic
classes? If so, could someone give me a pointer on how to implement
this? I don't see where to hook it up.
You just have to get the '__format__' attribute and call it if it
exists. Isn't that how you do it for new-style classes too?
I'm thinking that I need to add a __format__ to the most base old
style class, similar to how I added it for object itself (in
object_methods[]). As I currently have it in 2.6, I can call __format__
on a new style class, but not a classic class:
$ ./python.exe
Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
class newstyle(object): pass
...
class oldstyle: pass
...
newstyle().__format__('')
'__main__.newstyle object at 0x3d4d90'
oldstyle().__format__('')
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: oldstyle instance has no attribute '__format__'
So my question is, to what do I need to add __format__ so that classic
classes will have a default implementation?
My knowledge of how classic classes are implemented is weak, so I don't
know where to add this.
Ah, I see.
There is no root class of the classic class hierarchy (that's why
we're nixing it in 3.0 :-).
The customary pattern, used everywhere from len() to setattr(), is to
first check for an (instance) attribute with a special name
(__format__), and if that isn't found, to use a hard-coded fallback
implementation. For len() the fallback raises an exception; for
setattr() it puts the value in the instance __dict__.
Much to my surprise, this already works:
format(oldstyle(), '+^50s')
'+__main__.oldstyle instance at 0x3d91f8+'
So I guess it's a moot point. I'm using the same code as I use in 3.0,
where I call:
meth = _PyType_Lookup(Py_TYPE(value), format_str);
where format_str is __format__ interned. And I'm getting a value back
for old style classes.
Eric.
But now try overriding __format__(). The 3.0 code uses
_PyType_Lookup() which is not traversing the class dicts for classic
classes, so it won't find __format__ overrides.
--
--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] __new__ deprecation
-On [20080213 21:02], Guido van Rossum ([EMAIL PROTECTED]) wrote: What __new__ deprecation warning? Yes, sorry, I realized after sending that it might be a bit obtuse. With 2.6: DeprecationWarning: object.__new__() takes no parameters return object.__new__(cls, uri) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ I am the impossibility... ___ 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] Adding __format__ to classic classes
Guido van Rossum wrote: Much to my surprise, this already works: format(oldstyle(), '+^50s') '+__main__.oldstyle instance at 0x3d91f8+' So I guess it's a moot point. I'm using the same code as I use in 3.0, where I call: meth = _PyType_Lookup(Py_TYPE(value), format_str); where format_str is __format__ interned. And I'm getting a value back for old style classes. Eric. But now try overriding __format__(). The 3.0 code uses _PyType_Lookup() which is not traversing the class dicts for classic classes, so it won't find __format__ overrides. Okay, I see and understand that issue. But looking at len or getattr, I don't see how to generalize it to __format__. __len__ and __getattr__ have special support in the classes, with cl_getattr, tp_getattr, etc. I hate to be dense, but could you point me to some code that does something similar but looks up the method by name? Thanks for your time. Eric. ___ 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] Adding __format__ to classic classes
Nick Coghlan wrote: Eric Smith wrote: I hate to be dense, but could you point me to some code that does something similar but looks up the method by name? I was going to suggest __enter__/__exit__, but that code relies mainly on existing opcodes and just does an attribute lookup rather than explicitly bypassing the instance dictionary. However, the source code for cPickle may provide some ideas (when it looks up _reduce__/__getstate__/etc). Those do look promising. Thanks! Eric. ___ 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] Adding __format__ to classic classes
Eric Smith wrote: I hate to be dense, but could you point me to some code that does something similar but looks up the method by name? I was going to suggest __enter__/__exit__, but that code relies mainly on existing opcodes and just does an attribute lookup rather than explicitly bypassing the instance dictionary. However, the source code for cPickle may provide some ideas (when it looks up _reduce__/__getstate__/etc). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] __new__ deprecation
The message means just what it says. :-) There's no point in calling object.__new__() with more than a class parameter, and any code that did so was just dumping those args into a black hole. The only time when it makes sense for object.__new__() to ignore extra arguments is when it's not being overridden, but __init__ *is* being overridden -- then you have a completely default __new__ and the checking of constructor arguments is relegated to __init__. The purpose of all this is to catch the error in a call like object(42) which (again) passes an argument that is not used. This is often a symptom of a bug in your program. --Guido On Feb 13, 2008 12:19 PM, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote: -On [20080213 21:02], Guido van Rossum ([EMAIL PROTECTED]) wrote: What __new__ deprecation warning? Yes, sorry, I realized after sending that it might be a bit obtuse. With 2.6: DeprecationWarning: object.__new__() takes no parameters return object.__new__(cls, uri) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ I am the impossibility... -- --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] Adding __format__ to classic classes
On Feb 13, 2008 2:20 PM, Eric Smith [EMAIL PROTECTED] wrote: Nick Coghlan wrote: Eric Smith wrote: I hate to be dense, but could you point me to some code that does something similar but looks up the method by name? I was going to suggest __enter__/__exit__, but that code relies mainly on existing opcodes and just does an attribute lookup rather than explicitly bypassing the instance dictionary. However, the source code for cPickle may provide some ideas (when it looks up _reduce__/__getstate__/etc). Those do look promising. Thanks! Or look in classobject.c itself; e.g. instance_str(). -- --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] Adding __format__ to classic classes
Guido van Rossum wrote:
On Feb 13, 2008 2:20 PM, Eric Smith [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Eric Smith wrote:
I hate to be dense, but could you point me to some code that does
something similar but looks up the method by name?
I was going to suggest __enter__/__exit__, but that code relies mainly
on existing opcodes and just does an attribute lookup rather than
explicitly bypassing the instance dictionary.
However, the source code for cPickle may provide some ideas (when it
looks up _reduce__/__getstate__/etc).
Those do look promising. Thanks!
Or look in classobject.c itself; e.g. instance_str().
It uses a static helper function instance_getattr(), which while it
looks like what I want, I can't get to.
So I've come up with the following. I haven't checked for leaks yet,
but at least it appears to do what I want, for both classic and
new-style classes. I'm still porting over test cases from 3.0, so I'm
not convinced this is correct, yet.
/* Check for a __format__ method. */
meth = PyObject_GetAttr(value, str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
else {
meth = _PyType_Lookup(Py_TYPE(value), str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
else {
PyErr_Format(PyExc_TypeError,
Type %.100s doesn't define __format__,
Py_TYPE(value)-tp_name);
goto done;
}
}
___
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] Error in post-revprop-change hook in svn
I mistyped Jeroen's name so I edited the log message. But I got the following error message in the process:: svn: 'post-revprop-change' hook failed; no error output available The change still occurred, though. Anybody with access to the svn hooks know what is going on? -Brett ___ 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] Adding __format__ to classic classes
On Feb 13, 2008 2:57 PM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 2:20 PM, Eric Smith [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Eric Smith wrote:
I hate to be dense, but could you point me to some code that does
something similar but looks up the method by name?
I was going to suggest __enter__/__exit__, but that code relies mainly
on existing opcodes and just does an attribute lookup rather than
explicitly bypassing the instance dictionary.
However, the source code for cPickle may provide some ideas (when it
looks up _reduce__/__getstate__/etc).
Those do look promising. Thanks!
Or look in classobject.c itself; e.g. instance_str().
It uses a static helper function instance_getattr(), which while it
looks like what I want, I can't get to.
Well, it just implements PyObject_GetAttr for classic class instances...
So I've come up with the following. I haven't checked for leaks yet,
but at least it appears to do what I want, for both classic and
new-style classes. I'm still porting over test cases from 3.0, so I'm
not convinced this is correct, yet.
/* Check for a __format__ method. */
meth = PyObject_GetAttr(value, str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
else {
You'd need PyErr_Clear() here the way this is written. But the
following call is redundant -- if that _PyType_Lookup() call finds
something, PyObject_GetAttr() will have found that too (or something
else).
meth = _PyType_Lookup(Py_TYPE(value), str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
else {
PyErr_Format(PyExc_TypeError,
Type %.100s doesn't define __format__,
Py_TYPE(value)-tp_name);
goto done;
}
}
Since PyObject_GetAttr() sets an AttributeError exception already, I
question the benefit of setting a different exception.
--
--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] int/float freelists vs pymalloc
Christian Heimes wrote: By the way objects are always aligned at 8 byte address boundaries. A 12 or 4 bytes object occupies 16 bytes. Maybe pymalloc should be enhanced so it can cope with certain odd-sized objects, such as 12 bytes? -- 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] Adding __format__ to classic classes
[slight mailer problem, this might show up as a dupe. sorry]
Guido van Rossum wrote:
On Feb 13, 2008 2:57 PM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 2:20 PM, Eric Smith [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
However, the source code for cPickle may provide some ideas (when it
looks up _reduce__/__getstate__/etc).
Those do look promising. Thanks!
Or look in classobject.c itself; e.g. instance_str().
It uses a static helper function instance_getattr(), which while it
looks like what I want, I can't get to.
Well, it just implements PyObject_GetAttr for classic class instances...
So I've come up with the following. I haven't checked for leaks yet,
but at least it appears to do what I want, for both classic and
new-style classes. I'm still porting over test cases from 3.0, so I'm
not convinced this is correct, yet.
/* Check for a __format__ method. */
meth = PyObject_GetAttr(value, str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
else {
You'd need PyErr_Clear() here the way this is written.
Okay.
But the
following call is redundant -- if that _PyType_Lookup() call finds
something, PyObject_GetAttr() will have found that too (or something
else).
meth = _PyType_Lookup(Py_TYPE(value), str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
else {
PyErr_Format(PyExc_TypeError,
Type %.100s doesn't define __format__,
Py_TYPE(value)-tp_name);
goto done;
}
}
Yes, but what's the or something else, and is it the right thing? Are
you saying I should call _PyType_Lookup first? But that's how I
started: if I do it that way, I can't override __format__ in a classic
class. As the code stands (PyObject_GetAttr then _PyType_Lookup), it's
definitely true that _PyType_Lookup will succeed when PyObject_GetAttr
will have failed.
Or should the logic be:
if is-new-style-class(Py_TYPE(value)):
lookup method with _PyType_Lookup(Py_TYPE(value))
else:
lookup method with PyObject_GetAttr(value)
And if so, how to test for is-new-style-class?
Sorry to be wasting your time, but I'm don't understand all of the
issues trying to support both new and classic classes in C. I think
I'll get the rest of PEP 3101 working, then come back to this issue.
It's pretty well contained. I'll spend some time understanding
classobject.c's implementation. It just seems like it shouldn't be this
hard to call a method (if it exists), given an instance.
I think my confusion leads to this problem (if in fact it's a problem):
format(object, '')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: __format__() takes exactly 1 argument (0 given)
format(object(), '')
'object object at 0x307408'
^D
Which works in the py3k branch.
Since PyObject_GetAttr() sets an AttributeError exception already, I
question the benefit of setting a different exception.
Agreed.
___
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] Py3k and asyncore/asynchat
It's a big patch, but I'll try applying it to the current py3k branch -- does it apply? -- and try a few things with it. I'm concerned about how well it behaves with things like Medusa (which probably needs its own py3k update). Bill ___ 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] int/float freelists vs pymalloc
Christian Heimes wrote: By the way objects are always aligned at 8 byte address boundaries. A 12 or 4 bytes object occupies 16 bytes. No, with PyMalloc a 4 byte object occupies 8 bytes (see the comments at the top of Objects/obmalloc.c). Cheers, Andrew. -- - Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ 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] Adding __format__ to classic classes
On Feb 13, 2008 1:42 PM, Eric Smith [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Much to my surprise, this already works: format(oldstyle(), '+^50s') '+__main__.oldstyle instance at 0x3d91f8+' So I guess it's a moot point. I'm using the same code as I use in 3.0, where I call: meth = _PyType_Lookup(Py_TYPE(value), format_str); where format_str is __format__ interned. And I'm getting a value back for old style classes. Eric. But now try overriding __format__(). The 3.0 code uses _PyType_Lookup() which is not traversing the class dicts for classic classes, so it won't find __format__ overrides. Okay, I see and understand that issue. But looking at len or getattr, I don't see how to generalize it to __format__. __len__ and __getattr__ have special support in the classes, with cl_getattr, tp_getattr, etc. I hate to be dense, but could you point me to some code that does something similar but looks up the method by name? I'm not sure if it'll be exactly analogous, but you might look at __trunc__ and math.trunc for inspiration. -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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] Adding __format__ to classic classes
Oops, sorry for the spam. I didn't see that there were already answers in the rest of the thread. :-( On Feb 13, 2008 9:25 PM, Jeffrey Yasskin [EMAIL PROTECTED] wrote: On Feb 13, 2008 1:42 PM, Eric Smith [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Much to my surprise, this already works: format(oldstyle(), '+^50s') '+__main__.oldstyle instance at 0x3d91f8+' So I guess it's a moot point. I'm using the same code as I use in 3.0, where I call: meth = _PyType_Lookup(Py_TYPE(value), format_str); where format_str is __format__ interned. And I'm getting a value back for old style classes. Eric. But now try overriding __format__(). The 3.0 code uses _PyType_Lookup() which is not traversing the class dicts for classic classes, so it won't find __format__ overrides. Okay, I see and understand that issue. But looking at len or getattr, I don't see how to generalize it to __format__. __len__ and __getattr__ have special support in the classes, with cl_getattr, tp_getattr, etc. I hate to be dense, but could you point me to some code that does something similar but looks up the method by name? I'm not sure if it'll be exactly analogous, but you might look at __trunc__ and math.trunc for inspiration. -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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] Py3k and asyncore/asynchat
They applied when posted them, but subsequent patches seem to have broken them. I've now posted updated patches that apply cleanly against revision 60780. On Feb 13, 2008 6:52 PM, Bill Janssen [EMAIL PROTECTED] wrote: It's a big patch, but I'll try applying it to the current py3k branch -- does it apply? -- and try a few things with it. I'm concerned about how well it behaves with things like Medusa (which probably needs its own py3k update). Bill ___ 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] Error in post-revprop-change hook in svn
I mistyped Jeroen's name so I edited the log message. But I got the following error message in the process:: svn: 'post-revprop-change' hook failed; no error output available The change still occurred, though. Anybody with access to the svn hooks know what is going on? I have no clue. I believe it would have been /data/repos/projects/hooks/mailer.py propchange /data/repos/projects 60765 brett.cannon svn:log but when I ran that just now, it worked fine, and the message got sent. 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] Adding __format__ to classic classes
Try this:
if (PyInstance_Check(obj)) {
bound_method = PyObject_GetAttr(obj, str__format__);
if (!bound_method)
return NULL;
call it passing only the format string
Py_DECREF(bound_method);
return whatever the call returned
}
else {
do it the py3k way;
}
On Feb 13, 2008 5:31 PM, Eric Smith [EMAIL PROTECTED] wrote:
[slight mailer problem, this might show up as a dupe. sorry]
Guido van Rossum wrote:
On Feb 13, 2008 2:57 PM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 2:20 PM, Eric Smith [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
However, the source code for cPickle may provide some ideas (when it
looks up _reduce__/__getstate__/etc).
Those do look promising. Thanks!
Or look in classobject.c itself; e.g. instance_str().
It uses a static helper function instance_getattr(), which while it
looks like what I want, I can't get to.
Well, it just implements PyObject_GetAttr for classic class instances...
So I've come up with the following. I haven't checked for leaks yet,
but at least it appears to do what I want, for both classic and
new-style classes. I'm still porting over test cases from 3.0, so I'm
not convinced this is correct, yet.
/* Check for a __format__ method. */
meth = PyObject_GetAttr(value, str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
else {
You'd need PyErr_Clear() here the way this is written.
Okay.
But the
following call is redundant -- if that _PyType_Lookup() call finds
something, PyObject_GetAttr() will have found that too (or something
else).
meth = _PyType_Lookup(Py_TYPE(value), str__format__);
if (meth)
result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
else {
PyErr_Format(PyExc_TypeError,
Type %.100s doesn't define __format__,
Py_TYPE(value)-tp_name);
goto done;
}
}
Yes, but what's the or something else, and is it the right thing? Are
you saying I should call _PyType_Lookup first? But that's how I
started: if I do it that way, I can't override __format__ in a classic
class. As the code stands (PyObject_GetAttr then _PyType_Lookup), it's
definitely true that _PyType_Lookup will succeed when PyObject_GetAttr
will have failed.
Or should the logic be:
if is-new-style-class(Py_TYPE(value)):
lookup method with _PyType_Lookup(Py_TYPE(value))
else:
lookup method with PyObject_GetAttr(value)
And if so, how to test for is-new-style-class?
Sorry to be wasting your time, but I'm don't understand all of the
issues trying to support both new and classic classes in C. I think
I'll get the rest of PEP 3101 working, then come back to this issue.
It's pretty well contained. I'll spend some time understanding
classobject.c's implementation. It just seems like it shouldn't be this
hard to call a method (if it exists), given an instance.
I think my confusion leads to this problem (if in fact it's a problem):
format(object, '')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: __format__() takes exactly 1 argument (0 given)
format(object(), '')
'object object at 0x307408'
^D
Which works in the py3k branch.
Since PyObject_GetAttr() sets an AttributeError exception already, I
question the benefit of setting a different exception.
Agreed.
___
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] int/float freelists vs pymalloc
Andrew MacIntyre wrote: By the way objects are always aligned at 8 byte address boundaries. A 12 or 4 bytes object occupies 16 bytes. No, with PyMalloc a 4 byte object occupies 8 bytes (see the comments at the top of Objects/obmalloc.c). I know. It's a typo. It should read 12 or 14 byte object. Christian ___ 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
