[issue1631171] implement warnings module in C

[Brett Cannon]

Brett Cannon added the comment:

I see two ways of implementing the fetching of a source code line from
__loader__.get_source().

One is to do it in Python.  We have a function provided that can
suppress the second line of output from a warning and just handle it in
Python code.  That has the requirement that Python code be available to
import, but if you are using Lib/warnings.py instead of
Python/_warnings.c that is pretty much guaranteed.

The other option is to rely on the fact that get_source() is supposed to
use universal newlines.  Then we can find the index of the x and x-1
newlines and print the substring between the two.  That can be done in C
code by checking for the loader, checking for get_source(), calling it,
getting the char buffer, and then just looping through looking for the
needed newlines to find the needed indexes.  Otherwise we can use the
Python API on strings to do what would have been done in pure Python,
but that is a lot of PyObject_Call() usage and seems overly inefficient
if one bothers with coding it in C.  =)

_
Tracker <[EMAIL PROTECTED]>

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

[issue1774369] Unify __builtins__ -> __builtin__

[Georg Brandl]

Changes by Georg Brandl:


--
superseder:  -> Rename __builtins__ to __root_namespace__?

_
Tracker <[EMAIL PROTECTED]>

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

[issue1705362] cannot change cursor color in IDLE

[Georg Brandl]

Changes by Georg Brandl:


--
resolution:  -> fixed
status: open -> closed
superseder:  -> IDLE - cursor color configuration bug

_
Tracker <[EMAIL PROTECTED]>

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

[issue1269] Exception in pstats print_callers()

[Georg Brandl]

Changes by Georg Brandl:


--
assignee:  -> georg.brandl
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue1524] os.system() fails for commands with multiple quoted file names

[Guy Mott]

Guy Mott added the comment:

> Are you sure that the exact command line works in a Windows shell?

Yes, I tried running the exact same command line in a Windows shell and 
it worked fine. Note that the buggy.py script echoes the command line 
and then immediately calls os.system with it. E.g.:

   print "strCmdLine=[%s]" % strCmdLine
   nRtn = os.system(strCmdLine)

I tried running the script in a shell window, watched it fail, then 
immediately cut and pasted the command line that had been echoed out by 
the script to the command line prompt in the same shell, ran it and it 
succeeded.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Committed revision 59231 in trunk.

--
resolution:  -> fixed
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

[issue1518] Fast globals/builtins access (patch)

[Neil Toronto]

Neil Toronto added the comment:

Christian: Thanks for that, I'll have to remember DEBUG_LEAK in the
future. :)

It looks like it may be acting correctly since there *is* now a
fastglobals object that needs collecting, and also a new tuple built
from co_names + "__builtins__". I don't know why it wouldn't collect
those in the shell, though. The shell does create a new stack frame for
every command (where a function's commands are all run in a single stack
frame), but I don't know why that would matter. I'll look further into it.

Chris: The build problems should be fixed in the next patch. Thanks for
spending so much time on benchmarking this.

Regarding PyEval_EvalCode creating a PyFastGlobalsObject: I'm not sure
whether it's right thing to do, but I think it is. PyEval_EvalCode gets
called for eval, exec, running an imported module's code, and everything
in the interactive prompt - basically, running any code that's not in a
function or generator. (I think that covers everything.) It seems like
the patch has PyEval_EvalCode doing the right thing in general, but it
may suffer a bit in benchmarks.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1443504] locale.getpreferredencoding() dies when setlocale fails

[Heikki Toivonen]

Heikki Toivonen added the comment:

We noticed this too in Chandler. We worked around this issue with the
patch I am attaching. Maybe not a correct fix, though.

--
nosy: +heikki
versions: +Python 2.5
Added file: http://bugs.python.org/file8833/patches-2.5.1-Linux

_
Tracker <[EMAIL PROTECTED]>

_

patches-2.5.1-Linux
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1524] os.system() fails for commands with multiple quoted file names

[Georg Brandl]

Georg Brandl added the comment:

Are you sure that the exact command line works in a Windows shell?

Python does no processing on the string, it just hands it to the
platform system() function, so if MS decided that to work different from
a command prompt there's nothing we can do about.

--
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue1521] string.decode() fails on long strings

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Here is a patch, with a unit test (I was surprised that test_bigmem.py
already contained a test_decode function, which was left empty).

But I still don't have access to any 64bit machine.
Can someone try and see if the new tests in test_bigmem.py fail, and
that the patch in getargs.c corrects the problem?

Added file: http://bugs.python.org/file8832/getargs.patch

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1522] pyvm module patch

[Christian Heimes]

Christian Heimes added the comment:

Guido van Rossum wrote:
> Sure, go ahead and submit the uncontroversial part.

Applied py3k_add_types_to_h.patch in r59229

__
Tracker <[EMAIL PROTECTED]>

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

[issue1524] os.system() fails for commands with multiple quoted file names

[Christian Heimes]

Christian Heimes added the comment:

I don't think that we can do anything about your problem. The user of
os.system() is responsible to do the quoting himself. os.system() is
just a tiny wrapper around the low level C function. We don't plan to
chance the fact that os.system() doesn't handling quoting.

However the subprocess module is clever enough to do the quoting for you.

--
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Guido van Rossum]

Guido van Rossum added the comment:

> I like to apply the py3k_add_types_to_h.patch before the next alpha and
> discuss the fate of pyvm after the alpha.

Sure, go ahead and submit the uncontroversial part.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1518] Fast globals/builtins access (patch)

[Guido van Rossum]

Changes by Guido van Rossum:


--
keywords: +patch
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Christian Heimes]

Changes by Christian Heimes:


Removed file: http://bugs.python.org/file8829/py3k_pyvm2.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Christian Heimes]

Changes by Christian Heimes:


Removed file: http://bugs.python.org/file8824/py3k_pyvm.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Christian Heimes]

Christian Heimes added the comment:

I like to apply the py3k_add_types_to_h.patch before the next alpha and
discuss the fate of pyvm after the alpha.

