[issue1238] dictobject and dictentry not used consistently in dictobject.c

2007-10-05 Thread Anthon van der Neut

New submission from Anthon van der Neut:

In dictobject.c the structures from dictobject.h are typedeffed to:
typedef PyDictEntry dictentry;
typedef PyDictObject dictobject;

However there are still a few locations in that file where the
PyDictEntry and PyDictObject types are used directly. IMHO these should
be replaced by  dictentry resp. dictobject

Attached is a patch for that.

--
components: Interpreter Core
files: dictobject.c.patch
messages: 56234
nosy: anthon
severity: minor
status: open
title: dictobject and dictentry not used consistently in dictobject.c
versions: Python 2.5, Python 2.6

__
Tracker <[EMAIL PROTECTED]>

__--- ../dictobject.c	2007-10-02 16:06:08.0 +0200
+++ ./dictobject.c	2007-10-05 09:19:33.0 +0200
@@ -168,7 +168,7 @@
There are two ways to create a dict:  PyDict_New() is the main C API
function, and the tp_new slot maps to dict_new().  In the latter case we
can save a little time over what PyDict_New does because it's guaranteed
-   that the PyDictObject struct is already zeroed out.
+   that the dictobject struct is already zeroed out.
Everyone except dict_new() should use EMPTY_TO_MINSIZE (unless they have
an excellent reason not to).
 */
@@ -186,7 +186,7 @@
 
 /* Dictionary reuse scheme to save calls to malloc, free, and memset */
 #define MAXFREEDICTS 80
-static PyDictObject *free_dicts[MAXFREEDICTS];
+static dictobject *free_dicts[MAXFREEDICTS];
 static int num_free_dicts = 0;
 
 PyObject *
@@ -397,7 +397,7 @@
 {
 	PyObject *old_value;
 	register dictentry *ep;
-	typedef PyDictEntry *(*lookupfunc)(PyDictObject *, PyObject *, long);
+	typedef dictentry *(*lookupfunc)(dictobject *, PyObject *, long);
 
 	assert(mp->ma_lookup != NULL);
 	ep = mp->ma_lookup(mp, key, hash);
@@ -1338,7 +1338,7 @@
 int
 PyDict_Merge(PyObject *a, PyObject *b, int override)
 {
-	register PyDictObject *mp, *other;
+	register dictobject *mp, *other;
 	register Py_ssize_t i;
 	dictentry *entry;
 
@@ -2066,7 +2066,7 @@
 	assert(type != NULL && type->tp_alloc != NULL);
 	self = type->tp_alloc(type, 0);
 	if (self != NULL) {
-		PyDictObject *d = (PyDictObject *)self;
+		dictobject *d = (dictobject *)self;
 		/* It's guaranteed that tp->alloc zeroed out the struct. */
 		assert(d->ma_table == NULL && d->ma_fill == 0 && d->ma_used == 0);
 		INIT_NONZERO_DICT_SLOTS(d);
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1239] openpty does not give bidirectional pipe

2007-10-05 Thread Matti Katila

Changes by Matti Katila:


--
components: None
severity: normal
status: open
title: openpty does not give bidirectional pipe
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1239] openpty does not give bidirectional pipe

2007-10-05 Thread Matti Katila

New submission from Matti Katila:

http://rafb.net/p/t8cqSt71.html

--
nosy: +mudyc

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1239] openpty does not give bidirectional pipe

2007-10-05 Thread Matti Katila

Matti Katila added the comment:

Linux Programmer’s Manual for ptmx and pts - pseudo-terminal master and
slave states:

"Data written to the slave is presented  on  the  master descriptor  as
input. Data written to the master is presented to the slave as input."

The data can be read from slave to master but not from master to slave.

The unit test does not test this issue either:
http://coverage.livinglogic.de/Lib/test/test_openpty.py.html

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1240] str.split bug

2007-10-05 Thread Tim Gordon

Changes by Tim Gordon:


--
title: str.split possible bug -> str.split bug

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1240] str.split possible bug

2007-10-05 Thread Tim Gordon

New submission from Tim Gordon:

>From the docs for str.split:
"If sep is not specified or is None... First, whitespace characters are 
stripped from both ends. Then, words are separated by arbitrary length 
strings of whitespace characters."

However, ' a b c '.split(None, 1) returns ['a', 'b c '] indicating that 
the "stripped from both ends" isn't taking place, but that it's 
removing whitespace as it goes and never gets to the end as it stops 
parsing when it hits the first split.

