[Python-Dev] segfault when using PyGILState_Ensure/Release in Python2.3.4

2006-07-21 Thread Travis E. Oliphant 

I'm hoping somebody here can help me with an error I'm getting in Python 
  2.3.4 but not in Python 2.4.2 when I use PyGILState_Ensure in NumPy on 
Linux.

Perhaps somebody can point out what I'm doing wrong because while I've 
tried to understand the threading API it can be a bit confusing and 
maybe I'm doing it wrong.

Right now, I've had to disable threading support in NumPy for Python 2.3 
which is a bit annoying.

The problem shows up when I've released the GIL using 
PyEval_SaveThread() in one section of code.  Then the code calls 
functions that don't involve the Python C-API.

Then another function sometimes requires use of the C-API to set a 
Python Error or issue a warning.   So I call:

_save = PyGILState_Ensure();



Finally, before exiting this function

PyGILState_Release(_save);

is called.   Later when control returns to the original caller that 
released the GIL, PyEval_RestoreThread() is called.  But the segfault 
seems to be happening on the call to PyGILState_Release(_save);

All of this works fine when it runs under Python 2.4.2, but under Python 
2.3.4 I get a segfault.

Does anybody have any ideas?   Thanks very much.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new security doc using object-capabilities

2006-07-21 Thread Nick Coghlan 
Brett Cannon wrote:
> Extensible file type handling
> -
> If the file type handlers are stored in normal Python data
> structures as
> described above, it becomes feasible to make the import system
> extensible to
> different file types as well as to different file locations.
> 
> 
> Yep.  Although I am more interested in restricting than broadening the 
> file types.

Either way you'd be mutating the list of recognised file types :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FW: Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32

2006-07-21 Thread Nick Coghlan 
Delaney, Timothy (Tim) wrote:
> Looks like there's a bug in Popen.__del__ in 2.5. I'm not in a position
> to have a look right now.

For those not watching python-checkins, a check for "is not None" has been 
added before the offending line in Popen.__del__. (by Georg, IIRC)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Strategy for converting the decimal module to C

2006-07-21 Thread Nick Maclaren 
Greg Ewing <[EMAIL PROTECTED]> wrote:
> 
> > Now, interrupting into that level has to be transparent, in order to
> > support TLB misses, clock interrupts, device interrupts, machine-check
> > interrupts and so on.
> 
> I thought we were just talking about counting the number
> of floating point exceptions that a particular piece of
> code generates. Surely that's deterministic, and isn't

Er, no.  Rather fundamentally, on two grounds.  Please bear with me, as
this IS relevant to Python.  See the summary at the end if you like :-)

The first is that such things are NOT deterministic, not even on simple
CPUs - take a look at the Alpha architecture for an example, and then
follow it up with the IA64 one if you have the stomach for it.  But
that wasn't my main point.