Added file: http://bugs.python.org/file8831/py3k_pyvm3.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Modules/pyvm.c
===
--- Modules/pyvm.c	(Revision 0)
+++ Modules/pyvm.c	(Revision 0)
@@ -0,0 +1,92 @@
+/* pyvm module
+   Low level interface to Python's virtual machine and internal types.
+
+   Copyright (c) 2007 by Christian Heimes <[EMAIL PROTECTED]>
+   Licensed to PSF under a Contributor Agreement.
+   All rights reserved.
+*/
+
+#include "Python.h"
+#include "frameobject.h"
+
+typedef struct _typeinfo {
+	PyTypeObject *type;
+	char *name;
+} typeinfo;
+
+PyDoc_STRVAR(pyvm_doc,
+"Python Virtual Machine module\n");
+
+static PyMethodDef pyvm_methods[] = {
+	{NULL,		NULL}		/* sentinel */
+};
+
+PyMODINIT_FUNC
+initpyvm(void)
+{
+	char *name;
+	PyObject *mod;
+	typeinfo *ti;
+	typeinfo types[] = {
+		/* descriptors */
+		{&PyClassMethodDescr_Type, NULL},
+		{&PyGetSetDescr_Type, NULL},
+		{&PyMemberDescr_Type, NULL},
+		{&PyMethodDescr_Type, NULL},
+		{&PyWrapperDescr_Type, NULL},
+		/* functions */
+		{&PyCFunction_Type, "builtin_method"},
+		{&PyCFunction_Type, "builtin_function"}, /* alias */
+		{&PyFunction_Type, NULL},
+		{&PyMethod_Type, "instance_method"},
+		/* dict */
+		{&PyDictIterKey_Type, NULL},
+		{&PyDictIterValue_Type, NULL},
+		{&PyDictIterItem_Type, NULL},
+		{&PyDictKeys_Type, NULL},
+		{&PyDictItems_Type, NULL},
+		{&PyDictValues_Type, NULL},
+		{&PyDictProxy_Type, NULL},
+		/* iter */
+		{&PyBytesIter_Type, NULL},
+		{&PyCallIter_Type, "callable_iterator"},
+		{&PyLongRangeIter_Type, NULL},
+		{&PyListIter_Type, NULL},
+		{&PyListRevIter_Type, NULL},
+		{&PyRangeIter_Type, NULL},
+		{&PySeqIter_Type, NULL},
+		{&PySetIter_Type, NULL},
+		{&PyStringIter_Type, NULL},
+		{&PyTupleIter_Type, NULL},
+		{&PyUnicodeIter_Type, NULL},
+		/* other */
+		{&PyCObject_Type, NULL},
+		{&PyCode_Type, NULL},
+		{&PyFrame_Type, NULL},
+		{&PyGen_Type, NULL},
+		{&PyModule_Type, NULL},
+		{&PyTraceBack_Type, NULL},
+		{&PyCell_Type, NULL},
+		{&PyEnum_Type, NULL},
+		{&PyReversed_Type, NULL},
+		{&PySortWrapper_Type, NULL},
+		{&PyCmpWrapper_Type, NULL},
+		/* sentinel */
+		{NULL, NULL}
+	};
+
+	mod = Py_InitModule3("pyvm", pyvm_methods, pyvm_doc);
+	if (mod == NULL)
+		return;
+
+	ti = types;
+	while(ti->type != NULL) {
+		name = ti->name;
+		if (name == NULL)
+			name = (char*)ti->type->tp_name;
+		assert(name);
+		Py_INCREF(ti->type);
+		PyModule_AddObject(mod, name, (PyObject *)ti->type);
+		ti++;
+	}
+}

Eigenschaftsänderungen: Modules/pyvm.c
___
Name: svn:keywords
   + Id

Index: Modules/Setup.dist
===
--- Modules/Setup.dist	(Revision 59215)
+++ Modules/Setup.dist	(Arbeitskopie)
@@ -113,6 +113,7 @@
 errno errnomodule.c		# posix (UNIX) errno values
 pwd pwdmodule.c			# this is needed to find out the user's home dir
 # if $HOME is not set
+pyvm pyvm.c			# Python VM low level interface
 _sre _sre.c			# Fredrik Lundh's new regular expressions
 _codecs _codecsmodule.c		# access to the builtin codecs and codec registry
 _fileio _fileio.c		# Standard I/O baseline
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1522] pyvm module patch

[Christian Heimes]

Christian Heimes added the comment:

I've split the patch into two tasks. The first patch adds all types in
Objects/ to the appropriate header files. I've renamed some types, too.

The second patch contains the new pyvm.c module plus a modification to
Modules/Setup.dist.

Added file: http://bugs.python.org/file8830/py3k_add_types_to_h.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Include/iterobject.h
===
--- Include/iterobject.h	(Revision 59215)
+++ Include/iterobject.h	(Arbeitskopie)
@@ -6,12 +6,14 @@
 #endif
 
 PyAPI_DATA(PyTypeObject) PySeqIter_Type;
+PyAPI_DATA(PyTypeObject) PyCallIter_Type;
+PyAPI_DATA(PyTypeObject) PyZipIter_Type;
+PyAPI_DATA(PyTypeObject) PyCmpWrapper_Type;
 
 #define PySeqIter_Check(op) (Py_Type(op) == &PySeqIter_Type)
 
 PyAPI_FUNC(PyObject *) PySeqIter_New(PyObject *);
 
-PyAPI_DATA(PyTypeObject) PyCallIter_Type;
 
 #define PyCallIter_Check(op) (Py_Type(op) == &PyCallIter_Type)
 
Index: Include/stringobject.h
===
--- Include/stringobject.h	(Revision 59215)
+++ Include/stringobject.h	(Arbeitskopie)
@@ -40,6 +40,7 @@
 } PyStringObject;
 
 PyAPI_DATA(PyTypeObject) PyString_Type;
+PyAPI_DATA(PyTypeObject) PyStringIter_Type;
 
 #define PyString_Check(op) \
  PyType_FastSubclass(Py_Type(op), Py_TPFLAGS_STRING_SUBCLASS)
Index: Include/dictobject.h
===
--- Include/dictobject.h	(Revision 59215)
+++ Include/dictobject.h	(Arbeitskopie)
@@ -89,11 +89,24 @@
 };
 
 PyAPI_DATA(PyTypeObject) PyDict_Type;
