[Python-Dev] constness of interpreter data
libpython2.5.a contains quite a lot of .data that doesn't look like it
needs to be writable (my minimal interpreter binary has 105KB of
writable allocated data). A lot of these symbols look like they could
just be tagged const with no other changes to the interpreter; some of
them would require a proliferation of constness. I'm a bit new at this,
though, and it's possible that I'm wrong about some/most/all of these,
so I'm wondering what people think.
Attached is a patch which adds const to the easy ones:
* Docstrings for extension functions (PyDoc_VAR in Python.h)
* ascii->digit lookup table (_PyLong_DigitValue in longobject.c)
* The copyright notice (cprt in getcopyright.c)
There are no errors or new warnings introduced in my build by this
patch, but I'm only compiling the interpreter itself. If anyone can
suggest a reason why any of those shouldn't be const, please do :)
Things that take up space that might be const-able with more effort, or
might not, I can't tell:
* Token names (_PyParser_TokenNames in tokenizer.c)
* Module function tables (and ensuing propagation of constness into
PyModule_Init etc)
* All the type and exception objects
Things that take up space but probably aren't const-able unless someone
who knows more than me has an idea:
* Standard slot definitions (slotdefs in typeobject.c, but the
interned string pointers get added at runtime)
* The generated tables for the grammar (but the accelerator seems to
want to change these at init time)
There's probably other things, but I didn't go through the entire symbol
table, just started with the big ones :)
So, er, is this a remotely sane thing to be doing, and does anyone have
suggestions? :)
--
Torne Wuff
[EMAIL PROTECTED]
Index: quilted/Include/Python.h
===
--- quilted.orig/Include/Python.h 2008-09-01 16:00:58.0 +0100
+++ quilted/Include/Python.h 2008-09-01 16:01:57.0 +0100
@@ -162,7 +162,7 @@
#endif
/* Define macros for inline documentation. */
-#define PyDoc_VAR(name) static char name[]
+#define PyDoc_VAR(name) static const char name[]
#define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str)
#ifdef WITH_DOC_STRINGS
#define PyDoc_STR(str) str
Index: quilted/Objects/longobject.c
===
--- quilted.orig/Objects/longobject.c 2008-09-01 16:00:58.0 +0100
+++ quilted/Objects/longobject.c 2008-09-01 16:01:57.0 +0100
@@ -1340,7 +1340,7 @@
* Note that when converting a base B string, a char c is a legitimate
* base B digit iff _PyLong_DigitValue[Py_CHARMASK(c)] < B.
*/
-int _PyLong_DigitValue[256] = {
+const int _PyLong_DigitValue[256] = {
37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37,
37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37,
37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37,
Index: quilted/Python/getcopyright.c
===
--- quilted.orig/Python/getcopyright.c 2008-09-01 16:00:58.0 +0100
+++ quilted/Python/getcopyright.c 2008-09-01 16:01:57.0 +0100
@@ -2,7 +2,7 @@
#include "Python.h"
-static char cprt[] =
+static const char cprt[] =
"\
Copyright (c) 2001-2008 Python Software Foundation.\n\
All Rights Reserved.\n\
Index: quilted/Include/longobject.h
===
--- quilted.orig/Include/longobject.h 2008-09-01 16:00:58.0 +0100
+++ quilted/Include/longobject.h 2008-09-01 16:01:57.0 +0100
@@ -25,7 +25,7 @@
PyAPI_FUNC(Py_ssize_t) _PyLong_AsSsize_t(PyObject *);
PyAPI_FUNC(PyObject *) _PyLong_FromSize_t(size_t);
PyAPI_FUNC(PyObject *) _PyLong_FromSsize_t(Py_ssize_t);
-PyAPI_DATA(int) _PyLong_DigitValue[256];
+PyAPI_DATA(const int) _PyLong_DigitValue[256];
/* _PyLong_AsScaledDouble returns a double x and an exponent e such that
the true value is approximately equal to x * 2**(SHIFT*e). e is >= 0.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is the 'path' argument to an importer's find_module() just a hint?
On Mon, Oct 27 08 at 1:44:29PM -0700, Brett Cannon wrote: > I doubt anyone does. As Thomas asked, do people really even still use > frozen modules? I use frozen modules to load a filesystem driver into my bare-metal Python port (since there are no FS syscalls and thus I can't import the first python code from anywhere else). This may be something of a special case. :) I don't use __path__, though.. -- Torne Wuff [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60
On Thu, Nov 27 08 at 3:58:43PM +0100, Christian Heimes wrote: > A while ago I contacted Jukka Laurila from the Nokia developer board > about IEEE 754 support on S60 phones. The information from Jukka may be > useful for future reference. OK, I want to weigh in here, but first I need a lil disclaimer: I'm a Symbian core developer and theoretically in a position to fix this kind of thing, but I am not speaking in an official capacity and nothing here should be taken to represent Symbian or Nokia etc etc blah blah :) Also, I'm not quite a floating point expert, but have had to deal with various issues in the past, and wrote some of our hardware floating point support code, so the below is my best guesses. > We've been battling with some float problems recently as well in the > course of our 2.5 core porting. The principal problem has been imprecise > floating point formatting/parsing routines which lead to the unfortunate > case of not being able to roundtrip a Python float to string and back > bit-exactly. I've been trying to get to the bottom of that problem and > so far it seems like the root cause is a poorly written C library. The formatting/parsing routines for floats are not imprecise, they just don't print enough digits to make roundtripping work. We only print 15 digits, because that's the most digits we can guarantee to calculate accurately. Working out the 16th and 17th digits requires that you have a higher-than-double-precision intermediate representation, which is not guaranteed, see below. So, I'd like to suggest that "poorly written" is not true. :) > Though on the other hand, no one from Symbian is yet to confirm to me > that the software-emulated floating point routines correspond to > anything like IEEE 754. Most S60 devices lack floating point hardware. I think I might've actually been the one to receive these queries.. I did try to explain. We should be IEEE 754 compliant. We have a range of tests which attempt to prove this. If someone has a case demonstrating otherwise please let me know and I'll raise an issue. :) Floating point hardware makes it worse, though, not better: ARM's VFP floating point hardware has only single and double precision. Our software implementation uses 64 bit mantissas for intermediates, which is indeed enough to print 17 digits correctly, but on platforms where the VFP is enabled globally, there is no such higher intermediate precision and were we to try and print 17 digits some of them would be wrong. So, I'm not sure that it's actually possible for us to do better; maybe it is, maybe not. > The best guess is that the floating point support is IEEE 754'ish, with > imprecise formatting and parsing routines in the standard library. IEEE 754 doesn't include string formatting or parsing as far as I know, so I think this is irrelevant to whether we are compliant :) Does *any* standard actually promise that roundtripping will work, or is it just assumed? -- Torne Wuff [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60
On Thu, Nov 27 08 at 7:27:03PM +, Mark Dickinson wrote: > Many thanks for your input! No problem! I don't like hearing folks from Nokia implying that our code is rubbish :) > I think IEEE 754 is relevant. :-) Thanks for hunting down all that information! I'm in agreement: we should fix this so that it works for 17 digits. I've had a chat with our team's architect and it's not as awkward as I had assumed: the hardware floating point doesn't actually get in the way as the function in question only uses our software-implemented high precision real class, not float/double types. Whether our implementation is actually *correct* if you ask it for more digits is an interesting question, though. It might be already :) Are you aware of any compliance suite, test vectors, etc we could 'borrow' to verify our implementation? We would certainly like to verify this. I'm going to raise a defect for the binary<->decimal conversion issue, and see what we can do about sorting this out for future OS versions. -- Torne Wuff [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