It is that modern CPUs have a SINGLE interrupt mechanism (a mistake in
itself, but they do), so a CPU may be interrupted when it is running
a device driver, other kernel thread or within a system call as much as
when running an application.  In fact, to some extent, interrupt handlers
can themselves be interrupted (let's skip the details).

Now, in order to allow the application to run its handler, the state
has to be saved, sanitised and converted back to application context;
and conversely on return.  That is hairy, and is why it is not possible
to handle interrupts generated within system calls on many systems.
But that is not directly Python's problem.

What is, is that the code gets interrupted at an unpredictable place,
and the registers and other state may not be consistent as the language
run-time system and Python are concerned.  It is critical (a) that a sane
state is restored before calling the handler and (b) that calling the
handler neither relies on nor disturbs any of the "in flight" actions
in the interrupted code.

To cut a long story short, it is impractical for a language run-time
system to call user-defined handlers with any degree of reliability
unless the compiled code and run-time interoperate carefully - I have
been there and done that many times, but few people still working have.
On architectures with out-of-order execution (and interrupts), you
have to assume that an interrupt may occur anywhere, even when the
code does not use the relevant facility.  Floating-point overflow
in the middle of a list insertion?  That's to be expected.

It becomes considerably easier if the (run-time system) interrupt
handler merely needs to flag or count interrupts, as it can use a
minimal handler which is defensive and non-intrusive.  Even that is
a pretty fair nightmare, as many systems temporarily corrupt critical
registers when they think that it is safe.  And few think of interrupts
when deciding that 

So, in summary, please DON'T produce a design that relies on trapping
floating-point exceptions and passing control to a Python function.
This is several times harder than implementing fpectl.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761Fax:  +44 1223 334679
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Document performance requirements?

2006-07-21 Thread Neal Becker 
For a recent project I needed to select a container.  There are plenty of
python data structures to choose from.  It seems that information on
performance is missing (or not easy to find).

I think Python should include performance in the documentation of common
data structures to help users select the appropriate types.  Something in
the style of c++ STL.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Ireland PyPy sprint 21th-27th August 2006

2006-07-21 Thread Michael Hudson 
The next PyPy sprint will happen in the nice city of 
Limerick in Ireland from 21st till 27th August.  
(Most people intend to arrive 20th August). 

The main focus of the sprint will be on JIT compiler works, 
various optimization works, porting extension modules, 
infrastructure works like a build tool for PyPy, or 
extended (distributed) testing. 

It's also open to new topics.  If you are a student
consider to participate in `Summer of PyPy`_ in order 
get funding for your travels and accomodation. 

The sprint is being hosted by University of Limerick
(http://www.ul.ie/) - and is arranged in co-operation
with people from our sister project Calibre (www.calibre.ie).
Our contact at the University is Pär Ågerfalk and Eoin
Oconchuir. 

.. _`Summer of PyPy`: http://codespeak.net/pypy/dist/pypy/doc/summer-of-pypy

First day: introduction and workshop (possible to attend only this day)


During the first day (21st of August) there will be talks on various subjects
related to PyPy:

* A tutorial and technical introduction to the PyPy codebase  
  (suited for people interested in getting an overview of PyPy´s architecture
  and/or contributing to PyPy)

* a workshop covering more in-depth technical aspects of PyPy and what PyPy
  can do for you. The workshop will also cover methodology, aiming at explaining
  the pros and cons of sprint-driven development.
  (suited for sprint attendants, students, staff and other 
  interested parties from/around the University and the local area)

The tutorial will be part of the sprint introduction - the workshop will take 
place if 
there is enough interest raised before the 21st of August from people planning 
to 
attend. You are of course welcome to attend just for this first day of the 
sprint.


If you want to come ...


If you'd like to come, please subscribe to the `pypy-sprint mailing list`_
and drop a note about your interests and post any questions.  More 
organisational information will be send to that list.  We'll keep
a list of `people`_ which we'll update (which you can do so yourself
if you have codespeak commit rights). 

.. _`Calibre`: http://www.calibre.ie 

A small disclaimer:
There might be people visiting the sprint in order to do research on 
how open source communities work, organize and communicate. This 
research might be done via filming, observing or interviewing. 
But of course you will be able to opt-out of being filmed at the sprint. 

Logistics 
--

NOTE: you need a UK style of power adapter (220V). 

The sprint will be held in the Computer Science Building, room CSG-025, 
University of Limerick (no 7 on http://www.ul.ie/main/places/campus.shtml). 

Bus 308 from Limerick city will take you to no 30 (approx.).
See http://www.ul.ie/main/places/travel.shtml for more on how to get to UL.

We will have access to the sprint facilities from 09:00-19:00 every day (it 
might
be even later than 19:00). Monday-Wednesday, Friday-Sunday are sprint days,
Thursday is likely a break day.

Food on campus varies in price and quality ;-) : from ca 4 EUR to 7-8 EUR for 
a lunch. There are of course a lot more food alternatives in down town Limerick.

Next Airports
--

Shannon Airport (SNN) is the nearest airport (Ryanair flies
there) - you may check out more information about flights
to/from the airport at

http://www.shannonairport.com/index.html 

There are busses from there to downtown Limerick, and busses
from Limerick to the UL campus. Taxis are about 35 EUR.

Accomodation
-

There is a website address for campus accomodation at 

http://www.ul.ie/conference/accommodation.htm.  

The rate should be 49 euro for Bed and Breakfast.  If you are interested 
in booking campus accommodation, please contact deborah.tudge at ul ie
and make reference to the PyPy workshop and sprint.  Please try 
to book as soon as possible. 

As an off-campus accommodation alternative you can also try:

Castletroy Lodge and Castletroy Inn (Bed and Breakfast)
Dublin Road (15 to 20 mins walk to UL)
Tel: +353 61 338385 / +353 61 331167

.. _`pypy-sprint mailing list`: 
http://codespeak.net/mailman/listinfo/pypy-sprint
.. _`people`: people.html 

-- 
  surely, somewhere, somehow, in the history of computing, at least
  one manual has been written that you could at least remotely
  attempt to consider possibly glancing at.  -- Adam Rixey
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document performance requirements?

2006-07-21 Thread Nick Coghlan 
Neal Becker wrote:
> For a recent project I needed to select a container.  There are plenty of
> python data structures to choose from.  It seems that information on
> performance is missing (or not easy to find).
> 
> I think Python should include performance in the documentation of common
> data structures to help users select the appropriate types.  Something in
> the style of c++ STL.

Do you mean absolute performance, or do you mean algorithmic order guarantees? 
I thought the latter were already documented. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support for PyGetSetDefs in pydoc

2006-07-21 Thread Nick Coghlan 
Georg Brandl wrote:
> Perhaps you could put the objects into _testcapi. That way no new module
> has to be deployed (is _testcapi installed on every system?)

Let's not corrupt _testcapi with something that has an entirely differently 
purpose.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document performance requirements?

2006-07-21 Thread Neal Becker 
Nick Coghlan wrote:

> Neal Becker wrote:
>> For a recent project I needed to select a container.  There are plenty of
>> python data structures to choose from.  It seems that information on
>> performance is missing (or not easy to find).
>> 
>> I think Python should include performance in the documentation of common
>> data structures to help users select the appropriate types.  Something in
>> the style of c++ STL.
> 
> Do you mean absolute performance, or do you mean algorithmic order
> guarantees? I thought the latter were already documented. . .
> 

The latter.  Where is it documented?

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document performance requirements?

2006-07-21 Thread Nick Coghlan 
Neal Becker wrote:
> On Friday 21 July 2006 7:49 am, Nick Coghlan wrote:
>> Neal Becker wrote:
>>> For a recent project I needed to select a container.  There are plenty of
>>> python data structures to choose from.  It seems that information on
>>> performance is missing (or not easy to find).
>>>
>>> I think Python should include performance in the documentation of common
>>> data structures to help users select the appropriate types.  Something in
>>> the style of c++ STL.
>> Do you mean absolute performance, or do you mean algorithmic order
>> guarantees? I thought the latter were already documented. . .
>>
> 
> The latter.  Where are they documented?

Just because I think something, it doesn't mean it's true :)