+PyAPI_DATA(PyTypeObject) PyDictIterKey_Type;
+PyAPI_DATA(PyTypeObject) PyDictIterValue_Type;
+PyAPI_DATA(PyTypeObject) PyDictIterItem_Type;
+PyAPI_DATA(PyTypeObject) PyDictKeys_Type;
+PyAPI_DATA(PyTypeObject) PyDictItems_Type;
+PyAPI_DATA(PyTypeObject) PyDictValues_Type;
 
 #define PyDict_Check(op) \
  PyType_FastSubclass(Py_Type(op), Py_TPFLAGS_DICT_SUBCLASS)
 #define PyDict_CheckExact(op) (Py_Type(op) == &PyDict_Type)
+#define PyDictKeys_Check(op) (Py_Type(op) == &PyDictKeys_Type)
+#define PyDictItems_Check(op) (Py_Type(op) == &PyDictItems_Type)
+#define PyDictValues_Check(op) (Py_Type(op) == &PyDictValues_Type)
+/* This excludes Values, since they are not sets. */
+# define PyDictViewSet_Check(op) \
+	(PyDictKeys_Check(op) || PyDictItems_Check(op))
 
+
 PyAPI_FUNC(PyObject *) PyDict_New(void);
 PyAPI_FUNC(PyObject *) PyDict_GetItem(PyObject *mp, PyObject *key);
 PyAPI_FUNC(int) PyDict_SetItem(PyObject *mp, PyObject *key, PyObject *item);
Index: Include/unicodeobject.h
===
--- Include/unicodeobject.h	(Revision 59215)
+++ Include/unicodeobject.h	(Arbeitskopie)
@@ -417,6 +417,7 @@
 } PyUnicodeObject;
 
 PyAPI_DATA(PyTypeObject) PyUnicode_Type;
+PyAPI_DATA(PyTypeObject) PyUnicodeIter_Type;
 
 #define SSTATE_NOT_INTERNED 0
 #define SSTATE_INTERNED_MORTAL 1
Index: Include/rangeobject.h
===
--- Include/rangeobject.h	(Revision 59215)
+++ Include/rangeobject.h	(Arbeitskopie)
@@ -16,6 +16,8 @@
 */
 
 PyAPI_DATA(PyTypeObject) PyRange_Type;
+PyAPI_DATA(PyTypeObject) PyRangeIter_Type;
+PyAPI_DATA(PyTypeObject) PyLongRangeIter_Type;
 
 #define PyRange_Check(op) (Py_Type(op) == &PyRange_Type)
 
Index: Include/listobject.h
===
--- Include/listobject.h	(Revision 59215)
+++ Include/listobject.h	(Arbeitskopie)
@@ -39,6 +39,9 @@
 } PyListObject;
 
 PyAPI_DATA(PyTypeObject) PyList_Type;
+PyAPI_DATA(PyTypeObject) PyListIter_Type;
+PyAPI_DATA(PyTypeObject) PyListRevIter_Type;
+PyAPI_DATA(PyTypeObject) PySortWrapper_Type;
 
 #define PyList_Check(op) \
 		PyType_FastSubclass(Py_Type(op), Py_TPFLAGS_LIST_SUBCLASS)
Index: Include/tupleobject.h
===
--- Include/tupleobject.h	(Revision 59215)
+++ Include/tupleobject.h	(Arbeitskopie)
@@ -32,6 +32,7 @@
 } PyTupleObject;
 
 PyAPI_DATA(PyTypeObject) PyTuple_Type;
+PyAPI_DATA(PyTypeObject) PyTupleIter_Type;
 
 #define PyTuple_Check(op) \
  PyType_FastSubclass(Py_Type(op), Py_TPFLAGS_TUPLE_SUBCLASS)
Index: Include/descrobject.h
===
--- Include/descrobject.h	(Revision 59215)
+++ Include/descrobject.h	(Arbeitskopie)
@@ -67,7 +67,12 @@
 	void *d_wrapped; /* This can be any function pointer */
 } PyWrapperDescrObject;
 
+PyAPI_DATA(PyTypeObject) PyClassMethodDescr_Type;
+PyAPI_DATA(PyTypeObject) PyGetSetDescr_Type;
+PyAPI_DATA(PyTypeObject) PyMemberDescr_Type;
+PyAPI_DATA(PyTypeObject) PyMethodDescr_Type;
 PyAPI_DATA(PyTypeObject) PyWrapperDescr_Type;
+PyAPI_DATA(PyTypeObject) PyDictProxy_Type;
 
 PyAPI_FUNC(PyObject *) PyDescr_NewM

[issue1522] pyvm module patch

[Brett Cannon]

Brett Cannon added the comment:

There has been talk in the past of cleaning up the sys module by
splitting it up into a package, although I don't know how that would
work for a built-in module, though.

--
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

[issue1522] pyvm module patch

[Christian Heimes]

Christian Heimes added the comment:

Guido van Rossum wrote:
> Stuff in sys that people don't use doesn't really confuse anyone IMO.
> 
> I really don't think that this warrants a new module.
> 
> Many of the datatype-related types (e.g. dict_keys) should not go
> there but in _collections anyway.

I really think we should postpone the decision until after the next
alpha. For now I like to commit the part of the patch that adds all
types to the appropriate header files. A lot of internal types aren't
available from other C files.

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Guido van Rossum]

Guido van Rossum added the comment:

> sys is a very important and often used module, too. I don't like the
> idea to remove one module (types) and clutter an important module with
> its content.

Well, it is already pretty cluttered -- it contains many items that
*I* don't recognize... :-)

> The list of types has grown pretty long and most of the types can't be
> instantiated in Python. I fear that the types are going to confuse too
> many people. However the types are useful for type checking and ABCs.

Stuff in sys that people don't use doesn't really confuse anyone IMO.

I really don't think that this warrants a new module.

Many of the datatype-related types (e.g. dict_keys) should not go
there but in _collections anyway.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Christian Heimes]

Christian Heimes added the comment:

