On Tue, 2005-02-01 at 10:30 +1100, Donovan Baarda wrote:
> On Mon, 2005-01-31 at 15:16 -0500, Nathan Binkert wrote:
> > > Wouldn't it be nicer to have a facility that let you send messages
> > > between processes and manage concurrency properly instead? You'll need
[...]
> A quick google search re
On Mon, 2005-01-31 at 15:16 -0500, Nathan Binkert wrote:
> > Wouldn't it be nicer to have a facility that let you send messages
> > between processes and manage concurrency properly instead? You'll need
> > most of this anyway to do multithreading sanely, and the benefit to the
> > multiple proces
> Wouldn't it be nicer to have a facility that let you send messages
> between processes and manage concurrency properly instead? You'll need
> most of this anyway to do multithreading sanely, and the benefit to the
> multiple process model is that you can scale to multiple machines, not
> just pr
Barry Warsaw wrote:
I've heard rumors that SF was going to be making svn available. Anybody
know more about that? I'd be +1 on moving from cvs to svn.
It was on their "things we do in 2005" list. 2005 isn't over yet...
I wouldn't be surprised if it gets moved to their "things we do in 2006"
list
Evan Jones wrote:
The next page has a
micro-benchmark that shows reference counting performing very poorly.
Not to mention that Python has a garbage collector *anyway,* so wouldn't
it make sense to get rid of the reference counting?
It's not clear what these numbers exactly mean, but I don't bel
On Jan 31, 2005, at 10:43, Evan Jones wrote:
On Jan 31, 2005, at 0:17, Guido van Rossum wrote:
The "just kidding" applies to the whole list, right? None of these
strike me as good ideas, except for improvements to function argument
passing.
Really? You see no advantage to moving to garbage collecti
On Jan 31, 2005, at 0:17, Guido van Rossum wrote:
The "just kidding" applies to the whole list, right? None of these
strike me as good ideas, except for improvements to function argument
passing.
Really? You see no advantage to moving to garbage collection, nor
allowing Python to leverage multiple
On Mon, 2005-01-31 at 00:00, Skip Montanaro wrote:
> Raymond> I had hoped for the core of p3k to be built for scratch ...
>
> Then we should just create a new CVS module for it (or go whole hog and try
> a new revision control system altogether - svn, darcs, arch, whatever).
I've heard rumors
On Mon, 2005-01-31 at 00:17, Guido van Rossum wrote:
> > I had hoped for the core of p3k to be built for scratch [...]
>
> Stop right there.
Phew!
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
P
> I had hoped for the core of p3k to be built for scratch [...]
Stop right there.
I used to think that was a good idea too, and was hoping to do exactly
that (after retirement :). However, the more I think about it, the
more I believe it would be throwing away too much valuable work.
Please read
Raymond> I had hoped for the core of p3k to be built for scratch ...
Then we should just create a new CVS module for it (or go whole hog and try
a new revision control system altogether - svn, darcs, arch, whatever).
Skip
___
Python-Dev mailing lis
Neal Norwitz
> I thought about making a p3k branch in CVS
I had hoped for the core of p3k to be built for scratch so that even the
most pervasive and fundamental implementation choices would be open for
discussion:
* Possibly write in C++.
* Possibly replace bytecode with Forth style threaded co
Neal Norwitz wrote:
On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
[SNIP]
Any ideas how we could start to realize some benefits of Py3.0 before
it arrives? I'm not sure if this is worth it, if it's premature, or
if there are other ways to acheive the goal of easin
On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> This is what I mean about the patch taking on a life of its own. It's
> an optimization patch that slows down METH_O and METH_NOARGS. It's a
> incremental change that throws away backwards compatibility. It's a
On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I agree that METH_O and METH_NOARGS are near
> > optimal wrt to performance. But if we could have one METH_UNPACKED
> > instead of 3 METH_*, I think that would be a win.
> . . .
> > Sorry, I meant eliminated w/3.
> I agree that METH_O and METH_NOARGS are near
> optimal wrt to performance. But if we could have one METH_UNPACKED
> instead of 3 METH_*, I think that would be a win.
. . .
> Sorry, I meant eliminated w/3.0.
So, leave METH_O and METH_NOARGS alone. They can't be dropped until 3.0
and they can'
Neal Norwitz wrote:
> [...]
This is the python test coverage:
http://coverage.livinglogic.de/coverage/web/selectEntry.do?template=2850&entryToSelect=182530
This link won't work because of session management. To get the
coverage info of ceval.c go to http://coverage.livinglogic.de,
click on the
Neal Norwitz <[EMAIL PROTECTED]> writes:
>> * not handling more than nine arguments,
>
> There are very few functions I've found that take more than 2
> arguments. Should 9 be lower, higher? I don't have a good feel.
> From what I've seen, 5 may be more reasonable as far as catching 90%
> of the
Neal Norwitz wrote:
So far it seems there isn't any specific problems with the approach.
There are simply concerns. I not sure it would be best to modify this
patch over many iterations and then make one huge checkin. I also
don't want to lose the changes or the results. Perhaps I should make
a
On Tue, 25 Jan 2005 06:42:57 -0500, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
> >
> > I think tested a method I changed from METH_O to METH_ARGS and could
> > not measure a difference.
>
> Something is probably wrong with the measurements. The new call does much
> more work than METH_O or MET
> > In theory, I don't see how you could improve on METH_O and METH_NOARGS.
> > The only saving is the time for the flag test (a predictable branch).
> > Offsetting that savings is the additional time for checking min/max args
> > and for constructing a C call with the appropriate number of args.
Neal Norwitz wrote:
EXT_POP() modifies stack_pointer on the stack. In call_function(),
stack_pointer is PyObject ***. But in new_fast_function(), stack_pointer
is only PyObject **. So the modifications by EXT_POP to stack_pointer
(moving it down) are lost in new_fast_function().
Thanks - that i
On Tue, 25 Jan 2005 00:30:44 +0100, "Martin v. Löwis"
<[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> >>Where are the Py_DECREFs done for the function arguments?
> >
> > The original code path still handles the Py_DECREFs.
> > This is the while loop at the end of call_function().
>
> Can you pl
On Mon, 24 Jan 2005 03:11:05 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> Replacing METH_O and METH_NOARGS seems straight-forward, but
> METH_VARARGS has much broader capabilities. How would you handle the
> simple case of "O|OO"? How could you determine useful default values
> (NULL,
Neal Norwitz wrote:
Where are the Py_DECREFs done for the function arguments?
The original code path still handles the Py_DECREFs.
This is the while loop at the end of call_function().
Can you please elaborate? For METH_O and METH_ARGS,
the arguments have already been popped off the stack,
and the
On Mon, 24 Jan 2005 23:36:24 +0100, "Martin v. Löwis"
<[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > I would like feedback on whether the approach is desirable.
>
> I'm probably missing something really essential, but...
>
> Where are the Py_DECREFs done for the function arguments?
The ori
Neal Norwitz wrote:
I would like feedback on whether the approach is desirable.
I'm probably missing something really essential, but...
Where are the Py_DECREFs done for the function arguments?
Also, changing PyArg_ParseTuple is likely incorrect.
Currently, chr/unichr expects float values; with you
[Neal Norwitz]
> I would like feedback on whether the approach is desirable.
>
> The patch adds a new method type (flags) METH_ARGS that is used in
> PyMethodDef. METH_ARGS means the min and max # of arguments are
> specified in the PyMethodDef by adding 2 new fields. This information
> can be use
I added a patch to SF: http://python.org/sf/1107887
I would like feedback on whether the approach is desirable.
The patch adds a new method type (flags) METH_ARGS that is used in
PyMethodDef. METH_ARGS means the min and max # of arguments are
specified in the PyMethodDef by adding 2 new fields.
29 matches
Mail list logo
