RE: [Python-Dev] Speed up function calls

[Raymond Hettinger]

[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 used in ceval to
> call the method. No tuple packing/unpacking is required since the C
> stack is used.
> 
> The benefits are:
>  * faster function calls
>  * simplify function call machinery by removing METH_NOARGS, METH_O,
> and possibly METH_VARARGS
>  * more introspection info for C functions (ie, min/max arg count)
> (not implemented)

An additional benefit would be improving the C-API by allowing C calls
without creating temporary argument tuples.  Also, some small degree of
introspection becomes possible when a method knows its own arity.

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, 0, -1, -909, etc.)?

If you solve the default value problem, then please also try to come up
with a better flag name than METH_ARGS which I find to be indistinct
from METH_VARARGS and also not very descriptive of its functionality.
Perhaps something like METH_UNPACKED would be an improvement.



> The drawbacks are:
>  * the defn of the MethodDef (# args) is separate from the function
defn
>  * potentially more error prone to write C methods???

No worse than with METH_O or METH_NOARGS.



> I've measured between 13-22% speed improvement (debug build on
> Operton) when doing simple tests like:
> 
>  ./python ./Lib/timeit.py -v 'pow(3, 5)'
> 
> I think the difference tends to be fairly constant at about .3 usec
per
> loop.

If speed is the main advantage being sought, it would be worthwhile to
conduct more extensive timing tests with a variety of code and not using
a debug build.  Running test.test_decimal would be a useful overall
benchmark.

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.  I
suspect there is no savings here and that the timings will get worse.

In all likelihood, the only real opportunity for savings is replacing
METH_VARARGS in cases that have already been sped-up using
PyTuple_Unpack().  Those can be further improved by eliminating the time
to build and unpack the temporary argument tuple.

Even then, I don't see how to overcome the need to set useful default
values for optional object arguments.



Raymond Hettinger

___
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] Allowing slicing of iterators

[Nick Coghlan]

I just wrote a new C API function (PyItem_GetItem) that supports slicing for 
arbitrary iterators. A patch for current CVS is at http://www.python.org/sf/1108272

For simple indices it does the iteration manually, and for extended slices it 
returns an itertools.islice object.

As a trivial example, here's how to skip the head of a zero-numbered list:
  for i, item in enumerate("ABCDEF")[1:]:
print i, item
Is this idea a non-starter, or should I spend my holiday on Wednesday finishing 
it off and writing the documentation and tests for it?

Regards,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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 the Python Memory Allocator

[Rodrigo Dias Arruda Senra]

Evan Jones wrote:
This message is a follow up to a thread I started on python-dev back in 
October, archived here:

First, there is slightly more overhead with programs that allocate a lot 
of memory, release it, then reallocate it.

Summary of the changes:
- When freeing a page, if the arena is completely unused, the arena is 
deallocated.
Depending on the cost of arena allocation, it might help to define a 
lower threshold keeping a minimum of empty arena_objects permanently
available. Do you think this can bring any speedup ?

cheers,
Senra
--
Rodrigo Senra
MSc Computer Engineer [EMAIL PROTECTED]
GPr Sistemas Ltda   http://www.gpr.com.br
___
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 the Python Memory Allocator

[Evan Jones]

On Jan 24, 2005, at 7:00, Rodrigo Dias Arruda Senra wrote:
Depending on the cost of arena allocation, it might help to define a 
lower threshold keeping a minimum of empty arena_objects permanently 
available. Do you think this can bring any speedup ?
Yes, I think it might. I have to do some more benchmarking first, to 
try and figure out how expensive the allocations are. This is one of my 
"future work" items to work on if this change gets accepted. I have not 
implemented it yet, because I don't want to have to merge one *massive* 
patch. My rough idea is to do something like this:

1. Keep track of the largest number of pages in use at one time.
2. Every N memory operations (or some other measurement of "time"), 
reset this value and calculate a moving average of the number of pages. 
This estimates the current memory requirements of the application.

3. If (used + free) > average, free arenas until freeing one more arena 
would make (used + free) < average.