> Why such a strong opinion? 'sys' is pretty close to the VM too...

sys is a very important and often used module, too. I don't like the
idea to remove one module (types) and clutter an important module with
its content.

The list of types has grown pretty long and most of the types can't be
instantiated in Python. I fear that the types are going to confuse too
many people. However the types are useful for type checking and ABCs.

['PyCObject', '__doc__', '__name__', 'builtin_function',
'builtin_method', 'bytearray_iterator', 'bytes_iterator',
'callable_iterator', 'cell', 'classmethod_descriptor', 'cmpwrapper',
'code', 'dict_itemiterator', 'dict_items', 'dict_keyiterator',
'dict_keys', 'dict_valueiterator', 'dict_values', 'dictproxy',
'enumerate', 'frame', 'function', 'generator', 'getset_descriptor',
'instance_method', 'iterator', 'list_iterator', 'list_reverseiterator',
'longrange_iterator', 'member_descriptor', 'method_descriptor',
'module', 'range_iterator', 'reversed', 'set_iterator', 'sortwrapper',
'str_iterator', 'traceback', 'tuple_iterator', 'wrapper_descriptor']

Added file: http://bugs.python.org/file8829/py3k_pyvm2.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Include/iterobject.h
===
--- Include/iterobject.h	(Revision 59215)
+++ Include/iterobject.h	(Arbeitskopie)
@@ -6,12 +6,14 @@
 #endif
 
 PyAPI_DATA(PyTypeObject) PySeqIter_Type;
+PyAPI_DATA(PyTypeObject) PyCallIter_Type;
+PyAPI_DATA(PyTypeObject) PyZipIter_Type;
+PyAPI_DATA(PyTypeObject) PyCmpWrapper_Type;
 
 #define PySeqIter_Check(op) (Py_Type(op) == &PySeqIter_Type)
 
 PyAPI_FUNC(PyObject *) PySeqIter_New(PyObject *);
 
-PyAPI_DATA(PyTypeObject) PyCallIter_Type;
 
 #define PyCallIter_Check(op) (Py_Type(op) == &PyCallIter_Type)
 
Index: Include/stringobject.h
===
--- Include/stringobject.h	(Revision 59215)
+++ Include/stringobject.h	(Arbeitskopie)
@@ -40,6 +40,7 @@
 } PyStringObject;
 
 PyAPI_DATA(PyTypeObject) PyString_Type;
+PyAPI_DATA(PyTypeObject) PyStringIter_Type;
 
 #define PyString_Check(op) \
  PyType_FastSubclass(Py_Type(op), Py_TPFLAGS_STRING_SUBCLASS)
Index: Include/dictobject.h
===
--- Include/dictobject.h	(Revision 59215)
+++ Include/dictobject.h	(Arbeitskopie)
@@ -89,11 +89,24 @@
 };
 
 PyAPI_DATA(PyTypeObject) PyDict_Type;
+PyAPI_DATA(PyTypeObject) PyDictIterKey_Type;
+PyAPI_DATA(PyTypeObject) PyDictIterValue_Type;
+PyAPI_DATA(PyTypeObject) PyDictIterItem_Type;
+PyAPI_DATA(PyTypeObject) PyDictKeys_Type;
+PyAPI_DATA(PyTypeObject) PyDictItems_Type;
+PyAPI_DATA(PyTypeObject) PyDictValues_Type;
 
 #define PyDict_Check(op) \
  PyType_FastSubclass(Py_Type(op), Py_TPFLAGS_DICT_SUBCLASS)
 #define PyDict_CheckExact(op) (Py_Type(op) == &PyDict_Type)
+#define PyDictKeys_Check(op) (Py_Type(op) == &PyDictKeys_Type)
+#define PyDictItems_Check(op) (Py_Type(op) == &PyDictItems_Type)
+#define PyDictValues_Check(op) (Py_Type(op) == &PyDictValues_Type)
+/* This excludes Values, since they are not sets. */
+# define PyDictViewSet_Check(op) \
+	(PyDictKeys_Check(op) || PyDictItems_Check(op))
 
+
 PyAPI_FUNC(PyObject *) PyDict_New(void);
 PyAPI_FUNC(PyObject *) PyDict_GetItem(PyObject *mp, PyObject *key);
 PyAPI_FUNC(int) PyDict_SetItem(PyObject *mp, PyObject *key, PyObject *item);
Index: Include/unicodeobject.h
===
--- Include/unicodeobject.h	(Revision 59215)
+++ Include/unicodeobject.h	(Arbeitskopie)
@@ -417,6 +417,7 @@
 } PyUnicodeObject;
 
 PyAPI_DATA(PyTypeObject) PyUnicode_Type;
+PyAPI_DATA(PyTypeObject) PyUnicodeIter_Type;
 
 #define SSTATE_NOT_INTERNED 0
 #define SSTATE_INTERNED_MORTAL 1
Index: Include/rangeobject.h
===
--- Include/rangeobject.h	(Revision 59215)
+++ Include/rangeobject.h	(Arbeitskopie)
@@ -16,6 +16,8 @@
 */
 
 PyAPI_DATA(PyTypeObject) PyRange_Type;
+PyAPI_DATA(PyTypeObject) PyRangeIter_Type;
+PyAPI_DATA(PyTypeObject) PyLongRangeIter_Type;
 
 #define PyRange_Check(op) (Py_Type(op) == &PyRange_Type)
 
Index: Include/listobject.h
===
--- Include/listobject.h	(Revision 59215)
+++ Include/listobject.h	(Arbeitskopie)
@@ -39,6 +39,9 @@
 } PyListObject;
 
 PyAPI_DATA(PyTypeObject) PyList_Type;
+PyAPI_DATA(PyTypeObject) PyListIter_Type;
+PyAPI_DATA(PyTypeObject) PyListRevIter_Type;
+PyAPI_DATA(PyTypeObject) PySortWrapper_Type;
 
 #define PyList_Check(op) \
 		PyType_FastSubclass(Py_Type(op), Py_TPFLAGS_LIST_SUBCLASS)
