[Python-Dev] Next PyPy Sprint: Tokyo 23/4 - 29/4
Tokyo PyPy Sprint: 23rd - 29th April 2006 The next PyPy sprint is scheduled to take place 23rd- 29th April 2006 (Sunday-Saturday) in Akihabara, Tokyo, Japan. We will together with FSIJ (Free Software Initiative of Japan) aim to promote Python and PyPy. We therefor invite Japanese hackers knowledgeable in Python to join our sprint! We'll give newcomer-friendly introductions. To learn more about the new Python-in-Python implementation look here: http://codespeak.net/pypy For this sprint we are particularly interested in meeting and coding on PyPy together with interested Japanese Python hackers. Please register your interest at [EMAIL PROTECTED] as soon as possible and we will help with any questions regarding getting started, pointing to relevant documentation etc. The PyPy team is curious and interested in the experience of hacking code for embedded devices and would love to discuss and get feedback on optimisation efforts and the current state of PyPy. Goals and topics of the sprint -- Possible suggestions for topics are: - Work on gensqueak (our Squeak backend) or possibly other backends. - Implementing Python 2.5 features in PyPy. - Progress further on an 'rctypes' module aiming at letting us use a ctypes implementation of an extension module from the compiled pypy-c. - Writing ctypes implementations of modules to be used by the above tool. - Experimenting and improving performance of our garbage collectors. - Experiment with PyPy flexibility or other aspects of the implementation. - Possibly experiment with writing modules translatable for use both in PyPy and CPython. - Whatever participants want to do with PyPy or particular areas of PyPy (please send suggestions to the mailing list before to allow us to plan and give feedback) Location Accomodation The sprint will be held at National Institute of AIST (National Institute of Advanced Industrial Science and Technology, http://www.aist.go.jp/index_en.html), Akihahabara (the technical gadget district in Tokyo). Yutaka Niibe is our contact person there, helping with arranging facilities. Niibe is the chairman of FSIJ and they have invited us to sprint in Tokyo and we are very grateful for the help and interest we have recieved so far. The facilities we are sprinting in are located here: http://www.gtrc.aist.go.jp/en/access/index.html#Akihabara The actual address is: Akihabara Dai Bldg , 1-18-13 Sotokanda, Chiyoda-ku, Tokyo 101-0021 Japan Phone: +81-3-5298-4729 Hotel areas - we are recommended to book hotels in Ueno and Asakusa (old town), from those areas there are only two metro stops to Akihabara. Please note that hotelrooms in Tokyo are often very small. http://www.wh-rsv.com/english/akihabara/index.html (nearest hotel to sprint location) http://www.greenhotel.co.jp/ochanomizu_e.html http://www.ohgai.co.jp/index-e.html (Ueno) http://www.toyoko-inn.com/e_hotel/00012/index.html (Asakusa) http://www.hotelnewkanda.com/ (second nearest, but no english page) Here is a url for booking hotels with not too unreasonable rates (see map): http://japan-hotelguide.com/hotels/Japan/Tokyo/index.htm For more general tourist information about travelling to Japan and Tokyo - please see: http://www.jnto.go.jp/eng/ http://www.japantravelinfo.com/ (really useful information regarding airfares, hotels, currency, phones etc etc) Comments on the weather: In end April it is ca 20 degrees Celsius. Exact times --- The public PyPy sprint is held Sunday 23rd - Saturday 29th April 2006. Hours will be from 10:00 until people have had enough. It's a good idea to arrive a day before the sprint starts and leave a day later. Sometimes people cannot stay for the whole sprint - you are welcome even if you can only stay for a day or a few days. Sunday: Starting at 10:00. This day is focused on getting to know PyPy enought to start to participate. We will hold a PyPy tutorial and an architectural overview. Planning meeting for the work to be done during the week and grouping of developers (pairs or groups mixing new participants with core developers). Dinner in the evening (Yutaka will arrange a place for us to go to). Monday-Tuesday: Starting at 10:00 with status meetings. Possible regrouping depending on the interest and progress of the various teams. Wednesday: Breakday (coding is allowed although we recommend taking a break). Thursday-Saturday: Starting at 10:00 with status meetings. Possible regrouping depending on the interest and progress of the various teams. Ending on Saturday with a Closure session - summing of the work and planning work to be done until the next sprint. Network, Food, currency We will have access to WiFi at AIST - please make sure you have wlan capabilities.
Re: [Python-Dev] PySet API
On Sun, 2006-03-26 at 11:43 -0500, Raymond Hettinger wrote: It was a trick question. Everyone is supposed to be attracted to the _next version because it is shorter, faster, and takes less ref counting management. However, the _next version has a hard-to-find bug. The call to PyObject_Hash() can trigger arbitrary Python code and possibly mutate the table, leaving pointers to invalid memory addresses. It would likely take Armin less than five minutes to write a pure Python crasher for the code. And THAT is why PySet_Next() should never come into being. We're clearly going in circles here, and it's obvious we're not going to agree. The fact that PySet_Next() can be used incorrectly is no reason not to include it. There are /lots/ of things in Python that if you use incorrectly will screw you. So you document them, teach people when not to use them, and teach them how to use them correctly when they /are/ the right thing to use. I don't want to be babied into using inappropriate and cumbersome APIs which, yes, can be a source of their own subtle bugs. -Barry signature.asc Description: This is a digitally signed message part ___ 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] PySet_Next (Was: PySet API)
On Sun, 2006-03-26 at 19:59 +0200, Martin v. Löwis wrote: If it is similar to PyDict_Next, it will have PyObject** /input/ variables, which are really meant as PyObject* /output/ variables. Yep, that's exactly what my posted patch does. For the caller, a clear usage strategy follows from this: either discard the references before making a potentially-mutating call, or Py_INCREF the set element before making that mutating call. Yep. Nice and simple. And if you're not making a potentially-mutating call, you don't have to worry about even that. These /are/ valid use cases. -Barry signature.asc Description: This is a digitally signed message part ___ 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] PySet_Next (Was: PySet API)
On Sun, 2006-03-26 at 13:24 -0500, Raymond Hettinger wrote: We have a perfectly good way to iterate with PyIter_Next(). It may take a couple of extra lines, but it is easy to get correct and has no surprises. It seems that the only issue is that Barry says that he refuses to use the iterator protocol. Heck, just turn it into a list and index directly. There is no need to muck-up the set api for this. I just think you have a narrow vision of how Python sets can be used in a C application. -Barry signature.asc Description: This is a digitally signed message part ___ 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] PySet_Next (Was: PySet API)
On Sun, 2006-03-26 at 21:50 +0200, Martin v. Löwis wrote: I don't know what specific application Barry has in mind, but I'm sure he can get it right (although it might be an interesting experiment to test that theory :-) In general, I would expect that people find it easier to get code involving PyDict_Next right than code dealing with iterators - primarily because of the error cases you have to consider. I can't post the code because it's proprietary, but I gave a general feel to the types of things we do in a previous response. Imagine you have application objects that are also PyObjects. They have application specific state and behavior. They can be put in Python sets and they can be iterated over to check that state, invoke that behavior (which won't involve trips into Python), or perhaps add them to other collections. Do this 50 to 60 times in your application and I think you'll start to see why the iterator protocol is incredibly cumbersome to use. I don't care that much either way, although I would prefer to see an actual, current use case for PySet_Next, rather than theoretical, made-up examples. I don't expect to use Python sets in C code at all, personally. We really, honestly do use PySet_Next in many places. We implemented that API for Python 2.4 exactly because the iterator protocol was way too much overhead. The posted patch is a port to Python 2.5. We obviously can't add this to Python 2.4, but I had really hoped that we wouldn't have to maintain this extension for subsequent versions. I'm frankly astonished to get so much pushback from Raymond about it. -Barry signature.asc Description: This is a digitally signed message part ___ 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] refleaks in 2.4
Hi Neal, On Sun, Mar 26, 2006 at 11:39:50PM -0800, Neal Norwitz wrote: test_pkg leaked [10, 10, 10] references This one at least appears to be caused by dummy (deleted) entries in the dictionary of interned strings. So it is not really a leak. It is a pain that it is so hard to figure this out, though. Wouldn't it make sense to find a trick to exclude these dummy entries from the total reference count? E.g. by subtracting the refcount of the dummy object... 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] PySet API
Why don't we expose _PySet_Next() for Barry and leave it out of the public API for everyone else. Raymond ___ 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] PySet API
Why don't we expose _PySet_Next() for Barry and leave it out of the public API for everyone else. [Alex] There are precedents for adding some functionality to the C API but not documenting it to ensure non advanced users don't get hurt -- that's how we added the ability to raise exceptions in different threads, in particular. Not sure if this is the best solution here, but I'm just pointing out that it's definitely not unthinkable, procedurally speaking. Thank would be nice. It gives me the ability to keep a clean, sane API while at the same time making sure that my most important customer (Barry) gets his needs met. Raymond ___ 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 FREEZE for 2.5a1: 0000 UTC, Thursday 30th
Jeremy Hylton wrote: On 3/27/06, Anthony Baxter [EMAIL PROTECTED] wrote: Ok, it's time to rock and roll. The SVN trunk is FROZEN for 2.5a1 from 00:00 UTC on Thursday 30th of March. I'll post again once it's open. Note that new features can keep going in during the alpha cycle, the feature freeze only happens once we hit beta. And we're not going to hit beta until the features we want are in. Please help in making this release as painless as possible by not checking in while the trunk is frozen. There's a bug day on Friday. http://wiki.python.org/moin/PythonBugDay It seems a bit senseless to freeze the trunk the day before the bug day. All the bugs I'm planning to work on are important for the alpha. How much inconvenience will it case to delay the freeze until after the bug day? I'd say we should push the alpha a whole week rather than screw up the bug day. As the one who scheduled the bug day, I second that. (I really should have read the freeze message more closely, thanks Jeremy) 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] PySet API
Raymond Hettinger wrote: Why don't we expose _PySet_Next() for Barry and leave it out of the public API for everyone else. That is stupid. If Barry wants a private PySet_Next function, he can just implement it himself, no need to include it in the release. It should be included only if it is meant to be public. 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] r43358 - python/trunk/Modules/itertoolsmodule.c
On 3/27/06, Raymond Hettinger [EMAIL PROTECTED] wrote: Modified: python/trunk/Modules/itertoolsmodule.c Log: Make itertools.tee and its internal teedataobject participate in GC. This alone does not solve the leak in test_generators, unfortunately, but it is part of test_generators' problem and it does solve other cycles.Thanks for getting this in.To get the leak in test_generators, I think you make need to add GC to theteeobject as well as the teedataobject. The teeobject has GC (hence the word 'and' in 'itertools.tee and its internal teedataobject' ;-) The problem with test_generators is that this also leaks:def leak(): def gen(): while True: yield g g = gen()leak()It doesn't leak in 2.4. I'm using a little shell script to work backwards through the 2.5 changes to find out which one introduced this, although I somehow suspect it's the coroutine stuff... ;P -- 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
[Python-Dev] Libref sections to put new modules under?
Any thoughts on where documentation for the new contextlib module should go in the library reference? Some candidates: * Program Frameworks (???) * Development Tools (??) * Python Runtime Services (?) * Python Language Services (??) * Miscellaneous Services (??) A similar issue exists for ctypes module, although I imagine an argument could easily be made for putting it with Optional Operating System Services. wsgiref can probably go in Internet Protocols and Support, while ElementTree obviously goes under Structured Markup Processing Tools. What other new modules do we have going in 2.5 that haven't found a home in the documentation yet? I seem to recall some discussion about a decorator library or functools or something of that sort. ___ 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] r43358 - python/trunk/Modules/itertoolsmodule.c
On 3/27/06, Thomas Wouters [EMAIL PROTECTED] wrote: The teeobject has GC (hence the word 'and' in 'itertools.tee and its internal teedataobject' ;-) The problem with test_generators is that this also leaks: def leak(): def gen(): while True: yield g g = gen() leak() Please add a test for this to the leakers and remove the tee test in leakers if that no longer leaks. Thanks, 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] Libref sections to put new modules under?
On 3/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote: Any thoughts on where documentation for the new contextlib module should go in the library reference? Some candidates: * Program Frameworks (???) * Development Tools (??) * Python Runtime Services (?) * Python Language Services (??) * Miscellaneous Services (??) Runtime Services is by far the best candidate. The Language services are more for code that reads/writes Python source code or bytecode. The others are even less likely matches. (What's development tools?) A similar issue exists for ctypes module, although I imagine an argument could easily be made for putting it with Optional Operating System Services. +1 wsgiref can probably go in Internet Protocols and Support, while ElementTree obviously goes under Structured Markup Processing Tools. +1 What other new modules do we have going in 2.5 that haven't found a home in the documentation yet? I seem to recall some discussion about a decorator library or functools or something of that sort. Is the with statement documented yet? -- --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] Libref sections to put new modules under?
On Monday 27 March 2006 16:26, Phillip J. Eby wrote: Any thoughts on where documentation for the new contextlib module should go in the library reference? Most definately in Python Runtime Services. A similar issue exists for ctypes module, although I imagine an argument could easily be made for putting it with Optional Operating System Services. I'm less sure of that one. It could reasonably go in Python Runtime Services, Generic Operating System Services, or Optional Operating System Services. wsgiref can probably go in Internet Protocols and Support, while ElementTree obviously goes under Structured Markup Processing Tools. Yes to both. -Fred -- Fred L. Drake, Jr. fdrake at acm.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] refleaks in 2.4
Neal Norwitz wrote: test_unicode leaked [7, 7, 7] references This one is lacking this checkin: r41530 | neal.norwitz | 2005-11-24 23:00:56 +0100 (Do, 24 Nov 2005) | 6 lines Geänderte Pfade: M /python/trunk/Lib/test/test_unicode.py Move registration of the codec search function to the module scope so it is only executed once. Otherwise the same search function is repeated added to the codec search path when regrtest is run with -R and leaks are reported. :-) Applying it gets the number of leaked references down to 1. 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] I'm not getting email from SF when assigned a bug/patch
Folks, When you assign a bug/patch to me, somehow SourceForge doesn't send me an email. (Is this understood behavior? Can it be changed?) Since I don't monitor my SF personal page regularly any more, that means that the issue will remain in limbo forever or until someone points me to it. So if you want me to take any particular action (even rejecting something) please send me a separate email! -- --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] I'm not getting email from SF when assigned a bug/patch
Guido van Rossum wrote: When you assign a bug/patch to me, somehow SourceForge doesn't send me an email. (Is this understood behavior? Can it be changed?) I believe it broke at some point, I'm pretty certain it used to work. 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] I'm not getting email from SF when assigned a bug/patch
On 3/27/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Guido van Rossum wrote: When you assign a bug/patch to me, somehow SourceForge doesn't send me an email. (Is this understood behavior? Can it be changed?) I believe it broke at some point, I'm pretty certain it used to work. More reason to move away from SF ASAP. -- --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] PySet API
Barry Warsaw wrote: We're clearly going in circles here, and it's obvious we're not going to agree. Would it perhaps help if there were a better API for using the iterator protocol from C code? Something that's as easy to use as the proposed set iterating API, but which uses the general iterator protocol underneath. 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] Expose the array interface in Python 2.5?
Chris Barker wrote: Can we have both? A defined interface, that existing code can be adapted to provide, and a new C-Object, that future code can just use. If the goal is to have as many extension types as possible use the same base object, the sooner a standard object is provided the better. Having many extension types provide the same *interface* is what I think the main goal should be, not to have them use the same object. So getting the interface defined should be the first priority. I'd sure like to see indexing and slicing, at at least. The interface itself doesn't need to provide indexing and slicing -- these could be provided by a view object that used the array interface of the underlying object. This would also fit in nicely with the views philosophy that seems to be shaping up for Py3k. Another point is that n-dimensional arrays really are very useful for all sorts of stuff that have nothing to do with high-performance Numeric computing. I'm all in favour of including such an object, as long as we keep in mind that this is an orthogonal issue to having an array interface. The discussion still seems to be a bit muddled on this point. 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
If you have Numeric or numpy installed try this: #import Numeric as N import numpy as N a = range(10) b = N.arange(10) a.__iadd__(b) print a Result: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Contrast the returned output with import numpy as N a = range(10) b = N.arange(10) a += b print a Result: [ 0 2 4 6 8 10 12 14 16 18] Having a+=b and a.__iadd__(b) do different things seems like an unfortunate bug. It seems to me that the problem is that the INPLACE_ADD and INPLACE_MULTIPLY cases in ceval.c use PyNumber_InPlaceYYY instead of trying PySequence_InPlaceYYY when the object doesn't support the in-place number protocol. I could submit a patch if there is agreement that this is a problem. -Travis ___ 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
On 3/27/06, Travis Oliphant [EMAIL PROTECTED] wrote: If you have Numeric or numpy installed try this: #import Numeric as N import numpy as N a = range(10) b = N.arange(10) a.__iadd__(b) print a Result: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Contrast the returned output with import numpy as N a = range(10) b = N.arange(10) a += b print a Result: [ 0 2 4 6 8 10 12 14 16 18] Having a+=b and a.__iadd__(b) do different things seems like an unfortunate bug. It seems to me that the problem is that the INPLACE_ADD and INPLACE_MULTIPLY cases in ceval.c use PyNumber_InPlaceYYY instead of trying PySequence_InPlaceYYY when the object doesn't support the in-place number protocol. I could submit a patch if there is agreement that this is a problem. Well how is the interpreter to know whether += meanse numeric add or sequence add in any particular case? Shouldn't it be numpy's responsibility to implement both operations identically? (It's a design bug in Python that the + operation has two implementation slots. But it's difficult to fix that until Python 3000. It *will* be fixed there.) -- --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] Class decorators
Greg Ewing greg.ewing at canterbury.ac.nz writes: I've just been playing around with metaclasses, and I think I've stumbled across a reason for having class decorators as an alternative to metaclasses for some purposes. There has also been discussion on the IronPython mailing list that class decorators would be a very useful syntax for expressing .NET attributes. http://lists.ironpython.com/pipermail/users-ironpython.com/2006-March/002007.html Mike ___ 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] Class decorators
At 07:20 PM 3/27/2006 +, Mike Krell wrote: Greg Ewing greg.ewing at canterbury.ac.nz writes: I've just been playing around with metaclasses, and I think I've stumbled across a reason for having class decorators as an alternative to metaclasses for some purposes. There has also been discussion on the IronPython mailing list that class decorators would be a very useful syntax for expressing .NET attributes. http://lists.ironpython.com/pipermail/users-ironpython.com/2006-March/002007.html PyProtocols and the zope.interface package both support inline class decorators called class advisors. They don't require any special syntax, and aren't much more complex than regular decorators. By defining an advisor like this: from protocols.advice import addClassAdvisor def some_advisor(whatever_args): def callback(cls): print I can modify,cls,or replace it return cls addClassAdvisor(callback) you can then use it in a class body like so: class SomeClass: some_advisor(something) And the return value from 'callback' will replace SomeClass, just like a decorator replaces the function it's called on. The implementation should work with any Python version from 2.2 up. I'm not sure if it would work with IronPython. But if it doesn't, that would be a good indication of feature(s) that IronPython is missing. ;) ___ 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] PySet API
On Sat, 2006-03-25 at 22:05 -0500, Raymond Hettinger wrote:
Still, PyObject_Clear(s) would be better.
Although not ideal, in the interest of compromise, I could support this
option. There's a problem with this though: I don't think you want to
be able to clear a frozen set. My PySet_Clear() raises a SystemError
and returns -1 when the object is a frozen set.
If PyObject_Clear() is implemented something like
int PyObject_Clear(PyObject *o)
{
return (o-ob_type-tp_clear ? o-ob_type-tp_clear(o) : -1);
}
then you /would/ be able to clear a frozen set. For that matter, it
would be the case that any immutable collection would be clearable if it
had a tp_clear (which it probably would). That isn't the semantics I'd
expect though. That may not be solvable unless you make
PyObject_Clear() an alias for PyObject_CallMethod(clear).
Although I'm sure you'll disagree, I think this is less than ideal. For
one thing, you're requiring objects that work with PyObject_Clear() to
implement an exact Python-level protocol (it must have a method, it must
be called clear and it must take zero arguments). You also have to
implement PyObject_Clear() with a hasattr test, because I don't think
you want PyObject_Clear() raising AttributeErrors. That raises the
constant overhead cost, which can make clearing small sets more
expensive.
Better still would be to examine the
actual uses in the app. I suspect that most code that clears a set and then
rebuilds it would be better-off starting with a new empty set (and because of
freelisting, that is a very fast operation).
That may not be possible. Imagine a complex application where the set
is passed through many layers of calls. The set hangs off of other
application level objects which you don't have access to at the point
where you're deciding whether to clear the set or not. You can't create
a new set because you have no way to pass the new set back to the
several application level objects that would need to get their pointers
updated. So the most obvious, simple approach is to just clear the set
you have right there.
Likewise, it only takes a one-line header to define BarrySet_Update(s). I do
not want that part of the C API exposed yet. It is still under development
and
may eventually become a function with a variable length argument list.
Really? That would be odd and not at all parallel with established
convention (e.g. PyDict_Update()). I would think that a vararg update
should be named something different in order to preserve the principle
of least surprise.
If you're dead-set against using the iterator API, then maybe there is
something
wrong with the API. You should probably start a new thread on why you detest
the iterator API and see if there are ways to improve it.
I'm not saying there's anything wrong with the iterator API, I'm saying
that it's not always appropriate. It's the nail/hammer argument. But I
ran out of clever when I tried to propose the simplest, most direct fix
for our most pressing issues, so I'm not going to take the bait.
You talk about duck typing, but I don't care about that here.
It's one of the virtues of Python that gets reflected in the abstract API.
IMO,
it's nice that PyObject_Dir(o) corresponds to dir(o) and the same for
hash(o),
repr(o), etc. I just hope that by hardwiring data types in stone, that your
app
doesn't become rigid and impossible to change. I certainly do not recommend
that other people adopt this coding style (avoidance of iterators,
duplication
of abstact api functions in concrete form, etc.) If you're experiencing
debugging pain, it may be that avoidance of abstraction is the root cause.
Trust me Raymond, it's not the cause. I keep trying to explain this but
I must be completely inept because you're just not getting it. Let me
try this way: we're using Python's collection types (sets, lists, dicts)
as our fundamental collection data structures internally in our
application. There's no duck typing going on. There's no need for
abstraction because we know exactly what we have and there's no chance
we'll have something that smells like a set that isn't exactly a PySet.
As I've said many times, I'm all for an abstract API because it's darn
useful in many applications. It's the lack of a concrete API that is
limiting.
I wouldn't object to that, but it wouldn't change my mind about
PySet_Clear().
This is plain evidence that something is wrong with your approach. While
possibly necessary in your environment, the rest of mankind should not have
to
stomach this kind of API clutter.
Please, that's a bit extreme. I haven't heard anybody scream about the
PyDict's API clutter and I don't see my PySet proposal as being any
different.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
On 3/27/06, Travis E. Oliphant [EMAIL PROTECTED] wrote: Guido van Rossum wrote: On 3/27/06, Travis Oliphant [EMAIL PROTECTED] wrote: If you have Numeric or numpy installed try this: #import Numeric as N import numpy as N a = range(10) b = N.arange(10) a.__iadd__(b) print a Result: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Contrast the returned output with import numpy as N a = range(10) b = N.arange(10) a += b print a Result: [ 0 2 4 6 8 10 12 14 16 18] Having a+=b and a.__iadd__(b) do different things seems like an unfortunate bug. It seems to me that the problem is that the INPLACE_ADD and INPLACE_MULTIPLY cases in ceval.c use PyNumber_InPlaceYYY instead of trying PySequence_InPlaceYYY when the object doesn't support the in-place number protocol. I could submit a patch if there is agreement that this is a problem. Well how is the interpreter to know whether += meanse numeric add or sequence add in any particular case? I can see that '+' (and '*') having two different implementation slots is a design bug. However, it seems prudent that both += and .__iadd__ should have identical behavior regardless. Whatever mechanism is used to resolve the conflict for __iadd__, the same mechanism should be used for for +=. I don't think this is a NumPy-only issue. Any object that defines addition that works with lists will have similar problems. I think this can be fixed easily by first checking the sequence slot for a sq_concat function before calling PyNumber_InPlaceAdd. All I'm asking for is that a += b have the same behavior as a.__iadd__(b). That seems like desireable behavior to me. Correct. Robert Kern's analysis is correct: when you make the call explicitly, a.__iadd__(b) invokes the list.__iadd__ method; this is effectively an alias for list.extend. I take back whatever I said about numpy. So for consistency we want a += b to also execute a.__iadd__. The opcode calls PyNumber_InplaceAdd; I think that PyNumber_InplaceAdd (and PySequence_InplaceConcat, if it exists) should test for both the numeric and the sequence augmented slot of the left argument first; then they should try both the numeric and sequence non-augmented slot of the left argument; and then the numeric non-augmented slot of the right argument. Coercion should not be attempted at all. The question is, can we do this in 2.5 without breaking backwards compatibility? Someone else with more time should look into the details of that. -- --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] I'm not getting email from SF when assigned a bug/patch
When you assign a bug/patch to me, somehow SourceForge doesn't send me an email. (Is this understood behavior? Can it be changed?) Martin I believe it broke at some point, I'm pretty certain it used to Martin work. I would expect that if it broke for Guido it broke for everybody. While we consider him to be the BDFL I suspect the accolades are lost on the SF folks. 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] Class decorators
On 3/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote: PyProtocols and the zope.interface package both support inline class decorators called class advisors. They don't require any special syntax, and aren't much more complex than regular decorators. By defining an advisor like this: from protocols.advice import addClassAdvisor def some_advisor(whatever_args): def callback(cls): print I can modify,cls,or replace it return cls addClassAdvisor(callback) you can then use it in a class body like so: class SomeClass: some_advisor(something) And the return value from 'callback' will replace SomeClass, just like a decorator replaces the function it's called on. The implementation should work with any Python version from 2.2 up. I'm not sure if it would work with IronPython. But if it doesn't, that would be a good indication of feature(s) that IronPython is missing. ;) Just curious (and lazy): what magic is the implementation using that makes this work without a custom metaclass? -- --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] Class decorators
At 08:02 PM 3/27/2006 -0800, Guido van Rossum wrote: Just curious (and lazy): what magic is the implementation using that makes this work without a custom metaclass? It registers a function as the __metaclass__ by poking it into the f_locals of the frame that's defining the class. This function has two attributes that denote 1) the callback to be invoked, and 2) the previous metaclass, forming a linked list of callbacks. When the class is created, this dummy metaclass function invokes the previous metaclass (or metaclass function) in the chain, then calls its callback on the result and returns that value, thus recursively unwinding the chain of advisors in the right order. (i.e., the same order as the advisors were called in the class body). The only part of the code that's even mildly complex is simulating Python's builtin rules for determining the default metaclass, so that when the recursion bottoms out you end up with an actual class with the right metaclass. And that's not so much complex as tedious. Anyway, the mechanism is orthogonal to the chosen metaclass, and thus can be used with classic classes or even ExtensionClasses if you're sufficiently masochistic. :) And AFAIK it's been in use by Zope 3 for some years now; in fact I think you were still working at Zope Corp. when Steve Alexander came up with the basic idea and I made the first practical implementation. ___ 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
Travis E. Oliphant wrote: I think this can be fixed easily by first checking the sequence slot for a sq_concat function before calling PyNumber_InPlaceAdd. However, if this *is* fixed, it looks like it's going to break NumPy, in the sense that it will no longer be able to force an arithmetic interpretation for + when adding a sequence to an array. 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] PySet API
Barry Warsaw wrote:
My PySet_Clear() raises a SystemError
and returns -1 when the object is a frozen set.
Isn't SystemError a bit drastic? TypeError would be
sufficient here, surely.
If PyObject_Clear() is implemented something like
int PyObject_Clear(PyObject *o)
{
return (o-ob_type-tp_clear ? o-ob_type-tp_clear(o) : -1);
}
then you /would/ be able to clear a frozen set.
Hmmm, the problem here, I think, is that tp_clear is
really only designed for use by the garbage collector.
Giving anything else access to it is probably wrong.
Clearability is not a general feature in Python land --
a few types have a clear() method, but this is an
ad hoc feature of the type concerned. I don't think
it makes sense to have a general PyObject_Clear
function at all.
--
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] Class decorators
Phillip J. Eby wrote: It registers a function as the __metaclass__ by poking it into the f_locals of the frame that's defining the class. That is stunningly brilliant! I'd nominate it for Hack of the Year if there were such an award. It's far too magical for me to feel like actually using it, though. Class decorators would be so much more straightforward and explicit. 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] I'm not getting email from SF when assigned a bug/patch
[EMAIL PROTECTED] wrote: Martin I believe it broke at some point, I'm pretty certain it used to Martin work. I would expect that if it broke for Guido it broke for everybody. While we consider him to be the BDFL I suspect the accolades are lost on the SF folks. Indeed, it broke for me as well. I didn't notice until Guido's post that this is what happened - I had assumed I had filtered out/deleted these messages. 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] PySet API
Greg Ewing wrote: Hmmm, the problem here, I think, is that tp_clear is really only designed for use by the garbage collector. Giving anything else access to it is probably wrong. Clearability is not a general feature in Python land -- a few types have a clear() method, but this is an ad hoc feature of the type concerned. I don't think it makes sense to have a general PyObject_Clear function at all. I agree. Barry's PySet_Clear and Raymond's PyObject_Clear would be two completely unrelated functions (one invoking the clear method, the other invoking tp_clear). 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] Inconsistency in 2.4.3 for __repr__() returning unicode
On Monday 27 March 2006 21:14, M.-A. Lemburg wrote:
Change PyObject_Repr() to use the default encoding (again)
which is also consistent with how PyObject_Str() works.
For 2.4.3, I plan to just revert the following patch (and supply a
test case)
Index: Objects/object.c
===
--- Objects/object.c(revision 16197)
+++ Objects/object.c(revision 16198)
@@ -267,7 +267,7 @@
return NULL;
if (PyUnicode_Check(res)) {
PyObject* str;
- str = PyUnicode_AsEncodedString(res, NULL,
NULL);
+ str = PyUnicode_AsUnicodeEscapeString(res);
Py_DECREF(res);
if (str)
res = str;
Does anyone have any objections to this? The test suite passes with
this (including the new test) as do various random tests I could
string together.
I need to apply this in the next short while, so if you have an issue
with it, please speak up now!
Thanks,
Anthony
To make repr() conversion more robust, we could have
PyObject_Repr() apply the conversion using the 'replace'
error strategy - after all, repr() is usually only
used for debugging, where it's more important that
you do get an output rather than an exception.
--
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] improving quality
We've made a lot of improvement with testing over the years. Recently, we've gotten even more serious with the buildbot, Coverity, and coverage (http://coverage.livinglogic.de). However, in order to improve quality even further, we need to do a little more work. This is especially important with the upcoming 2.5. Python 2.5 is the most fundamental set of changes to Python since 2.2. If we're to make this release work, we need to be very careful about it. In order to do the best possible job and avoid silly errors, there shouldn't be any checkins which could change behaviour that do not include a test. I'm not talking about updating comments or string constants. But even trivial changes can cause regressions or incompatible changes. Just like failing tests, code checked in without tests is fair game for being reverted if there is anything questionable. If you really can't figure out any way to test the change, please describe why in your checkin message. Just make sure it's true. It would be quite embarrassing to have your whole theory trashed when Uncle Timmy comes along 5 minutes later and checks in the test you just claimed was impossible. :-) 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] improving quality
On Tuesday 28 March 2006 17:53, Neal Norwitz wrote: In order to do the best possible job and avoid silly errors, there shouldn't be any checkins which could change behaviour that do not include a test. I'm not talking about updating comments or string constants. But even trivial changes can cause regressions or incompatible changes. Just like failing tests, code checked in without tests is fair game for being reverted if there is anything questionable. +1 from me. Anyone disagree? 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] improving quality
[Neal Norwitz] ... If you really can't figure out any way to test the change, please describe why in your checkin message. Just make sure it's true. It would be quite embarrassing to have your whole theory trashed when Uncle Timmy comes along 5 minutes later and checks in the test you just claimed was impossible. :-) And I, for one, find that especially embarrassing when Uncle Timmy did the original checkin ;-) BTW, I just noticed that the Mac buildbot died with a segfault on the 2.4 branch, a few tests after test_capi finished. I'll backport the fix for that from the trunk now. BTW2, has anyone tested their favorite extension module on the trunk with a release build? If you don't start reporting horrible problems, I'm not going to revert the patch that causes them :-) ___ 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] Libref sections to put new modules under?
Fred L. Drake, Jr. wrote: On Monday 27 March 2006 16:26, Phillip J. Eby wrote: Any thoughts on where documentation for the new contextlib module should go in the library reference? Most definately in Python Runtime Services. A similar issue exists for ctypes module, although I imagine an argument could easily be made for putting it with Optional Operating System Services. I'm less sure of that one. It could reasonably go in Python Runtime Services, Generic Operating System Services, or Optional Operating System Services. I had the same thought as Philip. For a preview of what it could look like, see http://starship.python.net/crew/theller/python-docs/html/lib/ , especially http://starship.python.net/crew/theller/python-docs/html/lib/module-ctypes.html . Thomas ___ 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] Inconsistency in 2.4.3 for __repr__() returning unicode
Never mind. For 2.4.3, I reverted perky's patch for the unicode-escape, and reverted the old patch for PyObject_Repr on the trunk. After talking to perky and Neal, this seemed like the safest option for 2.4.3. Anthony ___ 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
