Re: [Python-Dev] s/hotshot/lsprof

2005-11-21 Thread Armin Rigo
Hi Barry, On Mon, Nov 21, 2005 at 09:25:05AM -0500, Barry Warsaw wrote: > hotshot used to produce incorrect data because it couldn't track exits > from functions due to exception propagation. We fixed that a while back It might be me, but I find it a bit odd that you didn't do anything with this

Re: [Python-Dev] s/hotshot/lsprof

2005-11-21 Thread Armin Rigo
Hi Barry, On Mon, Nov 21, 2005 at 11:40:37AM -0500, Barry Warsaw wrote: > Hi Armin. Actually it was SF #900092 that I was referring to. Ah, we're talking about different things then. The patch in SF #900092 is not related to hotshot, it's just ceval.c not producing enough events to allow a prec

Re: [Python-Dev] s/hotshot/lsprof

2005-11-21 Thread Armin Rigo
Hi Floris, On Mon, Nov 21, 2005 at 04:41:04PM +, Floris Bruynooghe wrote: > > Now Brett's > > student, Floris, extended hotshot to allow custom timers. This is > > essential, because it enables testing. The timing parts of hotshot were > > not tested previously. > > Don't be too enthousiast

Re: [Python-Dev] s/hotshot/lsprof

2005-11-21 Thread Armin Rigo
Hi Floris, On Mon, Nov 21, 2005 at 04:45:03PM +, Floris Bruynooghe wrote: > Afaik I did test recursive calls etc. It seems to show up in any test case I try, e.g. import hprofile def wait(m): if m > 0: wait(m-1) def f(n): wait(n) if n > 1:

Re: [Python-Dev] s/hotshot/lsprof

2005-11-21 Thread Armin Rigo
Hi Martin, On Mon, Nov 21, 2005 at 10:29:55PM +0100, "Martin v. L?wis" wrote: > > I see no incremental way of fixing some of the downsides of hotshot, > > like its huge log file size and loading time. > > I haven't looked into the details myself, but it appears that some > google-summer-of-code c

Re: [Python-Dev] s/hotshot/lsprof

2005-11-22 Thread Armin Rigo
Hi Brett, On Mon, Nov 21, 2005 at 11:35:37PM -0800, Brett Cannon wrote: > (any chance we can replace profile with a wrapper to lsprof > without much issue?) Yes. In fact I am thinking about adding lsprof under the module name 'cProfile', to keep true to the (IMHO) good tradition of pickle/cPickl

Re: [Python-Dev] Problems with the Python Memory Manager

2005-11-24 Thread Armin Rigo
Hi, On Thu, Nov 24, 2005 at 01:59:57AM -0800, Robert Kern wrote: > You can get the version of scipy_core just before the fix that Travis > applied: Now we can start debugging :-) > http://projects.scipy.org/scipy/scipy_core/changeset/1490 This changeset alone fixes the small example you provi

Re: [Python-Dev] Problems with the Python Memory Manager

2005-11-24 Thread Armin Rigo
Hi, Ok, here is the reason for the leak... There is in scipy a type called 'int32_arrtype' which inherits from both another scipy type called 'signedinteger_arrtype', and from 'int'. Obscure! This is not 100% officially allowed: you are inheriting from two C types. You're living dangerously! N

Re: [Python-Dev] Problems with mro for dual inheritance in C [Was: Problems with the Python Memory Manager]

2005-11-24 Thread Armin Rigo
Hi Travis, On Thu, Nov 24, 2005 at 10:17:43AM -0700, Travis E. Oliphant wrote: > Why doesn't the int32 > type inherit its tp_free from the early types first? In your case I suspect that the tp_free is inherited from the tp_base which is probably 'int'. I don't see how to "fix" typeobject.c, bec

Re: [Python-Dev] Problems with the Python Memory Manager

2005-11-25 Thread Armin Rigo
Hi Jim, You wrote: > >(2) Is he allocating new _types_, which I think don't get properly > > collected. (Off-topic) For reference, as far as I know new types are properly freed. There has been a number of bugs and lots of corner cases to fix, but I know of no remaining one. This assumes that t

Re: [Python-Dev] reference leaks

