[Python-Dev] Improved dyn mod load debug
I had mistakenly installed a module (Qsci.so) into the wrong directory.
Debugging this was harder than it needed to be (c-level debug of shared
lib).
Currently, the only debug info is from importdl.c:
m = PyDict_GetItemString(PyImport_GetModuleDict(), name);
if (m == NULL) {
PyErr_SetString(PyExc_SystemError,
"dynamic module not initialized properly");
return NULL;
}
I wonder if it would be difficult to print out the name expected, and the
name actually loaded? In this case, it would have said:
expected: PyQt4/Qsci
loaded: Qsci
___
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] Improved dyn mod load debug
Neal Becker wrote:
> I had mistakenly installed a module (Qsci.so) into the wrong directory.
> Debugging this was harder than it needed to be (c-level debug of shared
> lib).
>
> Currently, the only debug info is from importdl.c:
> m = PyDict_GetItemString(PyImport_GetModuleDict(), name);
> if (m == NULL) {
> PyErr_SetString(PyExc_SystemError,
> "dynamic module not initialized properly");
> return NULL;
> }
>
> I wonder if it would be difficult to print out the name expected, and the
> name actually loaded? In this case, it would have said:
How do you like:
if (p == NULL) {
PyErr_Format(PyExc_ImportError,
"dynamic module '%.400s' does not define init
function (init%.200s)",
pathname, shortname);
return NULL;
}
m = PyDict_GetItemString(PyImport_GetModuleDict(), name);
if (m == NULL) {
PyErr_Format(PyExc_SystemError,
"dynamic module '%.400s' not initialized
properly",
pathname);
return NULL;
}
Christian
___
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] [patch] Improvements for float and math
I've implemented several small improvements for floats and the math
module. You can find a description and the patches in our bug tracker:
http://bugs.python.org/issue1635
http://bugs.python.org/issue1640
Summary:
* Full and platform independent round trip for +/-inf and nan. Before
the patch the round trip didn't work on Windows and Windows returned
different repr() for nan and inf (1.#INF and -1.#IND).
>>> 1e500
inf
>>> -1e500
-inf
>>> 1e500 * 0.
nan
>>> float("nan")
nan
>>> float("inf")
inf
>>> float("-inf")
-inf
* math.isnan() and math.isinf() functions. The Py_IS_NAN and
Py_IS_INFINITY macros now use isinf and isnan on platforms that support
the functions. Although they are C99 functions they are also available
on GNU89 (C89 + GNU extensions) and other platforms. We already use them
on Windows.
* math.sign() function
>>> math.sign(42)
1
>>> math.sign(-42)
-1
>>> math.sign(0)
0
On platforms with full IEEE 754 semantics and copysign() support:
>>> math.sign(0.0)
1
>>> math.sign(-0.0)
-1
* Py_MATH_PI and Py_MATH_E macros with long double precision for future use.
* 1st and 2nd kind Bessel functions (j0, j1. jn, y0, y1, yn), error
functions (erf, erfc) and gamma function (lgamma with sign). They are
available in most libm libraries.
Please review the patches and comment on them.
Christian
___
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] asyncore delayed calls feature
I would ask if someone using asyncore could review this, please: http://bugs.python.org/issue1641 ___ 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] PyTuple_Pack with NULL argument
Currently, PyTuple_Pack() does not check for NULL arguments, so it is going to segfault in this case. Is this intended for performance reasons? -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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] Signals+Threads (PyGTK waking up 10x/sec).
Op dinsdag 11-12-2007 om 17:03 uur [tijdzone -0800], schreef Guido van Rossum: > On Dec 11, 2007 4:54 PM, Jan Claeys <[EMAIL PROTECTED]> wrote: > > Op vrijdag 07-12-2007 om 07:26 uur [tijdzone -0700], schreef Sean > > Reifschneider: > > > I would say that this is an optimization that helps a specific set of > > > platforms, including one that I think we really care about, the OLPC > > > which needs it for decreased battery use. > > > > Almost every laptop user would benefit from it, and even some desktop or > > server users might save on their electric power bill... > > Do you have data to support this claim? Not PyGTK-specific data, but you can see power-saving by reducing wakeups by playing with Intel's 'powertop' utility on linux (also see the "lesswatts" site mentioned earlier). One example was the interaction between PulseAudio & ALSA that caused a lot of "wakeups", and thus prevented laptops from going into the more "agressive" power saving modes; if PyGTK has a similar issue, that would make it less useful on laptops... -- Jan Claeys ___ 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] Deploying embedded Python
Hi - [Apologies if this isn't the right list but I couldn't find any mailing list specifically dedicated to embedded Python. Does such a list exist?] I'm currently looking into a few deployment issues with our embedded Python interpreter and I'm looking for any information about deploying embedded Python that people may have. Specifically, I'm looking for the following information: 1) How to define a useful subset of the stdlib that can serve as an initial basis for the installation but later allows upgrade to the "full" library if desirable. In other words, I'd like to deploy a small subset of the stdlib to begin with (simply because of size constraints) which may later be extended to a full stdlib if this is desirable. Has someone done this before? I'd love to have a small "Python.zip" cross-platform stdlib surrogate that just gets shipped with the product. If not, what is the right starting point for analyzing the dependencies inside the stdlib? 2) How to isolate the embedded interpreter from environmental effects. I have found that on occasion, the interpreter would pick up "stray" installations which can cause weird problems. Which environmental settings affect the startup of an embedded Python interpreter? How does one work around/remove those dependencies? Is there any information available about how exactly the startup works? What is being read/loaded in which order etc? 3) General advice about deploying embedded Python. Pointers to web sites, general experience (good or bad) etc. are all very welcome. Thanks, - Andreas ___ 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] PyTuple_Pack with NULL argument
Yes, a tuple containing NULL should never be exposed to Python code -- it should only ever be a temporary result in C code. The C code should ensure all tuple items are non-NULL before passing the tuple off to Python (or even to its caller, in most cases). --Guido On Dec 17, 2007 1:19 PM, Lisandro Dalcin <[EMAIL PROTECTED]> wrote: > Currently, PyTuple_Pack() does not check for NULL arguments, so it is > going to segfault in this case. Is this intended for performance > reasons? > > > -- > Lisandro Dalcín > --- > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) > PTLC - Güemes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Deploying embedded Python
On Mon, Dec 17, 2007, Andreas Raab wrote: > > [Apologies if this isn't the right list but I couldn't find any mailing > list specifically dedicated to embedded Python. Does such a list exist?] There isn't, really, but python-dev is by definition NOT the correct list because you're asking questions about using Python rather than about improving the code in Python. You should use either comp.lang.python or capi-sig. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith ___ 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] Deploying embedded Python
Aahz wrote: > On Mon, Dec 17, 2007, Andreas Raab wrote: >> [Apologies if this isn't the right list but I couldn't find any mailing >> list specifically dedicated to embedded Python. Does such a list exist?] > > There isn't, really, but python-dev is by definition NOT the correct list > because you're asking questions about using Python rather than about > improving the code in Python. You should use either comp.lang.python or > capi-sig. Thanks for pointing this out. I wasn't aware that this list is exclusively about improving the code in Python - I thought that discussions about, for example, the contents and structure of the stdlib as well as the startup of the interpreter would be on-topic here (mainly because it's fairly specialized knowledge that I wouldn't expect to be widely available outside of the python-dev community). In any case, I'll repost on the lists you're mentioning. Cheers, - Andreas ___ 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