Note this is easily worked around by calling str.strip().split(None, 
1), but it would be good not to have to.

I've tested this on windows version 2.5, and 2.4.4 for Debian

--
messages: 56237
nosy: QuantumTim
severity: normal
status: open
title: str.split possible bug
type: behavior
versions: Python 2.4, Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1240] str.split bug when using sep = None and maxsplit

2007-10-05 Thread Tim Gordon

Changes by Tim Gordon:


--
title: str.split bug -> str.split bug when using sep = None and maxsplit

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks

2007-10-05 Thread Guido van Rossum

Guido van Rossum added the comment:

Please submit a patch -- this was mostly intended as demo code, I didn't
expect anyone to use it, let alone on Windows. :-)

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1238] dictobject and dictentry not used consistently in dictobject.c

2007-10-05 Thread Guido van Rossum

Guido van Rossum added the comment:

I think it would be better to get rid of the typedefs and use the public
Py* names everywhere?

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1237] type_new doesn't allocate space for sentinal slot

2007-10-05 Thread Guido van Rossum

Guido van Rossum added the comment:

Can you be more specific as to on which line number the questionable
allocation happens, and which functions are depending on there being one
extra slot?

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1237] type_new doesn't allocate space for sentinal slot

2007-10-05 Thread Adam Olsen

Adam Olsen added the comment:

typeobject.c:1842:type_new
type = (PyTypeObject *)metatype->tp_alloc(metatype, nslots);
nslots may be 0.

typeobject.c:1966:type_new assigns this just-past-the-end address to
tp_members
type->tp_members = PyHeapType_GET_MEMBERS(et);

type_new later calls PyType_Ready, which calls add_members.
typeobject.c:3062:add_members
for (; memb->name != NULL; memb++) {

Interestingly, traverse_slots and clear_slots both use Py_Size rather
than name != NULL (so I was wrong about the extent of the problem.) 
Both seem only to be used for heap types.  add_members is used by both
heap types and static C types, so it needs to handle both behaviours.

One possible (if ugly) solution would be to switch iteration methods
depending on if Py_Size() is 0 or not, making sure type_new sets
tp_members to NULL if Py_Size() is 0.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1240] str.split bug when using sep = None and maxsplit

2007-10-05 Thread Brett Cannon

Brett Cannon added the comment:

I know there is another filed bug on this topic, I just need to find it.

--
nosy: +brett.cannon

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1237] type_new doesn't allocate space for sentinal slot

2007-10-05 Thread Guido van Rossum

Guido van Rossum added the comment:

Are you sure you're not missing the +1 on line 440 in PyType_GenericAlloc()?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1237] type_new doesn't allocate space for sentinal slot

2007-10-05 Thread Adam Olsen

Adam Olsen added the comment:

Ugh, you're right.

I refactored PyType_GenericAlloc out of my fork, which is why I got a crash.

Sorry for wasting your time.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1731717] race condition in subprocess module

2007-10-05 Thread Guido van Rossum

Guido van Rossum added the comment:

See http://bugs.python.org/issue1236 for a good repeatable testcase.

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1236] subprocess is not thread-safe

2007-10-05 Thread Guido van Rossum

Guido van Rossum added the comment:

This is a duplicate of bug# 1731717.

I asked Donovan Baarda, who told me:

"""
Last time I looked this had been fixed, admittedly in a bit of an ugly
way, on the svn head. I offered to do a patch to make it a bit cleaner,
but as it isn't really broken anymore it was a bit of a low priority and
I haven't done it.

This bug seems to have a good repeatable test-case that we can probably
use in the unittests to show that it's now fixed...
"""

--
nosy: +gvanrossum
resolution:  -> duplicate
status: open -> closed
superseder:  -> race condition in subprocess module

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1237] type_new doesn't allocate space for sentinal slot

2007-10-05 Thread Guido van Rossum

Changes by Guido van Rossum:


--
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1241] subprocess.py stdout of childprocess always buffered.

2007-10-05 Thread Jason Kim

New submission from Jason Kim:

Hi. 

I am currently using subprocess.py (2.4.4 and above) to try to have a
portable way of running a sub task in linux and windows.

I ran into a strange problem - a program runs and is "timed out"
but the the subprocess's stdout and stderr are not fully "grabbed"
So I've been trying various ways to force "flush" the stdout and stderr
of the child process so that at least partial results can be saved.

The "problem" app being spawned off is very simple:
--
#include 