The only reference I can actually find is the one in the collections module 
docs pointing out that collections.deque permits O(1) insertions and removals 
at the beginning of the sequence, as well as at the end (whereas lists are 
O(n) for operations at the beginning due to the resulting memory copying).

However, I'm also struggling to think of a case other than list vs deque where 
the choice of a builtin or standard library data structure would be dictated 
by big-O() concerns.

list vs array.array is based on memory efficiency
list vs deque is based on whether or not you need O(1) push/pop at both ends
list vs set is based on whether or not ordering matters
set vs dict is based on whether or not you need to map keys to values

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Document performance requirements?

2006-07-21 Thread Jason Orendorff 
On 7/21/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> However, I'm also struggling to think of a case other than list vs deque where
> the choice of a builtin or standard library data structure would be dictated
> by big-O() concerns.

OK, but that doesn't mean the information is unimportant.  +1 on
making this something of a priority.  People looking for this info
should find it in the obvious place.  Some are unobvious. (How fast is
dict.__eq__ on average? Worst case?)

-j
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

2006-07-21 Thread Brett Cannon 
On 7/20/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
On Friday 21 July 2006 00:10, Neil Hodgson wrote: > Brett Cannon: > > But SourceForge does not support anonymous reporting. > >SourceForge does support anonymous reporting. A large proportion of
 > the fault reports I receive for Scintilla are anonymous as indicated > by "nobody" in the "Submitted By" column.SourceForge supports anonymous reporting, but the Python project determined