2005-11-25 Thread Armin Rigo
Hi Neal, On Thu, Nov 24, 2005 at 07:35:06PM -0800, Neal Norwitz wrote: > The itertools.tee() fix I thought was quite obvious: > > +++ Modules/itertoolsmodule.c (working copy) > @@ -356,7 +356,8 @@ > { > if (tdo->nextlink == NULL) > tdo->nextlink = teedataobject_new(tdo-

Re: [Python-Dev] For Python 3k, drop default/implicit hash, and comparison

2005-11-27 Thread Armin Rigo
Hi Noam, On Sun, Nov 27, 2005 at 09:04:25PM +0200, Noam Raphael wrote: > No, I meant real programming examples. My theory is that most > user-defined classes have a "value", and those that don't are related > to I/O, in some sort of a broad definition of the term. I may be > wrong, so I ask for co

Re: [Python-Dev] should I really have to install Python before Icanbuild it ?

2005-12-12 Thread Armin Rigo
Hi Fredrik, On Mon, Dec 12, 2005 at 10:23:27PM +0100, Fredrik Lundh wrote: > $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) > -$(PYTHON) $(ASDLGEN) $(AST_ASDL) I suppose that the trick is in the "-" sign here. If this command fails for any reason you get warnings and errors but the buil

Re: [Python-Dev] Expose Subversion revision number to Python

2005-12-16 Thread Armin Rigo
Hi Barry, On Fri, Dec 16, 2005 at 12:16:49AM -0500, Barry Warsaw wrote: > SF patch # 1382163 is a fairly simple patch to expose the Subversion > revision number to Python, both in the Py_GetBuildInfo() text, and in a > new Py_GetBuildNumber() C API function, and via a new sys.build_number > attrib

Re: [Python-Dev] Expose Subversion revision number to Python

2005-12-16 Thread Armin Rigo
Hi Phillip, On Fri, Dec 16, 2005 at 10:51:33AM -0500, Phillip J. Eby wrote: > svn info -R|grep '^Last Changed Rev'|sort -nr|head -1|cut -f 4 -d" " > > To get the highest-numbered revision. However, both this approach and > yours will not deal with Subversion messages in non-English locales

Re: [Python-Dev] Expose Subversion revision number to Python

2005-12-16 Thread Armin Rigo
Hi Skip, On Fri, Dec 16, 2005 at 05:02:19AM -0600, [EMAIL PROTECTED] wrote: > Armin> ("trunk" is the last part of the path returned by "svn info".) > Did you mean the last part of the URL? Yes, sorry. Armin ___ Python-Dev mailing list Python-Dev@

Re: [Python-Dev] Expose Subversion revision number to Python

2005-12-16 Thread Armin Rigo
Hi Phillip, On Fri, Dec 16, 2005 at 10:59:23AM -0500, Phillip J. Eby wrote: > The "Revision" from "svn info" isn't reliable; it doesn't actually relate > to what version of code is in the subtree. It can change when nothing has > changed. Indeed, the patch should not use the "Revision" line bu

Re: [Python-Dev] Expose Subversion revision number to Python

2005-12-16 Thread Armin Rigo
Hi Phillip, On Fri, Dec 16, 2005 at 11:33:00AM -0500, Phillip J. Eby wrote: > >Not if you're happy with "Last Changed Rev": > > > > LC_ALL=C svn info | grep -i "last changed rev" | cut -f 4 -d " " > > You left off the all-important "-R" from "svn info", and the "sort -nr | > head -1" at the

Re: [Python-Dev] Expose Subversion revision number to Python

2005-12-17 Thread Armin Rigo
Hi Martin, On Sat, Dec 17, 2005 at 11:32:54AM +0100, "Martin v. L?wis" wrote: > > trunk$ svn up > > At revision xxx. > > trunk$ svn info > > Last Changed Rev: 1 > > trunk$ cd Python > > trunk/python$ svn info > > Last Changed Rev: 10001 > > It is possible: > sv

Re: [Python-Dev] Expose Subversion revision number to Python

2005-12-18 Thread Armin Rigo
Hi Barry, On Sat, Dec 17, 2005 at 08:28:17PM -0500, Barry Warsaw wrote: > Done. r41744. Doesn't appear to work for me: sys.build_number receives the value from the buildno. Looking at the Makefile, the reason is that I'm building CPython in a separate directory (running '/some/path/configure; ma

Re: [Python-Dev] NotImplemented reaching top-level

2005-12-25 Thread Armin Rigo
Hi Facundo, On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote: > >>> d += 1.2 > >>> d > NotImplemented The situation appears to be a mess. Some combinations of specific operators fail to convert NotImplemented to a TypeError, depending on old- or new-style-class-ness, although this

Re: [Python-Dev] NotImplemented reaching top-level

2005-12-25 Thread Armin Rigo
Hi Reinhold, On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote: > > that nobody fully understands the convoluted code paths of abstract.c > > any more :-( > > Time for a rewrite? Of course, speaking of a rewrite, PyPy does the "right thing" in these two areas. Won't happen to

Re: [Python-Dev] NotImplemented reaching top-level

2005-12-26 Thread Armin Rigo
Hi Brett, On Sun, Dec 25, 2005 at 11:55:11AM -0800, Brett Cannon wrote: > Maybe. Also realize we will have a chance to clean it up when Python > 3 comes around since the classic class stuff will be ripped out. That > way we might have a chance to streamline the code. For once, old-style classes

Re: [Python-Dev] NotImplemented reaching top-level

2005-12-26 Thread Armin Rigo
Hi, On Mon, Dec 26, 2005 at 02:40:38AM +1000, Nick Coghlan wrote: > That sounds like the right definition to me (I believe this behaviour is what > Raymond and Facundo were aiming for with the last round of updates to > Decimal). Done in patch #1390657. Although this patch passes all existing

Re: [Python-Dev] deque alternative

2005-12-27 Thread Armin Rigo
Hi Christian, On Mon, Dec 26, 2005 at 01:38:37PM +0100, Christian Tismer wrote: > I don't think your code has to decide about this. The power lies > in the fact that you don't specify that, but just use the list > in a different way. We do this in the PyPy implementation; > right now it is true th

Re: [Python-Dev] NotImplemented reaching top-level

2005-12-27 Thread Armin Rigo
Hi Facundo, On Mon, Dec 26, 2005 at 02:31:10PM -0300, Facundo Batista wrote: > > nb_add and nb_multiply should be tried. I don't think that this would > > break existing C or Python code, but it should probably only go in 2.5, > > together with the patch #1390657 that relies on it. > > It'd be g

Re: [Python-Dev] NotImplemented reaching top-level

2005-12-28 Thread Armin Rigo
Hi Marc, On Wed, Dec 28, 2005 at 09:56:43PM +0100, M.-A. Lemburg wrote: > > d += 1.2 > > d > >> NotImplemented > > The PEP documenting the coercion logic has complete tables > for what should happen: Well, '+=' does not invoke coercion at all, with new-style classes like Decimal. > Look

Re: [Python-Dev] New PEP: Using ssize_t as the index type

2005-12-29 Thread Armin Rigo
Hi Martin, On Thu, Dec 29, 2005 at 03:04:30PM +0100, "Martin v. L?wis" wrote: > New conversion functions PyInt_FromSsize_t, PyInt_AsSsize_t, > PyLong_AsSsize_t are introduced. PyInt_FromSsize_t will transparently > return a long int object if the value exceeds the MAX_INT. I guess you mean LONG_M

Re: [Python-Dev] buildno (Was: [Python-checkins] commit of r41907- python/trunk/Makefile.pre.in)

2006-01-05 Thread Armin Rigo
Hi Martin, On Thu, Jan 05, 2006 at 12:36:40AM +0100, "Martin v. L?wis" wrote: > OTOH, I also think we should get rid of buildno entirely. Instead, > svnversion should be compiled into the object file, or, if it is absent, > $Revision$ should be used; the release process should be updated to > forc

Re: [Python-Dev] New PEP: Using ssize_t as the index type

2006-01-05 Thread Armin Rigo
Hi Martin, On Fri, Dec 30, 2005 at 11:26:44AM +0100, "Martin v. L?wis" wrote: > > Hum. It would be much cleaner to introduce a new format character to > > replace '#' and deprecate '#'... > > That would certainly be clearer. What character would you suggest? > > I see two drawbacks with that ap

Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0

2006-01-06 Thread Armin Rigo
Hi Alexander, On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote: > There are three different peculiarity in Python 2.x > in respect of 'self' method argument: Yuk! This has been discussed again and again already. *Please* move this discussion to comp.lang.python. A bientot,

Re: [Python-Dev] Ph.D. dissertation ideas?

2006-01-14 Thread Armin Rigo
Hi Brett, If by any chance PyPy continues to be funded beyond 2006, we would definitely welcome you around :-) (If our funding model doesn't change, it might be difficult for us to give you money oversea, though... just asking, just in case, would you consider moving to a European university?) P

[Python-Dev] Summer of PyPy

2006-01-17 Thread Armin Rigo
Hi Brett, hi all, On Sat, Jan 14, 2006 at 05:51:25PM -0800, Brett Cannon wrote: > That would be cool! I definitely would not mind working on PyPy. > Unfortunately I would not consider changing universities; I really > like it here. We are looking at the possibility to do a "Summer of PyPy" in t

Re: [Python-Dev] str with base

2006-01-17 Thread Armin Rigo
Hi Alex, > Is it finally time in Python 2.5 to allow the "obvious" use of, say, > str(5,2) to give '101', just the converse of the way int('101',1) > gives 5? +1. That's obvious enough for me. Clearly it should only work with int and long arguments, just like int(x,base) only works if x is a st

[Python-Dev] cProfile module

2006-02-07 Thread Armin Rigo
Hi all, As promized two months ago, I eventually finished the integration of the 'lsprof' profiler. It's now in an internal '_lsprof' module that is exposed via a 'cProfile' module with the same interface as 'profile', producing compatible dump stats that can be inspected with 'pstats'. See prev

[Python-Dev] _length_cue()

2006-02-08 Thread Armin Rigo
Hi all, Last september, the __len__ method of iterators was removed -- see discussion at: http://mail.python.org/pipermail/python-dev/2005-September/056879.html It was replaced by an optional undocumented method called _length_cue(), which would be used to guess the number of remaining items in

Re: [Python-Dev] _length_cue()

2006-02-08 Thread Armin Rigo
Hi Raymond, On Wed, Feb 08, 2006 at 03:02:21PM -0500, Raymond Hettinger wrote: > IMHO, the "safety reasons" are imaginary -- the scenario would involve > subclassing one of these builtin objects and attaching an identically named > private method. No, the senario applies to any user-defined ite

Re: [Python-Dev] _length_cue()

2006-02-10 Thread Armin Rigo
Hi Greg, On Thu, Feb 09, 2006 at 04:27:54PM +1300, Greg Ewing wrote: > The iterator protocol is currently very simple and > well-focused on a single task -- producing things > one at a time, in sequence. Let's not clutter it up > with too much more cruft. Please refer to my original message: I in

Re: [Python-Dev] _length_cue()

2006-02-10 Thread Armin Rigo
Hi Nick, On Fri, Feb 10, 2006 at 11:21:52PM +1000, Nick Coghlan wrote: > Do they really need anything more sophisticated than: > >def __repr__(self): > return "%s(%r)" % (type(self).__name__, self._subiter) > > (modulo changes in the format of arguments, naturally. This simple one would

Re: [Python-Dev] _length_cue()

2006-02-10 Thread Armin Rigo
Hi Raymond, On Wed, Feb 08, 2006 at 09:21:02PM -0500, Raymond Hettinger wrote: > (... __getitem_cue__ ...) > Before putting this in production, it would probably be worthwhile to search > for code where it would have been helpful. In the case of __length_cue__, > there was an immediate payoff.

Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification

2006-02-11 Thread Armin Rigo
Hi Tim, On Fri, Feb 10, 2006 at 12:19:01PM -0500, Tim Peters wrote: > Oh, who cares? I predict "Jack's problem" would go away if we changed > the declaration of PyArg_ParseTupleAndKeywords to what you intended > to begin with: > > PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject

<    1   2   3   4