This is better than a static scheme which says "keep X MB of free 
memory around" because it will self-tune to the application's 
requirements. If you have an applications that needs lots of RAM, it 
will keep lots of RAM. If it has very low RAM usage, it will be more 
aggressive in reclaiming free space. The challenge is how to determine 
a good measurement of "time." Ideally, if the application was idle for 
a while, you would perform some housekeeping like this. Does Python's 
cyclic garbage collector currently do this? If so, I could hook this 
"management" stuff on to its calls to gc.collect()

Evan Jones
___
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 the Python Memory Allocator

[Rodrigo Dias Arruda Senra]

[Evan Jones] :
--
2. Every N memory operations (or some other measurement of "time"), 
reset this value and calculate a moving average of the number of pages. 
This estimates the current memory requirements of the application.
> The challenge is how to determine a good measurement of "time."
> Ideally, if the application was idle for a while,
you would perform some housekeeping like this. Does Python's cyclic 
garbage collector currently do this? If so, I could hook this 
"management" stuff on to its calls to gc.collect()
IMVHO, any measurement of "time" chosen would hurt performance of
non-memory greedy applications. OTOH, makes sense for the developers
of memory greedy applications (they should be aware of it )
to call gc.collect() periodically. Therefore, *hooking* gc.collect()
sounds about right to me, let the janitoring pace be defined by those
who really care about it.
Looking forward to see this evolve,
Senra
--
Rodrigo Senra
MSc Computer Engineer [EMAIL PROTECTED]
GPr Sistemas Ltda   http://www.gpr.com.br
___
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] Allowing slicing of iterators

[Guido van Rossum]

> I just wrote a new C API function (PyItem_GetItem) that supports slicing for
> arbitrary iterators. A patch for current CVS is at 
> http://www.python.org/sf/1108272
> 
> For simple indices it does the iteration manually, and for extended slices it
> returns an itertools.islice object.
> 
> As a trivial example, here's how to skip the head of a zero-numbered list:
> 
>for i, item in enumerate("ABCDEF")[1:]:
>  print i, item
> 
> Is this idea a non-starter, or should I spend my holiday on Wednesday 
> finishing
> it off and writing the documentation and tests for it?

Since we already have the islice iterator, what's the point? It seems
to me that introducing this notation would mostly lead to confuse
users, since in most other places a slice produces an independent
*copy* of the data.

-- 
--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] Allowing slicing of iterators

[Batista, Facundo]

Title: RE: [Python-Dev] Allowing slicing of iterators





[Guido van Rossum]


#- > As a trivial example, here's how to skip the head of a 
#- zero-numbered list:
#- > 
#- >    for i, item in enumerate("ABCDEF")[1:]:
#- >  print i, item
#- > 
#- > Is this idea a non-starter, or should I spend my holiday 
#- on Wednesday finishing
#- > it off and writing the documentation and tests for it?
#- 
#- Since we already have the islice iterator, what's the point? It seems
#- to me that introducing this notation would mostly lead to confuse
#- users, since in most other places a slice produces an independent
#- *copy* of the data.


I think that breaking the common idiom...


  for e in something[:]:
  something.remove(e)


is a no-no...


.    Facundo


Bitácora De Vuelo: http://www.taniquetil.com.ar/plog
PyAr - Python Argentina: http://pyar.decode.com.ar/



  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADVERTENCIA.


La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley.

Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo.

Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada.

Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje.

Muchas Gracias.



___
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] Speed up function calls

["Martin v. Löwis"]

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 your
change, I believe it won't anymore.
Apart from that, the change looks fine to me.
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] Speed up function calls

[Neal Norwitz]

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 original code path still handles the Py_DECREFs.
This is the while loop at the end of call_function().

I hope to refine the patch further in this area.

> Also, changing PyArg_ParseTuple is likely incorrect.
> Currently, chr/unichr expects float values; with your
> change, I believe it won't anymore.

You are correct there is an unintended change in behaviour:

