Re: [Python-Dev] Should execv() call _run_exitfuncs()? If not, should _run_exitfuncs() be private?
Guido van Rossum writes: > Depending on the use for the exit function you might or might not want > it run at the occasion of exec*(). E.g. I imagine that in a typical > fork() + exec*() scenario, calling the exit functions in the child > process would be a mistake. > > So I don't think the hooks should be called by default. However you > are welcome to call the function (leading underscore and all) if it > helps in your case. Ok - got it. Thanks, everyone, for the clarification(s). ___ 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] Removing tp_compare?
On Sun, Feb 1, 2009 at 4:22 AM, Mark Dickinson wrote: > On Sat, Jan 31, 2009 at 9:28 PM, "Martin v. Löwis" wrote: > >> tp_reserved sounds fine. In 3.0.1, filling it with a function pointer >> should give no error, since that would be a binary-incompatible change. > > I'm not sure I understand you here. Are you saying that in your > opinion it is safe to change the type of tp_reserved > from (cmpfunc *) to some other (dummy) function pointer? Sounds like Martin is referring to your suggestion to raise an exception when initializing a type that has a non-NULL thing here. I agree with him. > I now realize (thanks to your message) that changing the type > to (void *) isn't entirely safe, since sizeof(void*) may be > different from sizeof(cmpfunc*) on some platforms. I don't think it matters on any platforms we care about. -- --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] Removing tp_compare?
On Sat, Jan 31, 2009 at 9:28 PM, "Martin v. Löwis" wrote: > tp_reserved sounds fine. In 3.0.1, filling it with a function pointer > should give no error, since that would be a binary-incompatible change. I'm not sure I understand you here. Are you saying that in your opinion it is safe to change the type of tp_reserved from (cmpfunc *) to some other (dummy) function pointer? I now realize (thanks to your message) that changing the type to (void *) isn't entirely safe, since sizeof(void*) may be different from sizeof(cmpfunc*) on some platforms. Mark ___ 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] Removing tp_compare?
On Sun, Feb 1, 2009 at 4:21 PM, Guido van Rossum wrote: > Sounds like Martin is referring to your suggestion to raise an > exception when initializing a type that has a non-NULL thing here. I > agree with him. Got it. Thank you. Mark ___ 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] Removing tp_compare?
Mark Dickinson wrote: > On Sat, Jan 31, 2009 at 9:28 PM, "Martin v. Löwis" wrote: > >> tp_reserved sounds fine. In 3.0.1, filling it with a function pointer >> should give no error, since that would be a binary-incompatible change. > > I'm not sure I understand you here. Are you saying that in your > opinion it is safe to change the type of tp_reserved > from (cmpfunc *) to some other (dummy) function pointer? No. I thought someone (you?) proposed that it should cause a runtime error if a type definitions fills the tp_compare slot. I say that 3.0.1 must not produce such an error. > I now realize (thanks to your message) that changing the type > to (void *) isn't entirely safe, since sizeof(void*) may be > different from sizeof(cmpfunc*) on some platforms. Do you know of a platform where this is actually the case? I wouldn't mind making that an #error (i.e. having it fail at compile time already). Regards, Martin ___ 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] Strange locale problem with Python 3
Hi While helping Brandon Rhodes to port PyEphem[1] to Python 3 we struggled over a strange locale-related problem on OS X. PyEphem is a library which can do astronomical computations like tracking the position of stars, planets and earth satellites relative to the earth's position. When testing out the Python 3 release of PyEphem I noticed that on my OS X laptop a lot of calculations were wrong (not completely wrong, but clearly not accurate) compared to Python 2.5. We (well mostly Brandon) were able to track down the problem to the TLE parser (TLE are data file containing the orbital elements of an object) which appears to read most values wrong with python 3. In fact it cut of the decimal parts of all floats (1.123232 got 1, etc). Manually setting LANG and LC_ALL to C solved the problem. It turns out that some parts of Python 3 got more locale dependent on some platforms. The only platform I am aware of is OS X, on Linux Python 3 appears to behave like Python 2.x did. In case of PyEphem the problem was in the C extension which got more locale dependent, for example atof() or scanf() with Python 3 now expected the german decimal-delimiter ',' instead of the '.' in floats (3.14 vs. 3,14). On the other hand the constructor of float still expects '.' all the time. But the built-in function strptime() honors locales with Python 3 and expects german week day. I've written a simple script and a simple C extension which illustrates the problem. Both the extension and the script run python 2.x and python 3, so you can easily compare the result while executing the script in different environments. I was only able to reproduce the problem on OS X (10.5) and using a german locale like "de_CH.UTF-8". When manually setting LC_ALL=C, the differences disappears. I can't imagine that his behavior was really intended, and I hope the test case helps you guys to identify/fix this problem. Download the test case from: http://github.com/retoo/py3k-locale-problem/tarball/master or get it using git: git://github.com/retoo/py3k-locale-problem.git You can use the following steps to build it: $ python2.5 setup.py build $ python3.0 setup.py build To run the tests with python 2.5, enter: $ (cd build/lib*-2.5; python2.5 py3k_locale_problem.py) ... for 3.0 ... $ (cd build/lib*-3.0; python3.0 py3k_locale_problem.py) In the file 'results.txt' you can see the output from my OS X system. Cheers, Reto Schüttel [1] http://rhodesmill.org/pyephem/ ___ 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] Strange locale problem with Python 3
On Sun, Feb 01, 2009, Reto Sch?ttel wrote: > > While helping Brandon Rhodes to port PyEphem[1] to Python 3 we > struggled over a strange locale-related problem on OS X. Please file a report at bugs.python.org -- that's the only way to ensure that this gets tracked. -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ 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] Removing tp_compare?
On Sun, Feb 1, 2009 at 6:03 PM, "Martin v. Löwis" wrote: > No. I thought someone (you?) proposed that it should cause a runtime > error if a type definitions fills the tp_compare slot. I say that > 3.0.1 must not produce such an error. Thanks. I'm with you now. I'll get rid of the relevant bit of code. > > [...] sizeof(void*) may be > > different from sizeof(cmpfunc*) on some platforms. > Do you know of a platform where this is actually the case? I don't, so if no-one else does either then there's probably little point worrying about it. The best reference I could find (besides the C standards themselves, and in particular section 6.3.2.3 of the C99 standard) was an ancient and short discussion on comp.std.c (starting June 21, 1998, subject "Q: void pointers and function pointers") where some of the posters claimed to have encountered such platforms. Mark ___ 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] Fwd: Partial function application 'from the right'
Nick Coghlan wrote: That won't work: ... = 1 File "", line 1 SyntaxError: can't assign to Ellipsis Well, I was trying to be funny and was under the impression that Python 3.0 had Unicode identifiers, but apparently it doesn't. (I used …, not ...) - Ludvig ___ 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] python 3.0, tp_compare not used for == test?
Hi, I have been writing a new C api that can build with both python 2.6 and 3.0
I found that when building with python 2.6, doing "a==b" between 2
different pyrna_struct_Type's would run tp_compare
But with python 3.0, "a==b" will always be false and tp_compare
function would not even run.
The only way to get it to run the tp_compare function was to do
"cmp(a, b)" however Id like to be able to use == still.
The only way I could get "a==b" to work in python 3.0 was to add a
tp_richcompare function which runs tp_compare with Py_CmpToRich()
anyway
Is this the intended behavior? - if so its important for external C
API's to be updated to support this.
Included the PyType below with some relevant details. I looked at
other Python 3.0 types but could not see why this would happen.
// snip,
// initialized with PyType_Ready
if( PyType_Ready( &pyrna_struct_Type ) < 0 )
return NULL;
// header definition for BPy_StructRNA
typedef struct {
PyObject_HEAD /* required python macro */
PointerRNA ptr;
int freeptr; /* needed in some cases if ptr.data is created on the
fly, free when deallocing */
} BPy_StructRNA;
// PyType
/*---BPy_StructRNA method
def--*/
PyTypeObject pyrna_struct_Type = {
PyVarObject_HEAD_INIT(NULL, 0)
"StructRNA",/* tp_name */
sizeof( BPy_StructRNA ),/* tp_basicsize */
0, /* tp_itemsize */
/* methods */
( destructor ) pyrna_struct_dealloc,/* tp_dealloc */
NULL, /* printfunc tp_print; */
NULL, /* getattrfunc
tp_getattr; */
NULL, /* setattrfunc
tp_setattr; */
( cmpfunc ) pyrna_struct_compare, /* tp_compare */
( reprfunc ) pyrna_struct_repr, /* tp_repr */
/* Method suites for standard classes */
NULL, /* PyNumberMethods *tp_as_number; */
NULL, /* PySequenceMethods
*tp_as_sequence; */
NULL, /* PyMappingMethods
*tp_as_mapping; */
/* More standard operations (here for binary compatibility) */
( hashfunc )pyrna_struct_hash, /* hashfunc tp_hash; */
NULL, /* ternaryfunc tp_call;
*/
NULL, /* reprfunc tp_str; */
( getattrofunc ) pyrna_struct_getattro, /* getattrofunc tp_getattro; */
( setattrofunc ) pyrna_struct_setattro, /* setattrofunc tp_setattro; */
/* Functions to access object as input/output buffer */
NULL, /* PyBufferProcs *tp_as_buffer; */
/*** Flags to define presence of optional/expanded features ***/
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /* long tp_flags; */
NULL, /* char *tp_doc;
Documentation string */
/*** Assigned meaning in release 2.0 ***/
/* call function for all accessible objects */
NULL, /* traverseproc tp_traverse; */
/* delete references to contained objects */
NULL, /* inquiry tp_clear; */
/*** Assigned meaning in release 2.1 ***/
/*** rich comparisons ***/
(richcmpfunc)pyrna_struct_richcmp, /* richcmpfunc tp_richcompare;
*/
/*** weak reference enabler ***/
0, /* long tp_weaklistoffset; */
/*** Added in release 2.2 ***/
/* Iterators */
NULL, /* getiterfunc tp_iter; */
NULL, /* iternextfunc tp_iternext; */
/*** Attribute descriptor and subclassing stuff ***/
pyrna_struct_methods, /* struct PyMethodDef *tp_methods; */
NULL, /* struct PyMemberDef *tp_members; */
NULL, /* struct PyGetSetDef
*tp_getset; */
NULL, /* struct _typeobject *tp_base; */
NULL, /* PyObject *tp_dict; */
NULL, /* descrgetfunc tp_descr_get; */
NULL, /* descrsetfunc tp_descr_set; */
0, /* long tp_dictoffset; */
NULL, /* initproc tp_init; */
NULL, /* allocfunc tp_alloc; */
pyrna_struct_new, /* newfunc tp_new; */
/* Low-level free-memory routine */
NULL, /* freefunc tp_free; */
/* For PyObject_IS_GC */
NULL, /* inquiry tp_is_gc; */
NULL, /* PyObject *tp_bases; */
/* method resolution order */
NULL, /* PyObject *tp
Re: [Python-Dev] python 3.0, tp_compare not used for == test?
Campbell Barton wrote: Hi, I have been writing a new C api that can build with both python 2.6 and 3.0 Questions about using current releases should be directed to the python-list (or comp.lang.python or gmane.comp.python.general), not python-dev, which is for development of future releases. I found that when building with python 2.6, doing "a==b" between 2 different pyrna_struct_Type's would run tp_compare But with python 3.0, "a==b" will always be false and tp_compare function would not even run. The only way to get it to run the tp_compare function was to do "cmp(a, b)" however Id like to be able to use == still. In 3.0, the build-in cmp() should have been removed and will be for 3.0.1. Do not use it. I believe the tp_compare slot should not be used either. It will become reserved. It will not be removed only because that would change the binary layout. So use rich comparisons. ___ 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] Removing tp_compare?
On Sun, Feb 1, 2009 at 21:33, "Mark Dickinson" wrote: > On Sun, Feb 1, 2009 at 6:03 PM, "Martin v. Löwis" wrote: > > [...] sizeof(void*) may be > > different from sizeof(cmpfunc*) on some platforms. > Do you know of a platform where this is actually the case? > I don't, so if no-one else does either then there's probably little > point worrying about it. The best reference I could find (besides > the C standards themselves, and in particular section 6.3.2.3 of > the C99 standard) was an ancient and short discussion on > comp.std.c (starting June 21, 1998, subject > "Q: void pointers and function pointers") where some of the > posters claimed to have encountered such platforms. I do know of at least one such platform. Sure it's a bit dated, and probably not relevant for the python development, but definitely not exotic or rare! Don't you rememeber the PC:s in the late 1980th? It was based on Intel's 80286-processor, and Microsoft's C compiler supported three or four different memory models, called things like "TINY", "SMALL", "LARGE", and "HUGE". Most of these memory models had different sized data and function pointers. Niklas Norrthon ___ 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