Index: Include/tupleobject.h
===
--- Include/tupleobject.h	(Revision 59215)
+++ Include/tupleobject.h	(Ar

[issue1524] os.system() fails for commands with multiple quoted file names

[Guy Mott]

New submission from Guy Mott:

Given a call to os.system() with a command string like this:

   os.system('"TheCommand" > "MyOutput"')  # fails

then the call fails with the following error message on the console:

   'TheCommand" > "MyOutput' is not recognized as an internal or 
external command, operable program or batch file.

Note that both the executable file name and the redirected output file 
name are quoted.

Apparently the command string is being parsed and the first quote is 
incorrectly being matched with the last quote. A more general statement 
of this bug might say that multiple quoted fields on a command line 
cause os.system() to fail. I have not done enough research to better 
characterize the problem.

By contrast, if only one of the file names is quoted then the call to 
os.system() succeeds. E.g., these calls succeed:

   os.system('TheCommand > "MyOutput"')  # succeeds
   os.system('"TheCommand" > MyOutput')  # succeeds

Of course this is a simplified example where it is not necessary to 
quote either file name. Real world examples include 2 file names with 
imbedded spaces. E.g.:

   os.system('"The Command" > "My Output"')  # fails

   'The' is not recognized as an internal or external command, operable 
program or batch file.

A further real-world example is a command line with full path 
specifications for both the executable file and the output file. Such 
path specifications may include imbedded spaces so both need to be 
quoted. However, quoting both causes os.system() to fail. E.g.:

   os.system(r'"C:\New Folder\TheCommand" > "C:\New Folder\MyOutput"')  
# fails

   'C:\New' is not recognized as an internal or external command, 
operable program or batch file.

The above described scenario is the situation in the attached script 
that includes logic for finding an executable file that may not be 
found on the system path but is co-located with the Python script file. 
Thus the script and its companion file(s) may be moved from machine to 
machine and will work correctly even if not in a directory that is 
included on the system path. The script fails because the command line 
that it constructs, with executable and output file specifications 
quoted, fails in os.system().

Here is output from running the attached script:

---

C:\New Folder>buggy.py
strCmdLine=["ListMetadata" > "20071129Metadata.txt"]
'ListMetadata" > "20071129Metadata.txt' is not recognized as an 
internal or external command,
operable program or batch file.
Could not find "ListMetadata" on path, looking in script directory
strCmdLine=["C:\New Folder\ListMetadata" > "20071129Metadata.txt"]
'C:\New' is not recognized as an internal or external command,
operable program or batch file.
Traceback (most recent call last):
  File "C:\New Folder\buggy.py", line 16, in 
raise Exception("Could not locate command")
Exception: Could not locate command

---

Note that the command line that is constructed by the attached script 
runs just fine and produces the desired result if it is executed 
directly at a command line prompt. It is when executed via os.system() 
that the command line fails.

Testing environment:
   OS = Windows XP Professional
   Python = 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit 
(Intel)]

--
components: Extension Modules, Windows
files: buggy.py
messages: 57952
nosy: Quigon
severity: major
status: open
title: os.system() fails for commands with multiple quoted file names
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8828/buggy.py

__
Tracker <[EMAIL PROTECTED]>

__
#===
# This is example logic for Python code that depends upon an external executable
# file. If the executable is found on the system path then no problem.
# Otherwise, this script attempts to execute the executable in the same
# directory where the script is located.
# Unfortunately, this logic fails because os.system() fails when both the
# executable and the output files are both quoted. Note that the command lines
# that this code constructs work just fine at the command prompt. They fail in
# os.system().
#===

import os.path
import sys

strCmdName = "ListMetadata"  # name of our executable file
strOutName = "20071129Metadata.txt"  # name of output file

# Command line is constructed with both file names quoted for maximum 
generality.
strCmdLine = '"%s" > "%s"' % (strCmdName, strOutName)
print "strCmdLine=[%s]" % strCmdLine

nRtn = os.system(strCmdLine)

# if os.system() fails (which it does) ...
if (nRtn != 0):
   print 'Could not find "%s" on path, looking in script directory' % strCmdName

   # Create a new command line with a full executable f

[issue1516] make _ctypes work with non-gcc compilers

[Greg Couch]

Greg Couch added the comment:

The modications work on Tru64 and IRIX.  cc has understood .s suffixes
for a long time.  You use cc instead of as because it knows how to run
the C preprocessor (often /lib/cpp, but not on all systems).

Looking at the Solaris cc manual page (via google), I see that its cc
has the same .S and .s distinction that gcc has, so my patch will not
work with Solaris either.  IRIX has a separate issue in that it has
libffi support for n32 binaries, but doesn't have the ffi_closure
support, so while libffi compiles, _ctypes still fails  to compile (same
would be true if gcc were used).

__
Tracker <[EMAIL PROTECTED]>

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

[issue1506] func alloca inside ctypes lib needs #include on solaris

[Greg Couch]

Greg Couch added the comment:

That's a disappointment.   has the right logic in it
already.  Perhaps it should be copied to callproc.c.  I'm less concerned
about alloca not being there at all because it seems to be a pervasive
extension in non-gcc compilers, but using malloc is fine too.  Please go
ahead and fix this as you see fit.  I've started issue 1516 about using
non-gcc compilers to compile _ctypes/libffi.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Guido van Rossum]

Guido van Rossum added the comment:

> I don't see it as an option. I'd rather keep the types in the 'types'
> module than to add them to the sys module.

Why such a strong opinion? 'sys' is pretty close to the VM too...

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Georg Brandl]

Georg Brandl added the comment:

If there's a new "pyvm" module, there are a few things in sys that
should be moved there, I expect.

--
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Christian Heimes]

Christian Heimes added the comment:

I don't see it as an option. I'd rather keep the types in the 'types'
module than to add them to the sys module.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1506] func alloca inside ctypes lib needs #include on solaris

[Thomas Heller]

Thomas Heller added the comment:

> Greg Couch added the comment:
> 
> Turns out callproc.c forgot to include  after 
> which conditionally includes alloca.h.  So it's a one-line fix.
> 

This would not work.   is a file private to libffi;
when Python is configured to use the system ffi-library (--with-systemffi)
this file is not available.