Python 2.5a0 (#51, Jan 23 2005, 18:54:53)
>>> chr(5.3)
'\x05'

Python 2.3.4 (#1, Dec  7 2004, 12:24:19)
>>> chr(5.3)
__main__:1: DeprecationWarning: integer argument expected, got float
'\x05'

This needs to be fixed.

Neal
___
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 the Python Memory Allocator

["Martin v. Löwis"]

Here my comments, from more general to more subtle:
- please don't post patches here; post them to SF
  You may ask for comments here after you posted them to SF.
- please follow Python coding style. In particular, don't write
if ( available_arenas == NULL ) {
  but write
if (available_arenas == NULL) {
Second, the previous allocator went out of its way to permit a module to 
call PyObject_Free while another thread is executing PyObject_Malloc. 
Apparently, this was a backwards compatibility hack for old Python 
modules which erroneously call these functions without holding the GIL. 
These modules will have to be fixed if this implementation is accepted 
into the core.
I'm not certain it is acceptable to make this assumption. Why is it
not possible to use the same approach that was previously used (i.e.
leak the arenas array)?
- When allocating a page, it is taken from the arena that is the most 
full. This gives arenas that are almost completely unused a chance to be 
freed.
It would be helpful if that was documented in the data structures
somewhere. The fact that the nextarena list is sorted by nfreepools
is only mentioned in the place where this property is preserved;
it should be mentioned in the introductory comments as well.
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] Speed up function calls

["Martin v. Löwis"]

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 "What does this do" loop only pops off the
function itself. So (without testing) methinks your
code currently leaks references.
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] Speed up function calls

[Neal Norwitz]

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, 0, -1, -909, etc.)?

I have a new version of the patch that handles this condition.
I pass NULLs for non-existant optional parameters.  In your
case above, the arguments passed would be:

(obj, NULL, NULL)

This is handled pretty cleanly in the callees, since it is
pretty common to initialize optional params to NULL.

> If you solve the default value problem, then please also try to come up
> with a better flag name than METH_ARGS which I find to be indistinct
> from METH_VARARGS and also not very descriptive of its functionality.
> Perhaps something like METH_UNPACKED would be an improvement.

I agree METH_ARGS is a poor name.  UNPACKED is fine with me.
If I don't hear a better suggestion, I'll go with that.

> > The drawbacks are:
> >  * the defn of the MethodDef (# args) is separate from the function
> defn
> >  * potentially more error prone to write C methods???
> 
> No worse than with METH_O or METH_NOARGS.

I agree, plus the signature changes if METH_KEYWORDS is used.
I was interested if others viewed the change as better, worse,
or about the same.  I agree with /F that it could be a disaster
if it really is more error prone.  I don't view the change as
much different.  Do others view this as a real problem? 

> If speed is the main advantage being sought, it would be worthwhile to
> conduct more extensive timing tests with a variety of code and not using
> a debug build.  Running test.test_decimal would be a useful overall
> benchmark.

I was hoping others might try it out and see.  I don't have access
to Windows, Mac, or other arches.  I only have x86 and amd64.
It would also be interesting to test this on some real world code.

I have tried various builtin functions and methods and the gain
seems to be consistent across all of them.  I tried things like
dict.get, pow, isinstance.  Since the overhead is fairly constant,
I would expect functions with more arguments to have an even
better improvement.

> 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.  I
> suspect there is no savings here and that the timings will get worse.

I think tested a method I changed from METH_O to METH_ARGS and could
not measure a difference.  A beneift would be to consolidate METH_O,
METH_NOARGS, and METH_VARARGS into a single case.  This should
make code simpler all around (IMO).

> In all likelihood, the only real opportunity for savings is replacing
> METH_VARARGS in cases that have already been sped-up using
> PyTuple_Unpack().  Those can be further improved by eliminating the time
> to build and unpack the temporary argument tuple.

Which this patch accomplishes.

> Even then, I don't see how to overcome the need to set useful default
> values for optional object arguments.

Take a look at the updated patch (#2).  I still think it's pretty clean and an
overall win.  But I'd really like to know what others think.  I also implemented
most (all?) of METH_O and METH_NOARGS plus many METH_VARARGS, so
benchmarkers can compare a difference with and without the patch.

Neal
___
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] Speed up function calls

[Neal Norwitz]

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 please elaborate? 

I'll try.  Do you really trust me, given my first explanation was so poor? :-)

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().  So when it returns
to call_function(), the stack_pointer is still at the top of the stack.
The while loop pops off the arguments.

If there was a ref leak, this scenario should demonstrate the refs increasing:

>>> isinstance(5, int)
True
[25363 refs]
>>> isinstance(5, int)
True
[25363 refs]
>>> isinstance(5, int)
True
[25363 refs]

The current code is not optimal.  new_fast_function() should take PyObject***
and it should also do the DECREF, but I had some bugs when I tried to get
that working, so I've deferred fixing that.  It ought to be fixed though.

HTH,
Neal
___
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 the Python Memory Allocator

[Evan Jones]

On Jan 24, 2005, at 18:16, Martin v. Löwis wrote:
- please don't post patches here; post them to SF
  You may ask for comments here after you posted them to SF.
Sure. This should be done even for patches which should absolutely not 
be committed?

- please follow Python coding style. In particular, don't write
if ( available_arenas == NULL ) {
  but write
if (available_arenas == NULL) {
Yikes! This is a "bad" habit of mine that is in the minority of coding 
style . Thank you for catching it.

Second, the previous allocator went out of its way to permit a module 
to call PyObject_Free while another thread is executing 
PyObject_Malloc. Apparently, this was a backwards compatibility hack 
for old Python modules which erroneously call these functions without 
holding the GIL. These modules will have to be fixed if this 
implementation is accepted into the core.
I'm not certain it is acceptable to make this assumption. Why is it
not possible to use the same approach that was previously used (i.e.
leak the arenas array)?
This is definitely a very important point of discussion. The main 
problem is that leaking the "arenas" arena is not sufficient to make 
the memory allocator thread safe. Back in October, Tim Peters suggested 
that it might be possible to make the breakage easily detectable:

http://mail.python.org/pipermail/python-dev/2004-October/049502.html
If we changed PyMem_{Free, FREE, Del, DEL} to map to the system
free(), all would be golden (except for broken old code mixing
PyObject_ with PyMem_ calls).  If any such broken code still exists,
that remapping would lead to dramatic failures, easy to reproduce; and
old code broken in the other, infinitely more subtle way (calling
PyMem_{Free, FREE, Del, DEL} when not holding the GIL) would continue
to work fine.
I'll be honest, I only have a theoretical understanding of why this 
support is necessary, or why it is currently correct. For example, is 
it possible to call PyMem_Free from two threads simultaneously? Since 
the problem is that threads could call PyMem_Free without holding the 
GIL, it seems to be that it is possible. Shouldn't it also be 
supported? In the current memory allocator, I believe that situation 
can lead to inconsistent state. For example, see obmalloc.c:746, where 
it has been determined that a block needs to be put on the list of free 
blocks:

*(block **)p = lastfree = pool->freeblock;
pool->freeblock = (block *)p;
Imagine two threads are simultaneously freeing blocks that belong to 
the same pool. They both read the same value for pool->freeblock, and 
assign that same value to p. The changes to pool->freeblock will have 
some arbitrary ordering. The result? You have just leaked a block of 
memory.

Basically, if a concurrent memory allocator is the requirement, then I 
think some other approach is necessary.

- When allocating a page, it is taken from the arena that is the most 
full. This gives arenas that are almost completely unused a chance to 
be freed.
It would be helpful if that was documented in the data structures
somewhere. The fact that the nextarena list is sorted by nfreepools
is only mentioned in the place where this property is preserved;
it should be mentioned in the introductory comments as well.
This is one of those rough edges I mentioned before. If there is some 
concensus that these changes should be accepted, then I will need to 
severely edit the comments at the beginning of obmalloc.c.

Thanks for your feedback,
Evan Jones
___
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] Speed up function calls

["Martin v. Löwis"]

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 is the detail I was missing.
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] PyCon: The Spam Continues ;-)

[Steve Holden]

Dear python-dev:
The current (as of even date) summary of my recent contributions to 
Python -dev appears to be spam about PyCon.

Not being one to break habits, even not those of a lifetime sometimes, I 
spam you yet again to show you what a beautiful summary ActiveState have 
provided (I don't know whether this URL is cacheable or not):


If I remember Trent Lott (?) described at an IPC the SQL Server database 
that drives this system, and it was a great example of open source 
technology driving a proprietary (but I expect (?) relatively portable) 
repository.

Since I have your attention (and if I haven't then it really doesn't 
matter what I write hereafter, goodbye ...) I will also point out that 
the current top hit on Google for

"Microsoft to Provide PyCon Opening Keynote"
is
	[Python-Dev] Microsoft to Provide PyCon Opening Keynote
by Steve Holden (you can repeat the search to see whether this assertion 
is true as you read this mail, and read the opening keynote announcement 
[I hope...]).

Space at PyCon is again enlarged, but it certainly isn't infinite. I'd 
love to see it filled in my third and last year as chair. The program 
committee have worked incredibly hard to make sure we all have to choose 
between far more technical content than a single individual can possibly 
take in on their own. They [disclaimer: I was program chair, but this 
should be kudos for the committee membership - without whom this 
conference would have failed in many dimensions] they have succeeded so 
well we all, I hope, have to agonize between two sumptuous but 
equidistant technical bales of hay.

Only by providing such rich choice can we ensure that an even broader 
community forms around Python, with free interchange between the 
technical communities of the proprietary and open source worlds, and 
equitable participation in the benefit.

Sorry I haven't made many CVS contributions lately. We really should be 
showcasing more Python technologies via www.python.org.

targeted-marketing-to-talented-professionals-ly y'rs  - steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
___
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] Re: [PyCON-Organizers] PyCon: The Spam Continues ;-)