that the management cost of anonymous reports was higher than the value theyprovided.OK.  Wording  has been changed in my copy. 
It might be time to reconsider that decision (though my position hasn'tchanged).Sure.  It can also wait until we begin discussing the transition to our next bug tracker.-Brett 

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Strategy for converting the decimal module to C

2006-07-21 Thread James Y Knight 

On Jul 21, 2006, at 6:18 AM, Nick Maclaren wrote:
> To cut a long story short, it is impractical for a language run-time
> system to call user-defined handlers with any degree of reliability
> unless the compiled code and run-time interoperate carefully - I have
> been there and done that many times, but few people still working  
> have.
> On architectures with out-of-order execution (and interrupts), you
> have to assume that an interrupt may occur anywhere, even when the
> code does not use the relevant facility.  Floating-point overflow
> in the middle of a list insertion?  That's to be expected.

While this _is_ a real problem, is it _not_ a general problem as you  
are describing it. Processors are perfectly capable of generating  
precise interrupts, and the inability to do so has nothing to do with  
the out-of-order execution, etc. Almost all interrupts are precise.  
The only interesting one which is not, on x86 processors, is the x87  
floating point exception, which is basically for historical reasons.  
It has never been precise, ever since the actual 8087 coprocessor  
chip for the 8086. However, all is not lost: the exception cannot  
occur randomly. It can only occur on *some* floating point  
instruction, even if the instruction is not the one the error  
actually occurred in. So, unless your list insertion code uses  
floating point instructions, you should not get a floating point  
exception during your list insertion.

Also, looking forward, the "simd" floating point instructions (ie mmx/ 
sse/sse2/sse3) _do_ generate precise interrupts. And on x86-64, x87  
instructions are deprecated and everyone is recommended to use the  
simd ones, instead (so, for example, gcc defaults to using them).

James
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FW: Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32

2006-07-21 Thread Kevin Jacobs <[EMAIL PROTECTED]> 
On 7/21/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Delaney, Timothy (Tim) wrote:> Looks like there's a bug in Popen.__del__ in 2.5. I'm not in a position> to have a look right now.For those not watching python-checkins, a check for "is not None" has been
added before the offending line in Popen.__del__. (by Georg, IIRC)Many thanks for accepting my patch.  There remains a potentially related problem in popen2.py, but it may be a lower priority, since most folks should be using subprocess.
    def __del__(self):    # In case the child hasn't been waited on, check if it's done.    self.poll(_deadstate=sys.maxint)    if self.sts < 0:    if _active:    # Child is still running, keep us alive until we can wait on it.
    _active.append(self)The is _active check, unless it intendeds to check for either empty or None, should probably be revised to:    def __del__(self):    # In case the child hasn't been waited on, check if it's done.
    self.poll(_deadstate=sys.maxint)    if self.sts < 0:    if _active is None:    # Child is still running, keep us alive until we can wait on it.    _active.append(self)
However, there may be a clever reason for doing what is doing that I do not see.Thanks again,-Kevin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document performance requirements?

2006-07-21 Thread Giovanni Bajo 
Jason Orendorff wrote:

>> However, I'm also struggling to think of a case other than list vs
>> deque where the choice of a builtin or standard library data
>> structure would be dictated by big-O() concerns.
>
> OK, but that doesn't mean the information is unimportant.  +1 on
> making this something of a priority.  People looking for this info
> should find it in the obvious place.  Some are unobvious. (How fast is
> dict.__eq__ on average? Worst case?)

I also found out that most people tend to think of Python's lists as a
magical data structure optimized for many operations (like a "rope" or
something complex like that). Documenting that it's just a bare vector
(std::vector in C++) would be of great help.
-- 
Giovanni Bajo

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Community buildbots -- reprise

2006-07-21 Thread Grig Gheorghiu 
Hi,This message is in response to Glyph's plea(
).Here's what Glyph said:"I would like to propose, although I certainly don't have time toimplement, a program by which Python-using projects could contributebuildslaves which would run their projects' tests with the latest
Python trunk.  This would provide two useful incentives: Python codewould gain a reputation as generally well-tested (since there is adirect incentive to write tests for your project: get notified whencore python changes might break it), and the core developers would have
instant feedback when a "small" change breaks more code than it wasexpected to."I'm volunteering to organize this effort, is there is enough intereston this list. In fact, I've done some prep work already:
 * got a domain name: pybots.org * got a $47/month Ubuntu-based VPS from JohnCompanies.com (root accessand everything); it's available at 
