Re: [Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c
On 3/27/06, Neal Norwitz [EMAIL PROTECTED] wrote: 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.I added this test, but I didn't remove test_tee, because it still leaks. I also checked in a test of code that used to leak, but doesn't anymore. The cycle this nested generator creates, which is also involved in the test_tee leak, is not cleanable by the cycle-gc, and it looks like it hasn't been since the yield-expr/coroutine patch was included in the trunk. I believe the culprit to be this part of that patch: Index: Modules/gcmodule.c===--- Modules/gcmodule.c (revision 39238)+++ Modules/gcmodule.c (revision 39239)@@ -413,10 +413,8 @@ assert(delstr != NULL); return _PyInstance_Lookup(op, delstr) != NULL; }- else if (PyType_HasFeature(op-ob_type, Py_TPFLAGS_HEAPTYPE))+ else return op-ob_type-tp_del != NULL; - else- return 0;}/* Move the objects in unreachable with __del__ methods into `finalizers`.Now, reverting that part of the patch in revision 39239 triggers an assertion failure, but removing the assertion makes it work right; the above nested-generator cycle gets cleaned up again. Later in the trunk, the assertion was changed anyway, and it no longer fails if I just revert the gcmodule change. Of course, the reason the cycle is uncleanable is because generators grew a tp_del method, and that throws cycle-gc in a hissy fit; reverting the above patch just makes cycle-gc ignore the tp_del of heaptypes. I don't know enough about the cycle-gc to say whether that's good or bad, but not having generators be cleanable is not very good. For what it's worth, reverting the gcmodule patch doesn't seem to break any tests. However, fixing _both_ those things (itertools.tee lack of GC, and GC's inability to clean generators) *still does not fix the 254 refleaks in test_generators*. When I backport the itertools.tee-GC changes to r39238 (one checkin before coroutines), test_generators doesn't leak, neither the r39238 version of test_generators, nor the trunk version. One revision later, r39239, either test_generators leaks 15 references. 'Fixing' gcmodule, which fixes the nested-generator leak, does not change the number of leaks. And, as you all may be aware of, in the trunk, test_generators leaks 254 references; this is also the case with the gcmodule fix. So there's more huntin' afoot. In the mean time, if people knowledgeable about the cycle-GC care to comment about the gcmodule change wrt. heaptypes, please do.-- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assigned abug/patch
Anthony Baxter wrote: On Tuesday 28 March 2006 19:35, Giovanni Bajo wrote: Anthony Baxter [EMAIL PROTECTED] wrote: Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath). Please god no. No bugzilla, no no no. Please! Care to elaborate? Unbelievably complicated to setup and run. Awful default user interface (how many form fields can you get??) Awful code. Perl. 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] Libref sections to put new modules under?
Phillip J. Eby wrote: 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. The suggestion with functools was to rename functional.partial to functools.partial, and add a functools.decorator function. The idea of the latter being that sticking @decorator on the front would be enough to make a decorator function well-behaved (and future-proof). 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] I'm not getting email from SF when assigned abug/patch
Wolfgang Langner wrote: what about trac: http://www.edgewall.com/trac/ It is based on python and has a very good svn integration. We started using it recently and so far it's working really well. I love the svn (and wiki!) integration. However, I have no idea how well it scales to a project the size of Python. Just ___ 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 msgs for new-style division
Hi, (this makes test_ctypes fail, therefore I noticed) currently with -Qnew: 2/0 Traceback (most recent call last): File stdin, line 1, in ? ZeroDivisionError: float division 2L/0 Traceback (most recent call last): File stdin, line 1, in ? ZeroDivisionError: long division or modulo by zero 2/0L Traceback (most recent call last): File stdin, line 1, in ? ZeroDivisionError: long division or modulo by zero This seems a little inconsistent. Do we care? 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] I'm not getting email from SF when assigned abug/patch
On 3/28/06, Wolfgang Langner [EMAIL PROTECTED] wrote: what about trac:http://www.edgewall.com/trac/It is based on python and has a very good svn integration.Sorry, I should have realized more than half of python-dev lacked the context in which I made my suggestion. At PyCon and in a few other select groups, there's been talk about swapping SF for 'something else'. (Actually, there's been a lot of talk about that everywhere, but I'm talking about concrete proposals ;) The problem is 'which 'something else''. There is a PSF committee that is charged with proposing and trying out, but it got somewhat stuck at trying to get information from SourceForge. My suggestion is to use the existing, installed, configured roundup installation so we can give it a whirl. Obviously, we will also want to give trac and jira and any other serious alternatives a try. (But Bugzilla and RT have already been veto'd.) -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
Gerhard Häring wrote: Georg Brandl wrote: Anthony Baxter wrote: This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained. What's people's thoughts? OTOH, +1 for a simple DB wrapper that makes it easy to start with DB-enabled applications. The trouble with it can't be worse than the BSDDB issues ;) OTOH, pysqlite2 seems to have had a fairly rapid sequence of releases in the past. That's because I decided for a more rapid release cycle than I used in the past. If bugs are fixed and no features planned to implement in the near future, I made a release. Sounds fair. I don't know whether it is now bug-free (the website claims that the 2.1 branch should be stable, and the 2.0 branch has proven stable). There have been no more bug reports since 2.1, so I'm confident that all the glitches the switch to transparent compiled statements in 2.1 introduced are fixed now. There also have been some API changes in the 2.0.x line, like the introduction of executemany() which broke e.g. SQLObject. I missed that, can you provide a link please? pysqlite 2 was announced to be incompatible with pysqlite 1. I don't think there were any backwards incompatible API changes in the 2.x line. Never mind, you're right. I had another piece of software in my head ;) Anyway, almost all popular web frameworks rely on PySQLite and seem to work well with it. Of course, speaking with Gerhard will be the way to find out more. I'll try to throw in a bit more information that will be necessary for this discussion: pysqlite 2.x is (almost) feature complete now. I've a few more changes sitting in SVN trunk that are waiting for the pysqlite 2.2 release. These are all about wrapping more of the SQLite API, like custom collations. In what timeframe will those be completed? I *am* willing to be a maintainer of an SQLite module for Python. I will gladly help writing a PEP for it. But I won't be the champion for the idea, because I'm only +0 on adding external libraries to Python, like elementtree, or ctypes, or pysqlite instead of relying on setuptools/Cheese Shop. I could probably be convinced that a fat Python is still a good idea nowadays, though :-) Even though setuptools are a very good concept and implementation, ships with Python is still a different kind of statement. Many people think that every external package to maintain is one too much... 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] Error msgs for new-style division
Georg Brandl wrote: Hi, (this makes test_ctypes fail, therefore I noticed) currently with -Qnew: 2/0 Traceback (most recent call last): File stdin, line 1, in ? ZeroDivisionError: float division 2L/0 Traceback (most recent call last): File stdin, line 1, in ? ZeroDivisionError: long division or modulo by zero 2/0L Traceback (most recent call last): File stdin, line 1, in ? ZeroDivisionError: long division or modulo by zero I'll fix that in the ctypes tests. 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
Hi, On Mon, Mar 27, 2006 at 08:00:09PM -0800, Guido van Rossum wrote: 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. I agree that there is a bug. There is more than one inconsistency left around here, though. Fixing one might expose the next one... For example, if -- as the documention says -- the expression 'a + b' would really try all slots corresponding to a.__add__(b) first and then fall back only if the slots return NotImplemented, then we'd also have to fix the following to return NotImplemented: [].__add__(5) TypeError: can only concatenate list (not int) to list and then we have no place to put that nice error message. Nevertheless I think we should fix all this for consistency. I can try to give it a good look. I don't think many programs would break if the change goes into 2.5, but there are some C extension modules out there abusing the inner details of the type slots in unpredictable ways... 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] pysqlite for 2.5?
Georg Brandl wrote: Gerhard Häring wrote: I'll try to throw in a bit more information that will be necessary for this discussion: pysqlite 2.x is (almost) feature complete now. I've a few more changes sitting in SVN trunk that are waiting for the pysqlite 2.2 release. These are all about wrapping more of the SQLite API, like custom collations. In what timeframe will those be completed? I would have waited for a pysqlite 2.2 release until I found a good API for logging for pysqlite (mainly for reporting exceptions in Python callbacks). I will probably defer the logging stuff to pysqlite 2.3 and release pysqlite 2.2 soon with the features currently in SVN. I know that pushing new things into Python 2.5 should happen soon, if at all. So *if* pysqlite should go into Python, I propose that I release pysqlite 2.2.0 and we integrate that into the Python alpha release. If this is going to happen, I want it to happen under a different package name than pysqlite2 and it's probably a good idea to skip sqlite too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, sqlite would be the natural name if it ends up in Python. Perhaps sqlitedb ... Extensive unit tests are available, as is a reference manual in ReST format. -- Gerhard (*) Although if they're really using pysqlite 0.x/1.x then it's unlikely they'll switch to Python 2.5 with their applications. ___ 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 Tue, 2006-03-28 at 18:00 +1100, Anthony Baxter wrote: 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? Not me! -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] pysqlite for 2.5?
On Tue, 2006-03-28 at 17:59 +1100, Anthony Baxter wrote: This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained. SQLite/pysqlite is an awesome combination, and I do think it would make for a more compelling Python distribution. I've used it in several projects, usually with great success. My only hesitation is that in one project, we've had to stick with SQLite 3.2.1 and pysqlite 1.1.6 because we encountered some concurrency problems when trying to upgrade the former to 3.2.8. We couldn't upgrade both to the latest versions due to external project management constraints. But I'm not sure that's enough of a reason to vote against inclusion, so I guess I'm +0. Having Gerhard accept maintainership definitely pushes it from -0 to +0 in my mind. It's got lots of unit tests, so the only thing I'd probably want to see are Python docs for the module. I think Gerhard could still do more frequent releases if he wanted to -- I do that with the email package, and while it's a bit of a PITA, it's doable. Either sqlite or sqlitedb are fine names. -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] I'm not getting email from SF when assigned abug/patch
On Tue, 2006-03-28 at 10:13 +0200, Giovanni Bajo wrote: Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath). The infrastructure committee (of which I'm a member but not the chair) is examining the alternatives and trying to put up some live demos for people to check out. Getting the data out of SourceForge has been the sticky issue though, and last I recall, we were waiting for some response from them about export bugs we'd encountered. -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 API
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. [etc] For what it's worth[1], I think Raymond is absolutely on crack here. [1] Not necessarily very much. There is none of my code in Python, so far as I know. * Simple API: The complexity of an API is not determined by the number of methods in it but by the variety of different things you can ask it to do, and it's not any simpler to have PyObject_CallMethod(x, foo) PyObject_CallMethod(x, bar) PyObject_CallMethod(x, baz) than to have PyObject_foo(x) PyObject_bar(x) PyObject_baz(x) API complexity is measured in brain cells, not in methods. * Ease of making mistakes: The Python API is absolutely stuffed with places where you can go wrong by forgetting about subtle refcounting issues. Sure, it's nice to minimize that pain, but it's never going to be possible to write much code that uses the C API without being alert to such issues. (Incidentally, the more things you have that can only be done by invoking PyObject_CallMethod, the more places you have where you have to assume that arbitrary Python code may have been called and that reference counts may have changed behind your back.) * Duck typing: Yup, supporting duck typing is good. That's why we have an abstract API. There are concrete APIs for all sorts of particular kinds of Python object; it seems pretty clear to me that this isn't a mistake, and that sets should be one such type. Clients get to choose how to trade off the benefits in efficiency, conciseness and clarity from using the concrete API against the benefits in generality from using the abstract one. And when PySet_Add is the obvious way to add items to sets, how much C code using sets is likely to work with things that merely walk and quack like sets, anyway? * Efficiency: Anyone measured this? The mere fact that the overhead of (say) emptying a set using PyObject_CallMethod is O(1) doesn't mean it's insignificant. For many applications the size of your sets is O(1) too. (Often with quite a small implicit constant, too.) -- Gareth McCaughan ___ 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] pysqlite for 2.5?
I'm happy to work with Gerhard to make this happen. Does it need a PEP? I'd say no, but only because things like ElementTree didn't, either. Does it need a BDFL pronouncement? I'd say yes. 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
Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch
Just van Rossum [EMAIL PROTECTED] wrote: http://www.edgewall.com/trac/ It is based on python and has a very good svn integration. We started using it recently and so far it's working really well. I love the svn (and wiki!) integration. However, I have no idea how well it scales to a project the size of Python. Having extensively used both Trac and Bugzilla, let me say that the ticket tracker in Trac is a child-play version of Bugzilla. It might be enough for Python, though, if SF was enough till now. I thought that a large project like Python required something more advanced. Anyway, I'll shut up as I see there is a committee for this decision. The integration between tickets/svn/wiki in Trac is cute though, even if, after a while, you'd really want that mailman parsed that syntax as well (and maybe your MUA too :) -- Giovanni Bajo ___ 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 abug/patch
Barry The infrastructure committee (of which I'm a member but not the Barry chair) is examining the alternatives and trying to put up some Barry live demos for people to check out. Roundup is there now, right (sans SF export)? Trac is being used by the folks doing the new website. What other candidates are being considered? Based on my brief experience as a Bugzilla user (just trying to be a good citizen and report Mozilla bugs a few years ago), I would vote -1. I'd hate to think the bug reporting interface was *so* bad that it alone would discourage people from reporting bugs. Still, I gave up reporting Mozilla bugs because of it. 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] improving quality
On 3/28/06, Neal Norwitz [EMAIL PROTECTED] wrote: 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. This reminds me of something I've been wanting to ask for a while: does anybody run python through valgrind on a regular basis? I've noticed that valgrind complains a lot about invalid reads in PyObject_Free. I know that valgrind can warn about things that turn out not to be problems, but would generating a suppresion file and running all or part of the test suite through valgrind on the buildbots be useful? Cheers, Chris ___ 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 3/28/06, Chris AtLee [EMAIL PROTECTED] wrote: On 3/28/06, Neal Norwitz [EMAIL PROTECTED] wrote: 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.This reminds me of something I've been wanting to ask for a while: does anybody run python through valgrind on a regular basis?I'venoticed that valgrind complains a lot about invalid reads inPyObject_Free.I know that valgrind can warn about things that turnout not to be problems, but would generating a suppresion file and running all or part of the test suite through valgrind on thebuildbots be useful?See Misc/README.valgrind and Misc/valgrind-python.supp. I ran Python with valgrind two weeks ago, and didn't encounter any new problems. -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assigned abug/patch
Op di, 28-03-2006 te 09:23 -0600, schreef [EMAIL PROTECTED]: Based on my brief experience as a Bugzilla user (just trying to be a good citizen and report Mozilla bugs a few years ago), I would vote -1. I'd hate to think the bug reporting interface was *so* bad that it alone would discourage people from reporting bugs. Still, I gave up reporting Mozilla bugs because of it. GNOME uses a Bugzilla fork that's more user-friendly... (But other people say Bugzilla is also difficult for admins, so that's probably not the only important thing.) -- Jan Claeys ___ 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
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 the same is true for Jython and Java annotations. ___ 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 abug/patch
Anthony Baxter [EMAIL PROTECTED] wrote: On Tuesday 28 March 2006 19:13, Giovanni Bajo wrote: Another option would be Bugzilla, which is proven to be stable, maintained and used succesfully by large open source projects (like GCC+RedHat+Binutils+Classpath). Please god no. No bugzilla, no no no. Please! I second the god no. No bugzilla sentiment. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
On 3/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: I propose that someone start writing a Py3k PEP for class decorators. I don't think it's fair to the 2.5 release team to want to push this into 2.5 though; how about 2.6? Wasn't there already a (pretty small) patch? I guess it would be different now with the AST though. 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] Class decorators
On Tue, Mar 28, 2006 at 10:16:01AM -0800, Neal Norwitz wrote: On 3/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: I propose that someone start writing a Py3k PEP for class decorators. I don't think it's fair to the 2.5 release team to want to push this into 2.5 though; how about 2.6? Wasn't there already a (pretty small) patch? I guess it would be different now with the AST though. I submitted one a couple years ago. The AST makes it obsolete though. I'd be happy to make a new AST friendly one (time to learn the AST..) -Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
Gerhard Häring wrote: I know that pushing new things into Python 2.5 should happen soon, if at all. So *if* pysqlite should go into Python, I propose that I release pysqlite 2.2.0 and we integrate that into the Python alpha release. +1 ! If this is going to happen, I want it to happen under a different package name than pysqlite2 and it's probably a good idea to skip sqlite too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, sqlite would be the natural name if it ends up in Python. Perhaps sqlitedb ... db.sqlite3 ? (it wraps version 3 of the sqlite engine, after all...) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
At 10:01 AM 3/28/2006 -0800, Guido van Rossum wrote: OK, I'm convinced (mostly by the awful hackery that Phillip so proudly exposed :-). Just as a historical note, here's where you previously rejected the same hackery as an argument for supporting class decorators: http://mail.python.org/pipermail/python-dev/2004-March/043462.html Ironically, the subsequent discussion following the above message brought me around to your point of view. :) Or more precisely, the subsequent discussion and examples convinced me that putting class decorators on top of the class was bad for readability, vs. putting them in the body just after the docstring. As you said, the use cases are certainly very *different* than those for function/method decorators. So at this point I'd rather see a way to make my hackery go away (or become part of the standard library in some fashion) rather than simply mimic @decorators for classes. ___ 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] pysqlite for 2.5?
Anthony Baxter wrote: This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained. What's people's thoughts? We shouldn't include anything without the explicit permission of the author(s); if possible, the authors should grant the PSF permission to change the license (i.e. fill out the contributor agreement). Even better, the authors should be willing to keep the version in Python synchronized with the separate release. 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] Class decorators
On 3/28/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 10:01 AM 3/28/2006 -0800, Guido van Rossum wrote: OK, I'm convinced (mostly by the awful hackery that Phillip so proudly exposed :-). Just as a historical note, here's where you previously rejected the same hackery as an argument for supporting class decorators: http://mail.python.org/pipermail/python-dev/2004-March/043462.html Ironically, the subsequent discussion following the above message brought me around to your point of view. :) Or more precisely, the subsequent discussion and examples convinced me that putting class decorators on top of the class was bad for readability, vs. putting them in the body just after the docstring. As you said, the use cases are certainly very *different* than those for function/method decorators. So at this point I'd rather see a way to make my hackery go away (or become part of the standard library in some fashion) rather than simply mimic @decorators for classes. That's fine. But there's also the C#/Java POV. I'm somehow concerned that any mechanism that puts the syntax inside the class body is somehow going to have a hackish implementation, but I'd be glad to be proven wrong, so please come up with a concrete proposal! -- --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 abug/patch
[EMAIL PROTECTED] wrote: Roundup is there now, right (sans SF export)? Richard Jones has an SF importer for one of the two XML-like formats, the one that is correct XML but with incomplete data. The other format, which has complete data but is ill-formed XML, has no importer into roundup at the moment. Trac is being used by the folks doing the new website. What other candidates are being considered? My view is that nothing should be considered unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide. 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] What about PEP 299?
Hi, since I found myself writing if __name__ == '__main__' often these days, I wondered whether PEP 299 could be pronounced upon. I'm not proposing putting it into 2.5, but it should be relatively small a change. Cheers, 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] Class decorators
At 11:04 AM 3/28/2006 -0800, Guido van Rossum wrote:
That's fine. But there's also the C#/Java POV.
Can someone point me to examples of C# class attributes and Java
annotations that they'd like to use with this mechanism? I would indeed
like to see how those use cases compare with mine.
I'm somehow concerned
that any mechanism that puts the syntax inside the class body is
somehow going to have a hackish implementation,
That depends on whether there's syntax support, or it's just something that
happens at runtime. I'm not opposed to having syntax, I just don't think
that putting the syntax outside the class is the best thing for most of my
class decorator use cases.
Nonetheless, neither special syntax nor hackiness is really required. For
example, your proposal here:
http://mail.python.org/pipermail/python-dev/2004-April/043913.html
was to use a '__decorators__' attribute, which would then be processed by a
metaclass. However, this could simply become a standard magic attribute
ala __metaclass__, and be processed by the class creation machinery after
first invoking the correct metaclass.
I don't really *like* that approach, but it requires neither syntax nor
hacks, (nor a custom metaclass) and it could be syntax-sugared later.
For that matter, if this __decorators__ machinery existed, the existing
advisor implementation could become a lot less hacky. The only magical bit
at that point would be doing something like:
locals = sys._getframe(n).f_locals.
locals.setdefault('__decorators__',[]).append(decorator)
And this of course could go in a function in the stdlib, rather than have
everybody writing their own _getframe() hacks.
___
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 abug/patch
Martin v. Löwis wrote: [EMAIL PROTECTED] wrote: Roundup is there now, right (sans SF export)? Richard Jones has an SF importer for one of the two XML-like formats, the one that is correct XML but with incomplete data. The other format, which has complete data but is ill-formed XML, has no importer into roundup at the moment. Trac is being used by the folks doing the new website. What other candidates are being considered? My view is that nothing should be considered unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide. There exists a Trac importer for SF data at http://projects.edgewall.com/trac/browser/trunk/contrib/sourceforge2trac.py though I don't know which format it does expect. Generally, I like Trac very much, especially for its interconnected subsystems. I've used it with smaller projects, and there it works perfectly. Having said that, I don't know if the Trac ticket system (which would be the most important subsystem for us) scales up well enough. Of course, if there are only a few bits missing, instead of paying someone to operate a complicated tracker, perhaps the money could be used to pay someone to improve Trac... 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] What about PEP 299?
At 09:22 PM 3/28/2006 +0200, Georg Brandl wrote: Hi, since I found myself writing if __name__ == '__main__' often these days, I wondered whether PEP 299 could be pronounced upon. I'm not proposing putting it into 2.5, but it should be relatively small a change. A couple of issues that the PEP doesn't address: * How can you write code that runs in multiple Python versions with this? If you use the current idiom to invoke __main__, it's going to get invoked twice. * A module that imports __main__ (using import __main__) is going to get a TypeError unless the implementation checks that __main__ is not in fact the __main__ module. ___ 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] pysqlite for 2.5?
Fredrik Lundh wrote: Gerhard Häring wrote: I know that pushing new things into Python 2.5 should happen soon, if at all. So *if* pysqlite should go into Python, I propose that I release pysqlite 2.2.0 and we integrate that into the Python alpha release. +1 ! If this is going to happen, I want it to happen under a different package name than pysqlite2 and it's probably a good idea to skip sqlite too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, sqlite would be the natural name if it ends up in Python. Perhaps sqlitedb ... db.sqlite3 ? That would make sense if inclusion of more database-related modules was planned. Whatever name is chosen: please no from sqlite3 import dbapi2 as sqlite! 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
On Tue, 2006-03-28 at 17:28 +1200, Greg Ewing wrote:
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.
Possibly, but all the other PySet_*() functions call
PyErr_BadInternalCall() when they get a type they don't accept, so
PySet_Clear() should be consistent.
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.
Exactly.
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'm thinking the same thing, which is why I'm now favoring PySet_Clear()
again.
-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
[Python-Dev] Reminder: Bug Day this Friday, 31st of March
Hello, it's time for the 7th Python Bug Day, just before 2.5 alpha 1 is released. The aim of the bug day is to close as many bugs, patches and feature requests as possible, this time with a focus on small feature additions that can still go into the upcoming 2.5 alpha release. When? ^ The bug day will take place on Friday, March 31st, running from approximately 1PM to 8PM GMT (9AM to 4PM Eastern time). You don't need to be around all day; feel free to stop by for a few hours and contribute. Where and How? ^^ To join, stop by the IRC channel #python-dev on irc.freenode.net, where efforts will be discussed and coordinated. We'll collaboratively go through the Python bug database at SourceForge and fix things as they come up. IMPORTANT: *No* prior knowledge of the Python source is necessary to participate! You'll get all assistance the developers can offer for starting up with helping, this is in fact a good opportunity to learn the basics. Bug day participation helps the developers and makes Python 2.5 a better release by reducing the backlog of bugs and patches. Plus, it's fun! More information For instructions and more information, see the Wiki page at http://www.python.org/cgi-bin/moinmoin/PythonBugDay Cheers, 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] pysqlite for 2.5?
Georg Brandl [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: db.sqlite3 ? +1 That would make sense if inclusion of more database-related modules was planned. Yup; I'd be happy to see db.mysql and db.pgsql or whatnot added as appropriate, and having a nice new namespace ready for them is a good idea. Whatever name is chosen: please no from sqlite3 import dbapi2 as sqlite! Amen. db.sqlite3 is the perfect name. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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 Mon, 2006-03-27 at 23:53 -0800, Raymond Hettinger wrote: While I don't favor the proposed API, I think is essential that you not be left hanging without good options. Thank you. So where does this leave us? BTW, Guido made a suggestion in private email (which he okayed to mention publicly). Quoting: OTOH, our experience with dicts have shown that the C dict API causes major constraints on dict subclassing (since the C APIs mostly ignore overridden methods) and the proliferation of their use makes it hard to implement features like allowing arbitrary mappings as globals/locals for exec/eval. Perhaps the PySet API can raise an error if it's ever called on something that's not *exactly* a set? No subclassing allowed. Shouldn't affect you, and should be an effective deterrent against abuse of the kind that made the PyDict API an albatross. This would involve changing the type test in PySet_Next() from a PyAnySet_Check() to a PyAnySet_CheckExact() so that it only works for sets and frozen sets. Guido's exactly right, it wouldn't affect us so it seems like it would be fine. I'm not sure if this directly addresses your concerns though, since they seem mostly centered around the safety (or lack thereof) of PySet_Next(). -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 API
Excerpting... On Tue, 2006-03-28 at 14:07 +, Gareth McCaughan wrote: * Simple API: API complexity is measured in brain cells, not in methods. * Ease of making mistakes: The Python API is absolutely stuffed with places where you can go wrong by forgetting about subtle refcounting issues. Sure, it's nice to minimize that pain, but it's never going to be possible to write much code that uses the C API without being alert to such issues. * Duck typing: Yup, supporting duck typing is good. That's why we have an abstract API. There are concrete APIs for all sorts of particular kinds of Python object; it seems pretty clear to me that this isn't a mistake, and that sets should be one such type. Clients get to choose how to trade off the benefits in efficiency, conciseness and clarity from using the concrete API against the benefits in generality from using the abstract one. * Efficiency: Anyone measured this? The mere fact that the overhead of (say) emptying a set using PyObject_CallMethod is O(1) doesn't mean it's insignificant. For many applications the size of your sets is O(1) too. (Often with quite a small implicit constant, too.) My sentiments exactly Gareth. Thanks for putting it so much more eloquently than I have. :) -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] pysqlite for 2.5?
On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote: I'm happy to work with Gerhard to make this happen. Does it need a PEP? I'd say no, Agreed. pysqlite is solid and widely accepted, and AFAIK has no competition. but only because things like ElementTree didn't, either. Does it need a BDFL pronouncement? I'd say yes. If Guido even cares ;), but if not, RM pronouncement is good enough for me. -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] pysqlite for 2.5?
On Tue, 28 Mar 2006 15:48:36 -0500, Barry Warsaw [EMAIL PROTECTED] wrote: On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote: I'm happy to work with Gerhard to make this happen. Does it need a PEP? I'd say no, Agreed. pysqlite is solid and widely accepted, and AFAIK has no competition. FWIW: http://www.rogerbinns.com/apsw.html Jean-Paul ___ 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] What about PEP 299?
On 3/28/06, Georg Brandl [EMAIL PROTECTED] wrote: since I found myself writing if __name__ == '__main__' often these days, I wondered whether PEP 299 could be pronounced upon. I'm not proposing putting it into 2.5, but it should be relatively small a change. If you're asking for a quick pronouncement, it's going to be no. It's not worth the change (in docs, user habits, etc.) and there's nothing particularly broken. -- --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] What about PEP 299?
Guido van Rossum [EMAIL PROTECTED] wrote: On 3/28/06, Georg Brandl [EMAIL PROTECTED] wrote: since I found myself writing if __name__ == '__main__' often these days, I wondered whether PEP 299 could be pronounced upon. I'm not proposing putting it into 2.5, but it should be relatively small a change. If you're asking for a quick pronouncement, it's going to be no. It's not worth the change (in docs, user habits, etc.) and there's nothing particularly broken. It might be worth instead adding an option flag to the executable that implies from the loaded module, run __main__() with sys.argv as its argument(s), so the user can get this behaviour with `python -X somemodule.py`. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] What about PEP 299?
On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote: It might be worth instead adding an option flag to the executable that implies from the loaded module, run __main__() with sys.argv as its argument(s), so the user can get this behaviour with `python -X somemodule.py`. You can do python -x somemodule as long as somemodule.py uses the if __name__=='__main__' convention. What does your proposal add? -- --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] What about PEP 299?
Sorry, I meant python -m somemodule. On 3/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote: It might be worth instead adding an option flag to the executable that implies from the loaded module, run __main__() with sys.argv as its argument(s), so the user can get this behaviour with `python -X somemodule.py`. You can do python -x somemodule as long as somemodule.py uses the if __name__=='__main__' convention. What does your proposal add? -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- --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] What about PEP 299?
Guido van Rossum [EMAIL PROTECTED] wrote: On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote: It might be worth instead adding an option flag to the executable that implies from the loaded module, run __main__() with sys.argv as its argument(s), so the user can get this behaviour with `python -X somemodule.py`. You can do python -m somemodule as long as somemodule.py uses the if __name__=='__main__' convention. What does your proposal add? Well, it's not really my proposal. I'm just suggesting the behaviour in PEP299 could be added via a commandline option so that it doesn't introduce backward-incompatibility. I don't see any particular benefit to PEP299 myself -- I'd rather just add an entry to the style guide about standardizing the executable stanza and main() function. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] What about PEP 299?
OK. -1 on PEP 299 it is. On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote: Guido van Rossum [EMAIL PROTECTED] wrote: On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote: It might be worth instead adding an option flag to the executable that implies from the loaded module, run __main__() with sys.argv as its argument(s), so the user can get this behaviour with `python -X somemodule.py`. You can do python -m somemodule as long as somemodule.py uses the if __name__=='__main__' convention. What does your proposal add? Well, it's not really my proposal. I'm just suggesting the behaviour in PEP299 could be added via a commandline option so that it doesn't introduce backward-incompatibility. I don't see any particular benefit to PEP299 myself -- I'd rather just add an entry to the style guide about standardizing the executable stanza and main() function. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c
[Thomas Wouters] ... The cycle this nested generator creates, which is also involved in the test_tee leak, is not cleanable by the cycle-gc, and it looks like it hasn't been since the yield-expr/coroutine patch was included in the trunk. That could very well be. Adding finalizers to generators could legitimately make some cycles suddenly uncollectable. There was a burst of list traffic about this on the 18th and 19th of June, 2005, under subject: gcmodule issue w/adding __del__ to generator objects I starred it in gmail at the time (which is why I was able to find it again ;-)), but never had time to pay attention. I believe the culprit to be this part of that patch: Index: Modules/gcmodule.c === --- Modules/gcmodule.c (revision 39238) +++ Modules/gcmodule.c (revision 39239) @@ -413,10 +413,8 @@ assert(delstr != NULL); return _PyInstance_Lookup(op, delstr) != NULL; } - else if (PyType_HasFeature(op-ob_type, Py_TPFLAGS_HEAPTYPE)) + else return op-ob_type-tp_del != NULL; - else - return 0; } Right, that's the patch that taught gc that generators now have finalizers. The original code can be read in two ways: 1. As a whole, it was an implementation of: Only instances of old- or new-style classes can have finalizers. An instance of an old-style class has a finalizer iff it has a method named __del__. An instance of a new-style class (PyType_HasFeature(op-ob_type, Py_TPFLAGS_HEAPTYPE) has a finalizer iff its tp_del is non-NULL. 2. Because of the obscure gimmicks that try to cater to using old binary extension modules across new Python releases without recompiling, there's no guarantee that the tp_del slot even exists, and therefore we don't try to access tp_del at all unless PyType_HasFeature says the type object was compiled recently enough so that we know tp_del does exist. When generators grew finalizers, the Only instances of ... classes can have finalizers part of #1 became wrong, and I expect that's why Phillip removed the conditional. It was the right thing to do from that point of view. I don't understand the #2 gimmicks well enough to guess whether it was actually safe to remove all guards before trying to access tp_del (I run on Windows, and compiled extensions can never be reused across Python minor releases on Windows -- if a problem was introduced here, I'll never see it). Now, reverting that part of the patch in revision 39239 There may be a reason to change that patch (due to #2 above), but generators do have finalizers now and the #1 part must not be reverted (although it may be fruitful to complicate it ;-)). triggers an assertion failure, but removing the assertion makes it work right; No, it's not right if has_finalizer(g) returns 0 for all generators g. the above nested-generator cycle gets cleaned up again. Later in the trunk, the assertion was changed anyway, and it no longer fails if I just revert the gcmodule change. Of course, the reason the cycle is uncleanable is because generators grew a tp_del method, and that throws cycle-gc in a hissy fit; If by hissy fit you mean gcmodule properly moves generators to the list of objects with finalizers, thereby preventing catastrophes, right, that's an intended hissy fit ;-) reverting the above patch just makes cycle-gc ignore the tp_del of heaptypes. I don't know enough about the cycle-gc to say whether that's good or bad, Ignoring all generators' tp_del would be disastrous (opens pure-Python code to segfaults, etc). but not having generators be cleanable is not very good. Not disastrous, though. For what it's worth, reverting the gcmodule patch doesn't seem to break any tests. I believe that. gc disasters are typically very difficult to provoke --, the first time :-) However, fixing _both_ those things (itertools.tee lack of GC, and GC's inability to clean generators) *still does not fix the 254 refleaks in test_generators*. When I backport the itertools.tee-GC changes to r39238 (one checkin before coroutines), test_generators doesn't leak, neither the r39238 version of test_generators, nor the trunk version. One revision later, r39239, either test_generators leaks 15 references. 'Fixing' gcmodule, which fixes the nested-generator leak, does not change the number of leaks. And, as you all may be aware of, in the trunk, test_generators leaks 254 references; this is also the case with the gcmodule fix. So there's more huntin' afoot. In the mean time, if people knowledgeable about the cycle-GC care to comment about the gcmodule change wrt. heaptypes, please do. Did the best I could above, short of explaining exactly how failing to identify an object with a finalizer can lead to disaster. Short course: gc obviously needs to know which objects are and are not
Re: [Python-Dev] pysqlite for 2.5?
At 04:22 PM 3/28/2006 -0500, Jean-Paul Calderone wrote: On Tue, 28 Mar 2006 15:48:36 -0500, Barry Warsaw [EMAIL PROTECTED] wrote: On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote: I'm happy to work with Gerhard to make this happen. Does it need a PEP? I'd say no, Agreed. pysqlite is solid and widely accepted, and AFAIK has no competition. FWIW: http://www.rogerbinns.com/apsw.html That implementation doesn't support the DBAPI, although it sounds as though the differences are mostly shallow and easy to add implementations for. (e.g., implementing the fetch* methods, a description property, etc.). More likely to be an issue is that the author hasn't volunteered to contribute/support it. On the plus side, it sounds like ASPW is a more general wrapping of SQLite, which seems to me to lean in its favor for the stdlib, if it can also be brought into DBAPI compliance. ___ 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
At 06:13 PM 3/28/2006 -0500, Tim Peters wrote: 2. Because of the obscure gimmicks that try to cater to using old binary extension modules across new Python releases without recompiling, there's no guarantee that the tp_del slot even exists, and therefore we don't try to access tp_del at all unless PyType_HasFeature says the type object was compiled recently enough so that we know tp_del does exist. When generators grew finalizers, the Only instances of ... classes can have finalizers part of #1 became wrong, and I expect that's why Phillip removed the conditional. It was the right thing to do from that point of view. I don't understand the #2 gimmicks well enough to guess whether it was actually safe to remove all guards before trying to access tp_del (I run on Windows, and compiled extensions can never be reused across Python minor releases on Windows -- if a problem was introduced here, I'll never see it). By that reasoning, binary compatibility won't be an issue anywhere else, either, since the change was made on the 2.5 alpha trunk, and ISTM that 2.5 will require recompiling extensions anyway. Now, the trick could potentially be made a bit smarter if there were a slot by which gcmodule could ask the object for a finalizer *dynamically*. A generator without an active frame (or an active frame with no try blocks on the frame's block stack), has no need to run Python code for finalization. Calling tp_clear on such a generator will do anything that the actual deletion would, only faster. :) So, that approach could be used to get rid of most new leaks caused by generator cycles, at the expense of a bit more complexity in the gc and in generators. It won't fix leaks caused by cycles in active generators that have active try/finally or try/except blocks, since these are the things that actually need finalizing. ___ 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] Fwd: [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c
Wupsie, this was meant for all of python-dev ;P-- Forwarded message --From: Thomas Wouters [EMAIL PROTECTED] Date: Mar 29, 2006 1:34 AMSubject: Re: [Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.cTo: Tim Peters [EMAIL PROTECTED] On 3/29/06, Tim Peters [EMAIL PROTECTED] wrote: ... that throws cycle-gc in a hissy fit;If by hissy fit you mean gcmodule properly moves generators to thelist of objects with finalizers, thereby preventing catastrophes, right, that's an intended hissy fit ;-) Well, I meant 'the durned thing refuses to do what I want it to do', which is clear cycles. I guess the hissy fit was mine ;) Did the best I could above, short of explaining exactly how failing toidentify an object with a finalizer can lead to disaster.Much appreciated. Short course:gc obviously needs to know which objects are and are nottrash.If a finalizer is associated with an object in cyclic trash,then trash objects are potentially visible _from_ the finalizer, andtherefore can be resurrected by running the finalizer.gc must therefore identify all trash objects reachable from trash objects withfinalizers, because running finalizers _may_ make all such objectsnot trash again.Getting any part of that wrong can lead to calling tp_clear on an object that a finalizer actually resurrects, leading tosymptoms from hey, all the attributes on my object suddenly vanishedby magic, for no reason at all to segfaults. So does that make all cycles involving only objects with finalizers impervious to cycle-gc? I guess it'd have to be that way. That also means I can stop searching for leaks in the C code, as we'll never be able to fix them all, anyway (although 'good code' could manually break many of the cycles.) At least not while keeping the tp_del of generator objects, not to mention avoiding finalizers on other builtin objects. (None seem to have them at the moment, they all do their stuff in tp_dealloc, which I guess doesn't allow objects to reincarnate themselves.) I'll see about fixing the Python code to avoid or explicitly break the cycles. Maybe we can patch regrtest.py to take into account uncollectable cycles, so that it could report them separately from refleaks. I'm going to think about all this first, though. Hrrm-hrrm'ly y'rs,-- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a finalizer virus! copy me into your tp_del slot to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c
On 3/29/06, Thomas Wouters [EMAIL PROTECTED] wrote: So does that make all cycles involving only objects with finalizers impervious to cycle-gc? I guess it'd have to be that way.Er, I meant to say 'does that make all cycles involving just one object with a finalizer impervious to cycle-gc'. -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
On Tue, 2006-03-28 at 18:24 -0500, Phillip J. Eby wrote: On the plus side, it sounds like ASPW is a more general wrapping of SQLite, which seems to me to lean in its favor for the stdlib, if it can also be brought into DBAPI compliance. If there's some general uncertainty about which to add, then it might make better sense to wait and not add either for Python 2.5. -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] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c
[Thomas Wouters] So does that make all cycles involving only objects with finalizers impervious to cycle-gc? I guess it'd have to be that way. [again] Er, I meant to say 'does that make all cycles involving just one object with a finalizer impervious to cycle-gc'. Both are true, and both are implied by this sharper variant: all cycles containing at least one object with a finalizer [etc] ___ 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] pysqlite for 2.5?
Yup; I'd be happy to see db.mysql and db.pgsql or whatnot added as appropriate, and having a nice new namespace ready for them is a good idea. I really wish that that namespace would be database, not db. 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] Fwd: [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c
[Thomas Wouters] ... not to mention avoiding finalizers on other builtin objects. (None seem to have them at the moment, they all do their stuff in tp_dealloc, Right, generators are the only exception now (and there were no exceptions before 2.5). which I guess doesn't allow objects to reincarnate themselves.) This is the actual rule: tp_dealloc must not do anything that could confuse cyclic gc 0.5 wink. I'm afraid that's the best writeup there is. If you have a few spare weeks, try to figure out exactly why subtype_dealloc() does what it does ;-) ... I'll see about fixing the Python code to avoid or explicitly break the cycles. Or giving gc more smarts about generators specifically (see Phillip's msg). Maybe we can patch regrtest.py to take into account uncollectable cycles, so that it could report them separately from refleaks. I'm going to think about all this first, though. Hrrm-hrrm'ly y'rs, -- Hi! I'm a finalizer virus! copy me into your tp_del slot to help me spread! LOL! Nice variation. ___ 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 can't imaging anybody relying on an in-place operations to return a different object, but we could make the change and run all the NumPy/SciPy tests to see what happens. I'm really thinking more about the non-inplace operators. If nb_add and sq_concat are collapsed into a single slot, it seems to me that if you do a = [1, 2, 3] b = array([4, 5, 6]) c = a + b then a will be asked Please add yourself to b, and a will say Okay, I know how to do that! and promptly concatenate itself with b. This would be very different from the current behaviour of Numeric arrays. I don't know whether Numeric users would consider it a serious problem or not, but I think we need to consider the implications before charging ahead too fast with slot unification. -- 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] pysqlite for 2.5?
Barry Warsaw [EMAIL PROTECTED] wrote: On Tue, 2006-03-28 at 18:24 -0500, Phillip J. Eby wrote: On the plus side, it sounds like ASPW is a more general wrapping of SQLite, which seems to me to lean in its favor for the stdlib, if it can also be brought into DBAPI compliance. If there's some general uncertainty about which to add, then it might make better sense to wait and not add either for Python 2.5. I'm not sure that there is uncertainty about *which* to add. So far we've seen a handful of +1s for pysqlite, but a link and short discussion about aspw. In my opinion, because pysqlite already has a DBAPI compliant interface to sqlite, and of us who have used it have had positive experiences, I don't see how aspw is even competition, let alone influential enough to push the adoption of an embedded SQL server to Python 2.6 or later. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
Barry Warsaw wrote: Perhaps the PySet API can raise an error if it's ever called on something that's not *exactly* a set? No subclassing allowed. Shouldn't affect you, and should be an effective deterrent against abuse of the kind that made the PyDict API an albatross. And perhaps in Py3k the same could be done for dicts, and any other builtin types with concrete access functions? -- 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
Armin Rigo wrote: [].__add__(5) TypeError: can only concatenate list (not int) to list Would that be much of a loss? It doesn't really give you much more information than something like Unsupported operand types for '+': list, int and what it does give is based on the assumption that concatenation is what the user has in mind. He might just as easily have been thinking of addition, or something else entirely. -- 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
Gareth McCaughan wrote: For what it's worth[1], I think Raymond is absolutely on crack here. +1 on a good concrete set API from me, too. Being such similar types, sets should have about the same API richness as dicts, IMO. -- 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: http://mail.python.org/pipermail/python-dev/2004-March/043462.html Or more precisely, the subsequent discussion and examples convinced me that putting class decorators on top of the class was bad for readability, vs. putting them in the body just after the docstring. I just looked at that discussion, and I didn't see any argument to refute the thesis that if decorators-on-top is good enough for functions, it should be good enough for classes. In fact it seems to have been written before the on-top decorator syntax existed, so there's no discussion of the issue at all. Seems to me that, since we now already have @-decorators for functions, a *very* good reason will be needed for requiring a completely different syntax to get exactly the same effect for classes. -- 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
At 02:55 PM 3/29/2006 +1200, Greg Ewing wrote: Phillip J. Eby wrote: http://mail.python.org/pipermail/python-dev/2004-March/043462.html Or more precisely, the subsequent discussion and examples convinced me that putting class decorators on top of the class was bad for readability, vs. putting them in the body just after the docstring. I just looked at that discussion, and I didn't see any argument to refute the thesis that if decorators-on-top is good enough for functions, it should be good enough for classes. In fact it seems to have been written before the on-top decorator syntax existed, so there's no discussion of the issue at all. Seems to me that, since we now already have @-decorators for functions, a *very* good reason will be needed for requiring a completely different syntax to get exactly the same effect for classes. And here it is: because the use cases for class decorators are different. I routinely use them with things that take numerous keyword arguments, but this isn't nearly as common of a scenario for function decorators. Also, class decorators are far more likely to be just registering the class with something -- which means they don't deserve so prominent a location as to obscure the class itself. ObDisclaimer: this is my personal experience and opinion. Others may have different use cases in mind. I'm just pointing out that if @decorator support were added for classes, I wouldn't use it, because it's not actually an improvement over what I'm doing now. Function decorators, OTOH, *are* an improvement over what I did before, so I use 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] Class decorators
On Tuesday 28 March 2006 22:06, Phillip J. Eby wrote: And here it is: because the use cases for class decorators are different. This is vague. I routinely use them with things that take numerous keyword arguments, but this isn't nearly as common of a scenario for function decorators. The zope.formlib decorators are commonly used with many arguments; those construct the replacements and register with a class-specific registry. Also, class decorators are far more likely to be just registering the class with something -- which means they don't deserve so prominent a location as to obscure the class itself. I've not looked at the Java and C# examples, so I don't claim anything about those examples. For all the cases where I'm registering classes, however, it's not a local registry, but something that lives elsewhere in the system; it doesn't affect the class itself at all. I'm happy for that use case to be supported in other ways than prefixing the class with decorator-syntax stuff. ObDisclaimer: this is my personal experience and opinion. Others may have different use cases in mind. I'm just pointing out that if @decorator support were added for classes, I wouldn't use it, because it's not actually an improvement over what I'm doing now. So it doesn't apply. I suspect this is something for which familiarity with the use cases for the Java and C# precedents would help. For Zope 3, we have decorators that work with the component architecture (I'm sure Phillip is familiar with these). They're used with functions to indicate that the function adapts a particular kind of object, or that it implements or provides a particular interface. We have different functions that get used for this purpose in classes that are executed within the body of the class. There's some merit to being able to use a single set of functions in both cases, since the use cases are the same. I'm not sure I'd want to change the existing pattern, though, since it's already so widespread within the Zope 3 codebase (including 3rd-party components). -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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 389 open ( -3) / 3117 closed (+23) / 3506 total (+20) Bugs: 901 open ( -6) / 5687 closed (+41) / 6588 total (+35) RFE : 214 open ( +1) / 206 closed ( +4) / 420 total ( +5) New / Reopened Patches __ Minimalist fix for bug 1446847 (2006-03-17) CLOSED http://python.org/sf/1452332 opened by Nick Coghlan N-d array interface for array object (2006-03-17) http://python.org/sf/1452906 opened by Alexander Belopolsky IDNA codec simplification (2006-03-18) http://python.org/sf/1453235 opened by Walter Dörwald popen2 new parameter and setpgid (2006-03-20) CLOSED http://python.org/sf/1454425 opened by Oskar Anderö 2 Tools for easy inter-thread communication-Queue,threading (2006-03-20) http://python.org/sf/1454452 opened by kxroberto Make thread stack size runtime tunable (2006-03-20) http://python.org/sf/1454481 opened by Andrew I MacIntyre patch for SIGSEGV in arraymodule.c (2006-03-20) http://python.org/sf/1454485 reopened by tbmetin patch for SIGSEGV in arraymodule.c (2006-03-20) http://python.org/sf/1454485 opened by Baris Metin Use dlopen() to load extensions on Darwin, where possible (2006-03-20) http://python.org/sf/1454844 opened by Zach Pincus patch for mbcs codecs (2006-03-22) http://python.org/sf/1455898 opened by ocean-city timestamp() method for datetime objects (2006-03-23) CLOSED http://python.org/sf/1457227 opened by Chris AtLee Support different GPG keys in upload --sign (2006-03-23) http://python.org/sf/1457316 opened by Stefan Behnel patch for building trunk with VC6 (2006-03-24) http://python.org/sf/1457736 opened by ocean-city floor division (2006-03-25) CLOSED http://python.org/sf/1458419 opened by Andy Improved PySet C API (2006-03-25) CLOSED http://python.org/sf/1458476 opened by Barry A. Warsaw Mutable Iterators PEP (2006-03-26) http://python.org/sf/1459011 opened by Adam DePrince Install PKG-INFO with packages (2006-03-27) http://python.org/sf/1459476 opened by Phillip J. Eby Add docs for zlib.decompressobj.flush optional param (2006-03-27) CLOSED http://python.org/sf/1459630 opened by Chris AtLee Update docs for zlib.decompressobj.flush() (2006-03-27) http://python.org/sf/1459631 opened by Chris AtLee convenient Message.as_string to use mangle_from_=unixfrom ? (2006-03-28) http://python.org/sf/1459867 opened by kxroberto Patches Closed __ PEP 338 implementation (2006-02-11) http://python.org/sf/1429601 closed by ncoghlan patch for 1441408 compiler fails to spot extended slice (2006-03-10) http://python.org/sf/1446847 closed by ncoghlan Minimalist fix for bug 1441408 (2006-03-17) http://python.org/sf/1452332 closed by ncoghlan PEP 338 documentation (2006-02-11) http://python.org/sf/1429605 closed by ncoghlan error checking after PyXXX_New (2006-03-08) http://python.org/sf/1445505 closed by gbrandl audioop - alaw encoding/decoding added, code updated (2005-07-02) http://python.org/sf/1231053 closed by anthonybaxter Method for cell objects to access contents (2005-03-25) http://python.org/sf/1170323 closed by gbrandl Incremental codecs for CJKCodecs (2006-03-05) http://python.org/sf/1443155 closed by perky A wait4() implementation (2005-09-30) http://python.org/sf/1309579 closed by nnorwitz Make itertools.tee participate in GC (2006-03-06) http://python.org/sf/1444398 closed by twouters more leaky, leaky (2006-03-07) http://python.org/sf/1445431 closed by nnorwitz Some fixes for the binary distribution builder (2005-12-14) http://python.org/sf/1380777 closed by ronaldoussoren popen2 new parameter and setpgid (2006-03-20) http://python.org/sf/1454425 closed by oskar_andero CALL_ATTR opcode (2003-03-26) http://python.org/sf/709744 closed by twouters FreeBSD is system scope threads capable (2006-01-04) http://python.org/sf/1396919 closed by perky timestamp() method for datetime objects (2006-03-23) http://python.org/sf/1457227 closed by gvanrossum Add method to function objects to simplify decoration (2005-03-12) http://python.org/sf/1161819 closed by ncoghlan Simplify using Queues with consumer threads (2006-03-21) http://python.org/sf/1455676 closed by rhettinger floor division (2006-03-25) http://python.org/sf/1458419 closed by nnorwitz Improved PySet C API (2006-03-25) http://python.org/sf/1458476 closed by gvanrossum Add docs for zlib.decompressobj.flush optional param (2006-03-27) http://python.org/sf/1459630 closed by gbrandl New / Reopened Bugs ___ xmlrpclib.py problem solved (2006-03-17) CLOSED http://python.org/sf/1452174 opened by varun bhansaly htmllib
Re: [Python-Dev] Class decorators
At 11:35 PM 3/28/2006 -0500, Fred L. Drake, Jr. wrote: For Zope 3, we have decorators that work with the component architecture (I'm sure Phillip is familiar with these). They're used with functions to indicate that the function adapts a particular kind of object, or that it implements or provides a particular interface. We have different functions that get used for this purpose in classes that are executed within the body of the class. There's some merit to being able to use a single set of functions in both cases, since the use cases are the same. I'm not sure I'd want to change the existing pattern, though, since it's already so widespread within the Zope 3 codebase (including 3rd-party components). If we're using Zope 3 as an example, I personally find that: class Foo: Docstring here, blah blah blah implements(IFoo) is easier to read than: @implements(IFoo) class Foo: Docstring here, blah blah blah And it only gets worse when you have lots of arguments or multiple decorators. For some reason, this doesn't bother me with functions. But then, I can't remember how often I've actually needed to use two decorators on the same function, or how many times a function decorator's arguments took multiple lines to list. Both of these are routine occurrences for my class use cases. It's too bad this syntax is ambiguous: class Foo: Docstring here, blah blah blah @implements(IFoo) As this achieves a desirable highlighting of the specialness, without forcing the decorator outside the class. Oh well. ___ 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 Wednesday 29 March 2006 00:01, Phillip J. Eby wrote: If we're using Zope 3 as an example, I personally find that: class Foo: Docstring here, blah blah blah implements(IFoo) is easier to read than: I think the existing usage for classes is perfectly readable. The @-syntax works well for functions as well. For some reason, this doesn't bother me with functions. But then, I can't remember how often I've actually needed to use two decorators on the same function, or how many times a function decorator's arguments took multiple lines to list. For zope.formlib actions, I find there's usually only one decorator. Sometimes it fits comfortably on one line, and sometimes it takes two or three. For component architecture decorators, we find we commonly use two (zope.interface.implementer and zope.component.adapter) in tandem. This can be fairly verbose with multi-object adaptation, or really long package names. It's too bad this syntax is ambiguous: class Foo: Docstring here, blah blah blah @implements(IFoo) As this achieves a desirable highlighting of the specialness, without forcing the decorator outside the class. Oh well. Agreed, but... guess we can't have everything. On the other hand, something like: class Foo: Documentation is good. @class implements(IFoo) is not ambiguous. Hmm. It even says what it means. :-) -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] Class decorators
On Wednesday 29 March 2006 00:48, Fred L. Drake, Jr. wrote: I think the existing usage for classes is perfectly readable. The @-syntax works well for functions as well. On re-reading what I wrote, I don't think I actually clarified the point I was trying to make originally. My point wasn't that I desparately need @-syntax for class decorators (I don't), or see it as inherantly superior in some way. It's much simpler than that: I just want to be able to use the same syntax for a group of use cases regardless of whether the target is a function or a class. This fits into the nice-to-have category for me, since the use case can be the same regardless of whether I'm decorating a class or a function. (I will note that when this use case applies to a function, it's usually a module-level function I'm decorating rather than a method.) My other example, the zope.formlib example, has only ever involved a single decorator, and is always a method. It could conceivably be applied to a nested class without much of a stretch, however. -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] PySet API
Greg Ewing [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Gareth McCaughan wrote: For what it's worth[1], I think Raymond is absolutely on crack here. +1 on a good concrete set API from me, too. For what it's worth, I think Gareth's crack at Raymond is childish and out of place here. tjr ___ 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 abug/patch
On 3/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Roundup is there now, right (sans SF export)? Richard Jones has an SF importer for one of the two XML-like formats, the one that is correct XML but with incomplete data. The other format, which has complete data but is ill-formed XML, has no importer into roundup at the moment. Trac is being used by the folks doing the new website. What other candidates are being considered? My view is that nothing should be considered unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide. And as the chair of the infrastructure committee, those are the base requirements for a tracker to be considered. Once we have the complete SF data I will put out a call for proposals for trackers along with who has volunteered to manage them so that people can band together to help push their favorite tracker. But as of right now the committe just wants to get a clean dump of our SF data to work off of (yes, we could start a tracker from scratch but we want the SF data anyway and so we are going through the hassle of getting it off now and as a test data set for the various trackers). -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