int main() {
  int i = 0;
  for (i = 0; i < 1000; ++i) {
printf("STDOUT boo %d\n",i);
fprintf(stdout,"STDOUT sleeping %d\n",i);
fprintf(stderr,"STDERR sleeping %d\n",i);
//fflush(stdout);
//fflush(stderr);
sleep(1);
  } 
}

---

i.e. it just dumps its output to both stdout and stderr. The issue that
I am seeing is that no matter what options I tried to place for
subprocess(), the ONLY output I see from the executed process are

"STDERR sleeping " lines, UNLESS I uncomment the fflush(stdout) line in
the application.

Executing the script with python -u doesn't seem to help either.
Now, if the task completes normally, then I am able to grab the entire
stdout and stderr produced by the subprocess. The issue is that I can't
seem to grab the partial output for stdout, and there does not seem to
be a way to make the file descriptors returned by pipe() to be unbuffered.

So the question is: what is the preferred method of forcing the pipe()
file descriptors created by subprocess.__init__() to be fully unbuffered?

Second, is there a better way of doing this?
i.e. a portable way to spawn off a task, with an optional timeout, grab
any partial results from the task's stdout and stderr, and grab the
return code from the child task?

Any hints and advice will be greatly appreciated.

Thank you.

The relevant snippet of python code is:

import threading
from signal import *
from subprocess import *
import time
import string
import copy
import re
import sys
import os
from glob import glob
from os import path
import thread

class task_wrapper():
   def run(s):
  if s.timeout > 0:
#print "starting timer for ",s.timeout
s.task_timer = threading.Timer(s.timeout, task_wrapper.cleanup, [s])
s.task_timer.start()
  s.task_start_time = time.time()
  s.task_end_time = s.task_start_time
  s.subtask=Popen(s.cmd, bufsize=0, env=s.env, stdout=PIPE, stderr=PIPE)
  s.task_out, s.task_err = s.subtask.communicate()


  def kill(s, subtask):
""" attempts a portable way to kill things
First, flush the buffer
"""
print "killing", subtask.pid
sys.stdout.flush()
#s.subtask.stdin.flush()
print "s.subtask.stdout.fileno()=",s.subtask.stdout.fileno()
print "s.subtask.stderr.fileno()=",s.subtask.stderr.fileno()
#os.fsync(s.subtask.stderr.fileno())
#os.fsync(s.subtask.stdout.fileno())
s.subtask.stdout.flush()
s.subtask.stderr.flush()

if os.name == "posix":
  os.kill(subtask.pid, SIGKILL)
elif os.name == "nt":
  import win32api
  win32api.TerminateProcess(subtask._handle ,9)

  def cleanup(s, mode="TIMEOUT"):
s.timer_lock.acquire()
if s.task_result == None:
if mode == "TIMEOUT":
   s.msg( """ Uhoh, subtask took too long""")
   s.kill(s.subtask) 
   

--
messages: 56247
nosy: jason.w.kim
severity: normal
status: open
title: subprocess.py stdout of childprocess always buffered.
type: behavior
versions: Python 2.4, Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1239] openpty does not give bidirectional pipe

2007-10-05 Thread Matti Katila

Matti Katila added the comment:

Not a real issue - it's a standard behaviour of tty.

Fix is to set -icanon:

m,s = os.openpty()
s = os.ttyname(s)
os.system( 'stty cs8 -icanon -echo < %s' % s )

see, http://www.eulogika.net/download/eutalk_20040302/pymouse.html

The issue can be closed and documentation can be updated with some
helpful information.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1242] test

2007-10-05 Thread Gopinath

New submission from Gopinath:

hi

I have registerd recently
and need notes on hacking disadvantages and advantages.

--
files: unnamed
messages: 56249
nosy: gopiyadav26
severity: normal
status: open
title: test

__
Tracker <[EMAIL PROTECTED]>

__hi
 
I have registerd recently 
and need notes on hacking disadvantages and advantages.
 

___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1238] dictobject and dictentry not used consistently in dictobject.c

2007-10-05 Thread Anthon van der Neut

Anthon van der Neut added the comment:

Guido's suggestion to change all entries to PyDictEntry resp.
PyDictObject would work as well and declutter the code in a better way.

The only advantage of the typedefs that I see (and briefly used) it that
it is easy to have structures local to dictobject.c that hold some more
information, without having to touch dictobject.h (and trigger a more
general recompile. For the few that need that, they can globaly replace
PyDict{Entry,Object} when they do.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com