I would tend to replace the three alloca() calls in the function
_CallProc() in callbacks.c with calls to malloc().  All the other
occurrences of alloca() are only compiled on windows.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 59222 (2.5.2).
Committed revision 59223 (2.6).

Thanks rhamporyncus and jorendorff!!

--
keywords: +patch
resolution:  -> fixed
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

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

[Christian Heimes]

Christian Heimes added the comment:

Guido van Rossum wrote:
> The key that needs to be INCREF'ed is actually startkey.  Patch attached.

What about the second PyObject_RichCompareBool(startkey, key, Py_EQ) a
few lines below inside the for loop?

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

[Guido van Rossum]

Changes by Guido van Rossum:


Removed file: http://bugs.python.org/file8826/fix1517.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

[Guido van Rossum]

Guido van Rossum added the comment:

Oops, the same code appeared twice.  The new fix fixes both places.

Added file: http://bugs.python.org/file8827/fix1517.diff

__
Tracker <[EMAIL PROTECTED]>

__Index: Objects/dictobject.c
===
--- Objects/dictobject.c	(revision 59221)
+++ Objects/dictobject.c	(working copy)
@@ -272,7 +272,9 @@
 	else {
 		if (ep->me_hash == hash) {
 			startkey = ep->me_key;
+Py_INCREF(startkey);
 			cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
+Py_DECREF(startkey);
 			if (cmp < 0)
 return NULL;
 			if (ep0 == mp->ma_table && ep->me_key == startkey) {
@@ -302,7 +304,9 @@
 			return ep;
 		if (ep->me_hash == hash && ep->me_key != dummy) {
 			startkey = ep->me_key;
+Py_INCREF(startkey);
 			cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
+Py_DECREF(startkey);
 			if (cmp < 0)
 return NULL;
 			if (ep0 == mp->ma_table && ep->me_key == startkey) {
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

[Guido van Rossum]

Guido van Rossum added the comment:

I can reproduce the segfault in 2.2 through 2.4; in 2.5 and 2.6 the
output is this instead:

Test 1, using __eq__(a, b).__nonzero__()
this is never the right answer
*
Test 2, using tuple's tp_richcompare
New Watch 0xf7f8cbac
New Watch 0xf7f8cc0c
Deleting Watch 0xf7f8cbac
Deleting Watch 0xf7f8cbac
Deleting Watch 0xf7f8cc0c
Traceback (most recent call last):
  File "/tmp/db3.py", line 72, in 
print(d[(Bar(), Watch())])
TypeError: __eq__() takes exactly 1 argument (2 given)

which suggests it's still there ("this is never the right answer").

In 3.0 the output from the 1st test is "this is an acceptable answer"
suggesting it's no longer there; but I suspect it's there in 3.0 as well
but due to the unicode transition the dict code there is different
enough that the example doesn't trigger it.

The key that needs to be INCREF'ed is actually startkey.  Patch attached.

--
nosy: +gvanrossum
versions: +Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, 
Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8826/fix1517.diff

__
Tracker <[EMAIL PROTECTED]>

__Index: Objects/dictobject.c
===
--- Objects/dictobject.c	(revision 59221)
+++ Objects/dictobject.c	(working copy)
@@ -272,7 +272,9 @@
 	else {
 		if (ep->me_hash == hash) {
 			startkey = ep->me_key;
+Py_INCREF(startkey);
 			cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
+Py_DECREF(startkey);
 			if (cmp < 0)
 return NULL;
 			if (ep0 == mp->ma_table && ep->me_key == startkey) {
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1518] Fast globals/builtins access (patch)

[Chris Mellon]

Chris Mellon added the comment:

I may have had some old code in the build or something - I did a clean
rebuild to look at some of the slowdowns and the fastglobals_test
benchmarks are now even better than Neils. Pybench is still overall
slower but it's mostly in float operations, which seems odd and I'd
discount it unless someone else can recreate it. I've updated the
spreadsheet I linked before with the updated timings, along with my
microbenchmark and pystone results. Very impressive speedup on pystone,
no doubt because of the heavy use of globals.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Guido van Rossum]

Guido van Rossum added the comment:

Hm... What if we just put these names in sys?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1523] xdrlib fails to detect overflow (struct bug?)

[Jack Lloyd]

New submission from Jack Lloyd:

The XDR format requires integers to fit into 4 byte values. However (at
least on x86-64) xdrlib will silently accept (and truncate) values
larger than this (up to 2**64-1). Taking a (very brief) look at the
xdrlib code, it appears this is actually a problem in the struct module,
but I don't have the time (or interest) to trace through the _struct
module code.

An example on an x86-64 machine (Python 2.4.3) of encoding 2**32 (which
will not fit in an XDR field) being silently truncated:

$ ./xdr.py 
4294967296 ->  -> 0

An example of struct itself not detecting overflow:

>>> struct.pack("!I", 2**32)
'\x00\x00\x00\x00'

struct.pack will only throw an overflow error if a value >= 2**64 is
used, even if it is encoding into a field that is much smaller.

--
components: Extension Modules
files: xdr.py
messages: 57939
nosy: lloyd
severity: normal
status: open
title: xdrlib fails to detect overflow (struct bug?)
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file8825/xdr.py

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1521] string.decode() fails on long strings

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

I don't have any 64bit machine to test with,
but it seems to me that there is a problem in the function
getargs.c::convertsimple(): the t# and w# formats use the buffer
interface, but the code uses an int to store its length!

Look for the variables declared as "int count;". I suggest to replace it
with a Py_ssize_t in both places.

Shouldn't the compiler emit some warning in this case?

--
nosy: +amaury.forgeotdarc

__
Tracker <[EMAIL PROTECTED]>

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

[issue1522] pyvm module patch

[Christian Heimes]

New submission from Christian Heimes:

I've created a pyvm module for Python 3.0. So far it just contains a
bunch of internal types. What methods do you like to add to pyvm?
Somebody suggested internal functions from sys like the check internal.

--
components: Extension Modules, Interpreter Core
files: py3k_pyvm.patch
keywords: patch, py3k
messages: 57937
nosy: gvanrossum, tiran
priority: normal
severity: normal
status: open
title: pyvm module patch
versions: Python 3.0
Added file: http://bugs.python.org/file8824/py3k_pyvm.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Include/descrobject.h
===
--- Include/descrobject.h	(Revision 59215)
+++ Include/descrobject.h	(Arbeitskopie)
@@ -67,6 +67,10 @@
 	void *d_wrapped; /* This can be any function pointer */
 } PyWrapperDescrObject;
 
+PyAPI_DATA(PyTypeObject) PyClassMethodDescr_Type;
+PyAPI_DATA(PyTypeObject) PyGetSetDescr_Type;
+PyAPI_DATA(PyTypeObject) PyMemberDescr_Type;
+PyAPI_DATA(PyTypeObject) PyMethodDescr_Type;
 PyAPI_DATA(PyTypeObject) PyWrapperDescr_Type;
 
 PyAPI_FUNC(PyObject *) PyDescr_NewMethod(PyTypeObject *, PyMethodDef *);
Index: Objects/descrobject.c
===
--- Objects/descrobject.c	(Revision 59216)
+++ Objects/descrobject.c	(Arbeitskopie)
@@ -383,7 +383,7 @@
 	return 0;
 }
 
-static PyTypeObject PyMethodDescr_Type = {
+PyTypeObject PyMethodDescr_Type = {
 	PyVarObject_HEAD_INIT(&PyType_Type, 0)
 	"method_descriptor",
 	sizeof(PyMethodDescrObject),
@@ -421,7 +421,7 @@
 };
 
 /* This is for METH_CLASS in C, not for "f = classmethod(f)" in Python! */
-static PyTypeObject PyClassMethodDescr_Type = {
+PyTypeObject PyClassMethodDescr_Type = {
 	PyVarObject_HEAD_INIT(&PyType_Type, 0)
 	"classmethod_descriptor",
 	sizeof(PyMethodDescrObject),
@@ -458,7 +458,7 @@
 	0,	/* tp_descr_set */
 };
 
-static PyTypeObject PyMemberDescr_Type = {
+PyTypeObject PyMemberDescr_Type = {
 	PyVarObject_HEAD_INIT(&PyType_Type, 0)
 	"member_descriptor",
 	sizeof(PyMemberDescrObject),
@@ -495,7 +495,7 @@
 	(descrsetfunc)member_set,		/* tp_descr_set */
 };
 
-static PyTypeObject PyGetSetDescr_Type = {
+PyTypeObject PyGetSetDescr_Type = {
 	PyVarObject_HEAD_INIT(&PyType_Type, 0)
 	"getset_descriptor",
 	sizeof(PyGetSetDescrObject),
Index: Makefile.pre.in
===
--- Makefile.pre.in	(Revision 59215)
+++ Makefile.pre.in	(Arbeitskopie)
@@ -328,6 +328,7 @@
 LIBRARY_OBJS=	\
 		Modules/_typesmodule.o \
 		Modules/getbuildinfo.o \
+		Modules/pyvm.o \
 		$(PARSER_OBJS) \
 		$(OBJECT_OBJS) \
 		$(PYTHON_OBJS) \
@@ -365,6 +366,7 @@
 	-rm -f $@
 	$(AR) cr $@ Modules/getbuildinfo.o
 	$(AR) cr $@ Modules/_typesmodule.o
+	$(AR) cr $@ Modules/pyvm.o
 	$(AR) cr $@ $(PARSER_OBJS)
 	$(AR) cr $@ $(OBJECT_OBJS)
 	$(AR) cr $@ $(PYTHON_OBJS)
Index: Modules/pyvm.c
===
--- Modules/pyvm.c	(Revision 0)
+++ Modules/pyvm.c	(Revision 0)
@@ -0,0 +1,69 @@
+
+
+
+/* pyvm module
+   Low level interface to Python's virtual machine and internal types.
+
+   Copyright (c) 2007 by Christian Heimes <[EMAIL PROTECTED]>
+   Licensed to PSF under a Contributor Agreement.
+   All rights reserved.
+*/
+
+#include "Python.h"
+#include "frameobject.h"
+
+typedef struct _typeinfo {
+	PyTypeObject *type;
+	char *name;
+} typeinfo;
+
+PyDoc_STRVAR(pyvm_doc,
+"Python Virtual Machine module\n");
+
+static PyMethodDef pyvm_methods[] = {
+	{NULL,		NULL}		/* sentinel */
+};
+
+PyMODINIT_FUNC
+initpyvm(void)
+{
+	char *name;
+	PyObject *mod;
+	typeinfo *ti;
+	typeinfo types[] = {
+		/* descriptor types */
+		{&PyClassMethodDescr_Type, NULL},
+		{&PyGetSetDescr_Type, NULL},
+		{&PyMemberDescr_Type, NULL},
+		{&PyMethodDescr_Type, NULL},
+		{&PyWrapperDescr_Type, NULL},
+		/* functions */
+		{&PyCFunction_Type, "builtin_method"},
+		{&PyCFunction_Type, "builtin_function"}, /* alias */
+		{&PyFunction_Type, NULL},
+		{&PyMethod_Type, "instance_method"},
+		/* other */
+		{&PyCode_Type, NULL},
+		{&PyFrame_Type, NULL},
+		{&PyGen_Type, NULL},
+		{&PyModule_Type, NULL},
+		{&PyTraceBack_Type, NULL},
+		{&PyCallIter_Type, "callable_iterator"},
+		{NULL, NULL}	/* sentinel */
+	};
+
+	mod = Py_InitModule3("pyvm", pyvm_methods, pyvm_doc);
+	if (mod == NULL)
+		return;
+
+	ti = types;
+	while(ti->type != NULL) {
+		name = ti->name;
+		if (name == NULL)
+			name = (char*)ti->type->tp_name;
+		assert(name);
+		Py_INCREF(ti->type);
+		PyModule_AddObject(mod, name, (PyObject *)ti->type);
+		ti++;
+	}
+}

Eigenschaftsänderungen: Modules/pyvm.c
___
Name: svn:keywords
   + Id

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

[issue1521] string.decode() fails on long strings

[Andreas Eisele]

Andreas Eisele added the comment:

An instance of the other problem:

Python 2.5.1 (r251:54863, Aug 30 2007, 16:15:51) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
__[1] >>> s=" "*int(25E8)
2.99 sec
__[1] >>> u=s.decode("utf-8")
Traceback (most recent call last):
  File "", line 1, in 
  File
"/home/cl-home/eisele/lns-root-07/lib/python2.5/encodings/utf_8.py",
line 16, in decode
return codecs.utf_8_decode(input, errors, True)
TypeError: utf_8_decode() argument 1 must be (unspecified), not str
__[1] >>>

__
Tracker <[EMAIL PROTECTED]>

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

[issue1521] string.decode() fails on long strings

[Andreas Eisele]

Andreas Eisele added the comment:

For instance:

Python 2.5.1 (r251:54863, Aug 30 2007, 16:15:51) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
__[1] >>> s=" "*int(5E9)
6.05 sec
__[1] >>> u=s.decode("utf-8")
4.71 sec
__[1] >>> len(u) 
705032704
__[2] >>> len(s)
50
__[3] >>> 

I would have expected both lengths to be 5E9

__
Tracker <[EMAIL PROTECTED]>

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

[issue1521] string.decode() fails on long strings

[Walter Dörwald]

Walter Dörwald added the comment:

Can you attach a (small) example that demonstrates the bug?

--
nosy: +doerwalter

__
Tracker <[EMAIL PROTECTED]>

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

[issue1518] Fast globals/builtins access (patch)

[Chris Mellon]

Chris Mellon added the comment:

In funcobject.c:PyFunction_New, the declarations of op and __name__ need
to be moved to the top of the function to compile in MSVC, and if
accepted the fastglobals.c file needs to be added to PCBuild.

In the test script, the use of import * generates syntax warnings that
make the output awkward to read, and the benchmark for dict_get is
actually running dict_set. I'm attaching the fixed copy of the test
script I used.

I see roughly the same speed ups (MSVC 7.1, Windows XP, Intel Core2 Duo
@ 2.13Ghz), but I see a 10% slowdown in the dict-insert/delete and
dict-set benchmarks which I find very troubling.

TestTrunk  fastglobalsTime difference
--
Dict insert/del 2.0024954952.2074091251.102329134
Dict get0.7502532050.7455766620.993766714
Dict set0.9826959211.1149977661.13463152
Local get   0.5333870290.51337118 0.96247406
Local set   0.5965657740.6141249141.029433703
Global get  0.9356050730.7311365840.78145855
Global set  1.48638532 1.03868462 0.69879903
Builtin get 1.3926063670.7351806730.52791707
Function call   1.9387057811.7162330040.885246756
List comp   1.5477801051.1882157560.767690289


PyBench shows an overall slowdown - String mappings in particular,
string/unicode predicates, and new instance creation all show
significant slowdowns. The results are fairly verbose so I've uploaded
them as a google docs spreadsheet at
http://spreadsheets.google.com/ccc?key=p7g0z40g_NpvH5UpPTpr-Ag&hl=en

I notice that you create a new PyFastGlobals object in every call to
PyEval_EvalCode. This might explain some of the general case slowdown,
is this really what you want to do?

--
nosy: +arkanes
Added file: http://bugs.python.org/file8823/fastglobals_test.py

__
Tracker <[EMAIL PROTECTED]>

__import timeit, new, time, dis

MULTIPLIER = 1


def test_local_get():
	x = 0
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x
	x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x; x


def test_local_set():
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x = 0
	x = 0; x = 0; x = 0; x = 0; x = 0; x = 0; x

[issue1521] string.decode() fails on long strings

[Andreas Eisele]

New submission from Andreas Eisele:

s.decode("utf-8")

sometimes silently truncates the result if s has more than 2E9 Bytes,
sometimes raises a fairly incomprehensible exception:

Traceback (most recent call last):
  File "", line 2, in 
  File "/usr/lib64/python2.5/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
TypeError: utf_8_decode() argument 1 must be (unspecified), not str

--
components: Unicode
messages: 57932
nosy: eisele
severity: normal
status: open
title: string.decode() fails on long strings
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

[issue1520] 'without make' documentation build anomaly

[Joseph Armbruster]

New submission from Joseph Armbruster:

When I run the following from a windows command line, the resulting html
can not be browsed stand-alone:

python tools/sphinx-build.py -bhtml . build/htmlwin

It looks like the paths are getting hosed up; for example:

htmlcygwin/c-api/index.html contains:



htmlcmd/c-api/index.html contains:



Notes:

These seemed to work fine:

- building target html it in cygwin using make
- building target html in cygwin without make
- building target htmlhelp in cmd without make then generating chm

--
components: Documentation, Documentation tools (Sphinx)
messages: 57931
nosy: JosephArmbruster
severity: minor
status: open
title: 'without make' documentation build anomaly
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1519] async_chat.__init__() parameters

[Nadeem Vawda]

New submission from Nadeem Vawda:

The __init__() function for asynchat.async_chat doesn't allow the caller
to specify a channel map.  I thought it would make sense to add an
optional 'map' parameter, for consistency with asyncore.dispatcher.  If
the parameter is not specified, asyncore.dispatcher.__init__() will
default to using the global map, which is the current behaviour.

--
components: Library (Lib)
files: asynchat.patch
messages: 57930
nosy: nvawda
severity: minor
status: open
title: async_chat.__init__() parameters
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8822/asynchat.patch

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1518] Fast globals/builtins access (patch)

[Christian Heimes]

Christian Heimes added the comment:

When I run the code of test_gc.py test_function() in a shell I'm getting
the expected result of 2 collected items:

gc: collectable 
gc: collectable 

However the same code embedded in the test suite collects two additional
objects:

gc: collectable 
gc: collectable 
gc: collectable 
gc: collectable 

I've used gc.set_debug(gc.DEBUG_LEAK) to get the information

--
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

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

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

[Christian Heimes]

Christian Heimes added the comment:

Two questions:
* Which versions of Python are vulnerable to the problem? You forgot to
fill in the version list.
* How do we fix the problem? Is it enough to incref the key or must
startkey be protected, too?

--
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

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