Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
The assertion is clear if you open the source code (Python/pystate.c,
line 561):
assert(autoInterpreterState); /* Py_Initialize() hasn't been called! */
Does your code make sure that the python interpreter is initialized?
--
New submission from David Leonard [EMAIL PROTECTED]:
Patch to allow unit tests to test for exceptions through a 'with'
statement. Resulting (failing) test would look like this:
import unittest
class T(unittest.TestCase):
def runTest(self):
with self.assertRaises(KeyError):
Mart Sõmermaa [EMAIL PROTECTED] added the comment:
Corrections and clarifications:
* I'd say labeling the patch naive and breaking things was misleading
(there was a breakage that resulted from stale files with incorrect
permissions from my previous build of Python 2.6; after a make distclean
Mark Dickinson [EMAIL PROTECTED] added the comment:
Updated patch: fix overflow checks to use offsetof instead of sizeof as
well.
Added file: http://bugs.python.org/file12141/string_alloc.patch
___
Python tracker [EMAIL PROTECTED]
Changes by Mark Dickinson [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file12140/string_alloc.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4445
___
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Py_Initialize();
Py_Main(7, arg1);
Py_Finalize();
This seems correct... unless two threads run this function at the same
time. Can you ensure that this is not the case?
It seems to me that a simple call to
system(python
LuisC [EMAIL PROTECTED] added the comment:
Hi Amaury, thanks for you response...
This is my code sniped
gboolean
gui_file_copy_to_journal(char const *uri)
{
g_printerr(SAVING PYTHON JOURNAL!...%s\n, uri);
char * arg1[7];
arg1[0] = python;
arg1[1] =
New submission from Mark Dickinson [EMAIL PROTECTED]:
There are a number of places in Objects/stringobject.c where memory is
allocated for a string of length n using:
PyObject_MALLOC(sizeof(PyStringObject) + n)
On my computer (OS X 10.5.5/Intel), and, I suspect, on most common
platforms, the
New submission from Simon Cross [EMAIL PROTECTED]:
The section on Additional meta-data in Doc/distutils/setupscript.rst is
missing any reference to the setup() platforms keyword. I've attached
a patch which fills in the basics but there are some outstanding questions:
- Does note (4) about
Steve Purcell [EMAIL PROTECTED] added the comment:
I like this change, since assertRaises can be a bit messy when passing it
a local function.
I'd suggest modifying the patch such that the AssertRaisesContext class is
also used when callableObj is provided, which would eliminate the
LuisC [EMAIL PROTECTED] added the comment:
Thank you so much. It do worked!
I don't think two threads to be running the same function because the
messages are displayed only once.
Yes it seems to be a better way it worked, thank you again.
Regards,
Luis Carrión
Tata Consultancy Services
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]:
--
resolution: - invalid
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4443
___
Kristján Valur Jónsson [EMAIL PROTECTED] added the comment:
I like the suggestion of having endheaders() accept any extra data.
I have uploaded a new patch which implements this idea. It simplifies
things a lot.
The issue with the read buffer size is still open. I have sent an
email to
Raymond Hettinger [EMAIL PROTECTED] added the comment:
+1 on the idea. -1 on the current patch. Can you encapsulate this in a
simpler macro? I find the proposed replacement to be cryptic and
error-prone (i.e. hard to mentally verify its correctness and somewhat
likely to be screwed-up by a
Georg Brandl [EMAIL PROTECTED] added the comment:
Please submit Sphinx bugs in its own tracker:
http://bitbucket.org/birkenfeld/sphinx/issues
--
resolution: - invalid
status: open - closed
___
Python tracker [EMAIL PROTECTED]
Georg Brandl [EMAIL PROTECTED] added the comment:
Please submit Sphinx bugs in its own tracker:
http://bitbucket.org/birkenfeld/sphinx/issues
(Yes, I know there was still a Sphinx component -- I've removed that now.)
--
resolution: - invalid
status: open - closed
Changes by Georg Brandl [EMAIL PROTECTED]:
--
assignee: georg.brandl - loewis
nosy: +loewis
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4446
___
___
rb [EMAIL PROTECTED] added the comment:
What is the purpose of linking to the static library if you're still
going to depend on shared objects in lib-dynload?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4434
Akira Kitada [EMAIL PROTECTED] added the comment:
I'm having similar problem with distutils.
http://mail.python.org/pipermail/python-dev/2008-November/083670.html
Is there any reason customize_compiler
- only get CPPFLAGS in env, not ones from sysconfig?
- doesn't get OPT from from sysconfig,
New submission from David M. Beazley [EMAIL PROTECTED]:
Is the following code valid Python 3 or not?
def foo():
x = 1
exec(x = 42)
print(x)# Prints 1 (exec has no effect)
I know there are a variety of issues surrounding exec(), function
bodies, and other matters. Just
Georg Brandl [EMAIL PROTECTED] added the comment:
It is valid Python 3 and the lack of an effect on the local is correct.
From Python 3 on, exec is a function and therefore lacks the special
magic properties it had in Python 2 that made it possible execute the
code as if it just was written
John Levon [EMAIL PROTECTED] added the comment:
Besides, .so files should always declare their dependencies.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4434
___
David M. Beazley [EMAIL PROTECTED] added the comment:
For what it's worth, I hope this behavior gets well-documented. Thanks.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4447
___
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Suggestion:
#define PyStringObject_SIZE (offsetof(PyStringObject, ob_sval) + 1)
/* Inline PyObject_NewVar */
- op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size);
/* Inline PyObject_NewVar */
+
Thomas Heller [EMAIL PROTECTED] added the comment:
Currently, the _fields_ of ctypes Structures with non-native byte order
can only contain simple types (like int, char, but not pointers), and
arrays of those.
Since this is all Python code (in Lib/ctypes/endian.py) it should be
possible to
Thomas Heller [EMAIL PROTECTED] added the comment:
Correction:
Since this is all Python code (in Lib/ctypes/_endian.py) it should be
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4376
___
Changes by Gabriel Genellina [EMAIL PROTECTED]:
--
nosy: +gagenellina
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4309
___
___
Python-bugs-list
Changes by Gabriel Genellina [EMAIL PROTECTED]:
--
nosy: +gagenellina
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4022
___
___
Python-bugs-list
Changes by Gabriel Genellina [EMAIL PROTECTED]:
--
nosy: +gagenellina
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4315
___
___
Python-bugs-list
Mart Sõmermaa [EMAIL PROTECTED] added the comment:
See also
http://mail.python.org/pipermail/python-dev/2008-November/083727.html
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4438
___
New submission from Gregory P. Smith [EMAIL PROTECTED]:
From Kristján Valur Jónsson (kristjan at ccpgames.com) on python-dev:
http://mail.python.org/pipermail/python-dev/2008-November/083724.html
I came across this in socket.c:
# _rbufsize is the suggested recv buffer size.
Weeble [EMAIL PROTECTED] added the comment:
Is this ever likely to make it into IDLE? Running without a subprocess
in Windows appears to interact badly with the multiprocessing library
(attempting to spawn a process just creates a new IDLE window). I
couldn't figure out how to apply the patch
Ralf Schmitt [EMAIL PROTECTED] added the comment:
Yes, there is no purpose in linking with a static library when the
dynamically loaded modules still depend on the shared library.
And yes, the dynamically loaded libraries should declare their
dependencies. My point is they do *not* depend on the
Changes by Lars Immisch [EMAIL PROTECTED]:
--
nosy: +larsimmisch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4073
___
___
Python-bugs-list mailing
Guido van Rossum [EMAIL PROTECTED] added the comment:
You meant socket.py.
This is an extremely subtle area. I would be very wary of changing this
-- there is a use case where headers are read from the socket using
readline() but the rest of the data is read directly from the socket,
and this
35 matches
Mail list logo