master.pybots.org, and it's ready tobe configured as a buildmaster for the pybots * got a mailing list: 
[EMAIL PROTECTED]I can start configuring the Ubuntu machine as a buildmaster, and I canalso add a buildslave on the same machine that will check out thelatest Python trunk code, build it, then run the automated tests for a
sample project -- let's say for Twisted, since Glyph was the onerequesting this. This will also serve as a sample buildslave for otherpeople who will be interested in running buildslaves for their ownprojects.
Apart from the goals stated by Glyph, I see this as a very valuableeffort in convincing people of the value of automated tests,Python-related or not. A secondary effect I'd like to see would be forthese suites of tests to be invoked in a standard fashion -- maybe
'python setup.py test'.If PSF can contribute some $$$ towards the hosting of the masterserver, that would be appreciated, but not required. All that'srequired is enough interest from the community.
Please let me know if you're interested.Grig-- 
http://agiletesting.blogspot.com

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

2006-07-21 Thread skip 

Brett> Sure.  It can also wait until we begin discussing the transition
Brett> to our next bug tracker.

Would be kinda nice if the new bug tracker allowed submitters to enter a
followup email address without formally logging in.  (Of course, email-based
submissions would go a long way to minimizing the problem.)

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-21 Thread Jean-Paul Calderone 
On Fri, 21 Jul 2006 10:04:38 -0700, Grig Gheorghiu <[EMAIL PROTECTED]> wrote:
>Hi,
>
>Apart from the goals stated by Glyph, I see this as a very valuable
>effort in convincing people of the value of automated tests,
>Python-related or not. A secondary effect I'd like to see would be for
>these suites of tests to be invoked in a standard fashion -- maybe
>'python setup.py test'.
>
>If PSF can contribute some $$$ towards the hosting of the master
>server, that would be appreciated, but not required. All that's
>required is enough interest from the community.
>
>Please let me know if you're interested.
>

This is certainly interesting to me.  If you need any help setting up
the Twisted buildslave, please let me know.

Jean-Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FW: Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32

2006-07-21 Thread Georg Brandl 
Kevin Jacobs <[EMAIL PROTECTED]> wrote:
> On 7/21/06, *Nick Coghlan* <[EMAIL PROTECTED] 
> > wrote:
> 
> Delaney, Timothy (Tim) wrote:
>  > Looks like there's a bug in Popen.__del__ in 2.5. I'm not in a
> position
>  > to have a look right now.
> 
> For those not watching python-checkins, a check for "is not None"
> has been
> added before the offending line in Popen.__del__. (by Georg, IIRC)
> 
> 
> Many thanks for accepting my patch.  There remains a potentially related 
> problem in popen2.py, but it may be a lower priority, since most folks 
> should be using subprocess.
> 
> def __del__(self):
> # In case the child hasn't been waited on, check if it's done.
> self.poll(_deadstate=sys.maxint)
> if self.sts < 0:
> if _active:
> # Child is still running, keep us alive until we can 
> wait on it.
> _active.append(self)
> 
> 
> The is _active check, unless it intendeds to check for either empty or 
> None, should probably be revised to:
> 
> def __del__(self):
> # In case the child hasn't been waited on, check if it's done.
> self.poll(_deadstate=sys.maxint)
> if self.sts < 0:
> if _active is None:
> # Child is still running, keep us alive until we can 
> wait on it.
> _active.append(self)
> 
> However, there may be a clever reason for doing what is doing that I do 
> not see.

There's no reason (I know since I added the check myself ;). Thanks
for pointing out that obvious bug. (fixed in rev 50759).

Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FW: Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32

2006-07-21 Thread John Benediktsson 

> The is _active check, unless it intendeds to check for either empty or

> None, should probably be revised to:
> 
> def __del__(self):
> # In case the child hasn't been waited on, check if it's done.
> self.poll(_deadstate=sys.maxint)
> if self.sts < 0:
> if _active is None:
> # Child is still running, keep us alive until we can 
> wait on it.
> _active.append(self)
> 

It probably is obvious, but I think you mean:

if _active is not None:
...

Thanks,
John.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document performance requirements?

2006-07-21 Thread James Y Knight 
On Jul 21, 2006, at 12:45 PM, Giovanni Bajo wrote:
> Jason Orendorff wrote:
>
>>> However, I'm also struggling to think of a case other than list vs
>>> deque where the choice of a builtin or standard library data
>>> structure would be dictated by big-O() concerns.
>>
>> OK, but that doesn't mean the information is unimportant.  +1 on
>> making this something of a priority.  People looking for this info
>> should find it in the obvious place.  Some are unobvious. (How  
>> fast is
>> dict.__eq__ on average? Worst case?)
>
> I also found out that most people tend to think of Python's lists as a
> magical data structure optimized for many operations (like a "rope" or
> something complex like that). Documenting that it's just a bare vector
> (std::vector in C++) would be of great help.