[Steve Holden]

Steve Holden wrote:
[some things followed by]
If I remember Trent Lott (?) described at an IPC the SQL Server database 
that drives this system, and it was a great example of open source 
technology driving a proprietary (but I expect (?) relatively portable) 
repository.

Please forgive me for this not-so-talented Transatlantic confusion, 
since I mistook one famous name for another. I did of course mean
Trent Mick at ActiveState.  Apologies for the confusion.

regards
Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
___
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] Re: [PyCON-Organizers] PyCon: The Spam Continues ;-)

[David Ascher]

Steve Holden wrote:
Dear python-dev:
The current (as of even date) summary of my recent contributions to 
Python -dev appears to be spam about PyCon.

Not being one to break habits, even not those of a lifetime sometimes, I 
spam you yet again to show you what a beautiful summary ActiveState have 
provided (I don't know whether this URL is cacheable or not):

 
Yup, we try to make all our URLs portable and persistent.
If I remember Trent Lott (?) 
Nah, that's a US politician.  T'was Trent Mick.
described at an IPC the SQL Server database 
that drives this system, and it was a great example of open source 
technology driving a proprietary (but I expect (?) relatively portable) 
repository.
Modulo some SQLServer features we're using.
Since I have your attention (and if I haven't then it really doesn't 
matter what I write hereafter, goodbye ...) I will also point out that 
the current top hit on Google for

"Microsoft to Provide PyCon Opening Keynote"
What a bizarre search.
(note that some of your To's and Cc's were pretty strange...
--david

___
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] Re: PyCon: The Spam Continues ;-)

