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
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
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
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
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
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
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
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 ?
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
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
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
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,
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
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
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
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
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.
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
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
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
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
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,
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
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?
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
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:
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.
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
[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
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
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.
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
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
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,
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
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
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
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
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
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
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.
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
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
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
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
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
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
[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
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
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
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
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'.
--
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
[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
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
[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
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
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
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
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
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
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.
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.
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.
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
__
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
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
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
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
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
70 matches
Mail list logo