Indeed, I was talking to someone a while back who thought that lists  
were magically hashed, in that he did something like:
dictionary = open("/usr/share/dict/words").readlines()

and then expected:
"word" in dictionary

would be fast. And was very surprised when it turned out to be slow a  
linear search of the list. :)

James

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-21 Thread Neal Norwitz 
I have a server up and running.  I still need to polish some stuff
off.  I will mail more info when I get a chance.

n
--

On 7/21/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Jul 2006 10:04:38 -0700, Grig Gheorghiu <[EMAIL PROTECTED]> wrote:
> >Hi,
> >
> >Apart from the goals stated by Glyph, I see this as a very valuable
> >effort in convincing people of the value of automated tests,
> >Python-related or not. A secondary effect I'd like to see would be for
> >these suites of tests to be invoked in a standard fashion -- maybe
> >'python setup.py test'.
> >
> >If PSF can contribute some $$$ towards the hosting of the master
> >server, that would be appreciated, but not required. All that's
> >required is enough interest from the community.
> >
> >Please let me know if you're interested.
> >
>
> This is certainly interesting to me.  If you need any help setting up
> the Twisted buildslave, please let me know.
>
> Jean-Paul
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FW: Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32

2006-07-21 Thread Kevin Jacobs <[EMAIL PROTECTED]> 
That'll teach me to fire off emails while running out the door.   Thanks.-KevinOn 7/21/06, John Benediktsson <
[EMAIL PROTECTED]> wrote:> The is _active check, unless it intendeds to check for either empty or
> None, should probably be revised to:>> def __del__(self):> # In case the child hasn't been waited on, check if it's done.> self.poll(_deadstate=sys.maxint)> if 
self.sts < 0:> if _active is None:> # Child is still running, keep us alive until we can> wait on it.> _active.append(self)>It probably is obvious, but I think you mean:
if _active is not None:...Thanks,John.___Python-Dev mailing [email protected]
http://mail.python.org/mailman/listinfo/python-devUnsubscribe: http://mail.python.org/mailman/options/python-dev/jacobs%40bioinformed.com

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

2006-07-21 Thread Kevin Jacobs <[EMAIL PROTECTED]> 
On 7/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Brett> Sure.  It can also wait until we begin discussing the transitionBrett> to our next bug tracker.Would be kinda nice if the new bug tracker allowed submitters to enter afollowup email address without formally logging in.  (Of course, email-based
submissions would go a long way to minimizing the problem.)It may just be bad karma, but SourceForge tends to lock or go off into lala land whenever I log in.  Thus, I would file many bug reports, with a reply-to address, if non-login bug submissions where allowed.  My long term hope is that you toss out SF and get something better.
Thanks,-Kevin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document performance requirements?

2006-07-21 Thread Nick Coghlan 
Jason Orendorff wrote:
> On 7/21/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> However, I'm also struggling to think of a case other than list vs 
>> deque where
>> the choice of a builtin or standard library data structure would be 
>> dictated
>> by big-O() concerns.
> 
> OK, but that doesn't mean the information is unimportant.  +1 on
> making this something of a priority.  People looking for this info
> should find it in the obvious place.  Some are unobvious. (How fast is
> dict.__eq__ on average? Worst case?)

Agreed, but there's more to doing that than just writing down the O() implied 
by the current CPython implementation - it's up to Guido to decide which of 
the constraints are part of the language definition, and which are 
implementation accidents (e.g. CPython's list.sort() operation was stable for 
at least one release before GvR made stability part of the definition of the 
method at the language level).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

2006-07-21 Thread Nick Coghlan 
Kevin Jacobs <[EMAIL PROTECTED]> wrote:
> It may just be bad karma, but SourceForge tends to lock or go off into 
> lala land whenever I log in.  Thus, I would file many bug reports, with 
> a reply-to address, if non-login bug submissions where allowed.   My long
> term hope is that you toss out SF and get something better.

You're not the only one with that hope. With at least Trac, Jira and Roundup 
to choose from, the PSF's current tracker shootout should find us that 
replacement :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com