[Terry Reedy]

 
Huh?
  I get a mostly blank page.  Perhaps there are no authors by thatname.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] Strange segfault in Python threads and linux kernel 2.6

[Anthony Baxter]

On Thursday 20 January 2005 12:43, Donovan Baarda wrote:
> On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote:
> > The main oddness about python threads (before 2.3) is that they run
> > with all signals masked.  You could play with a C wrapper (call
> > setprocmask, then exec fop) to see if this is what is causing the
> > problem.  But please try 2.4.
>
> Python 2.4 does indeed fix the problem. Unfortunately we are using Zope
> 2.7.4, and I'm a bit wary of attempting to migrate it all from 2.3 to
> 2.4. Is there any wa  this "Fix" can be back-ported to 2.3?

It's extremely unlikely - I couldn't make myself comfortable with it
when attempting to figure out it's backportedness. While the current
behaviour on 2.3.4 is broken in some cases, I fear very much that 
the new behaviour will break other (working) code - and this is 
something I try very hard to avoid in a bugfix release, particularly
in one that's probably the final one of a series.

Fundamentally, the answer is "don't do signals+threads, you will
get burned". For your application, you might want to instead try 
something where you write requests to a file in a spool directory, 
and have a python script that loops looking for requests, and 
generates responses. This is likely to be much simpler to debug 
and work with. 



Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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