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
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
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
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:
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
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
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
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
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
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
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-
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
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
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
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
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@
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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.
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
301 - 341 of 341 matches
Mail list logo