Re: [Python-Dev] Removing tp_compare?
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. I don't think this is factually correct: - tiny, small: code and data each 16 bit - large, huge: code and data each 32 bit - medium: code 32 bit, data 16 bit - compact: code 16 bit, data 32 bit So most of the memory models (66%) have same-sized data and function pointers, only few of them (33%) have them differently-sized. In any case, I don't think Python supports 8086 segmented mode in any reasonable way today. Regards, Martin ___ 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] Removing tp_compare?
On Sun, Feb 1, 2009 at 4:22 AM, Mark Dickinson dicki...@gmail.com wrote: On Sat, Jan 31, 2009 at 9:28 PM, Martin v. Löwis mar...@v.loewis.de 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 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] Removing tp_compare?
On Sat, Jan 31, 2009 at 9:28 PM, Martin v. Löwis mar...@v.loewis.de 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 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] Removing tp_compare?
On Sun, Feb 1, 2009 at 4:21 PM, Guido van Rossum gu...@python.org 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 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] Removing tp_compare?
Mark Dickinson wrote: On Sat, Jan 31, 2009 at 9:28 PM, Martin v. Löwis mar...@v.loewis.de 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 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] Removing tp_compare?
On Sun, Feb 1, 2009 at 6:03 PM, Martin v. Löwis mar...@v.loewis.de 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 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] Removing tp_compare?
On Sun, Feb 1, 2009 at 21:33, Mark Dickinson dicki...@gmail.com wrote: On Sun, Feb 1, 2009 at 6:03 PM, Martin v. Löwis mar...@v.loewis.de 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 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
[Python-Dev] Removing tp_compare?
Here's a question (actually, three questions) for python-dev that came up in the issue 1717 (removing cmp) discussion. Once the cmp removal is complete, the type object's tp_compare slot will no longer be used. The current plan is to rename it to tp_reserved, change its type to (void *), and raise TypeError when initializing any type that attempts to put something nonzero into that slot. But another possibility would be to remove it entirely. So... Questions: (1) Is it desirable to remove tp_compare entirely, instead of just renaming it? (2) If so, for which Python version should that removal take place? 3.0.1? 3.1.0? 4.0? and the all-important bikeshed question: (3) In the meantime, what should the renamed slot be called? tp_reserved? In the issue 1717 discussion, Raymond suggested tp_deprecated_compare. Any thoughts? My own opinion is that it really doesn't matter that much if the slot is left in; it's just a little annoying to have such backwards-compatibility baggage already present in the shiny new 3.0 series. A little like finding a big scratch on your brand-new bright yellow Hummer H3. Or not. N.B. The same questions apply to nb_reserved (which used to be nb_long) in the PyNumberMethods structure. Mark ___ 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] Removing tp_compare?
On Sat, Jan 31, 2009 at 3:07 PM, Mark Dickinson dicki...@gmail.com wrote: Once the cmp removal is complete, the type object's tp_compare slot will no longer be used. The current plan is to rename it to tp_reserved, change its type to (void *), and raise TypeError when initializing any type that attempts to put something nonzero into that slot. But another possibility would be to remove it entirely. So... I think we should keep as tp_reserved in 3.0.1. In 3.1, as I mentioned in the issue, I'd like to reuse it as a slot for __bytes__. Confusion could be avoided still raising a TypeError for a non-null tp_reserved slot unless the type has Py_TPFLAGS_HAVE_BYTES flag set. After a while, we could just make it default. N.B. The same questions apply to nb_reserved (which used to be nb_long) in the PyNumberMethods structure. IMO, it's fine to keep them around, just in case. -- Regards, Benjamin ___ 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] Removing tp_compare?
(1) Is it desirable to remove tp_compare entirely, instead of just renaming it? No. (2) If so, for which Python version should that removal take place? 3.0.1? 3.1.0? 4.0? If it is removed, it definitely shouldn't be removed in 3.0.1; that would be a binary-incompatible change. (3) In the meantime, what should the renamed slot be called? tp_reserved? In the issue 1717 discussion, Raymond suggested tp_deprecated_compare. 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. Any thoughts? My own opinion is that it really doesn't matter that much if the slot is left in; it's just a little annoying to have such backwards-compatibility baggage already present in the shiny new 3.0 series. A little like finding a big scratch on your brand-new bright yellow Hummer H3. Or not. Well, there is also PY_SSIZE_T_CLEAN. I asked before 3.0, and was told that it was too late to remove it. Regards, Martin ___ 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] Removing tp_compare?
Martin v. Löwis martin at v.loewis.de writes: Any thoughts? My own opinion is that it really doesn't matter that much if the slot is left in; it's just a little annoying to have such backwards-compatibility baggage already present in the shiny new 3.0 series. A little like finding a big scratch on your brand-new bright yellow Hummer H3. Or not. Well, there is also PY_SSIZE_T_CLEAN. I asked before 3.0, and was told that it was too late to remove it. Are all modules PY_SSIZE_T_CLEAN? Last I looked, _ssl.c still used int or long in various places instead of Py_ssize_t. Regards Antoine. ___ 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] Removing tp_compare?
Are all modules PY_SSIZE_T_CLEAN? Last I looked, _ssl.c still used int or long in various places instead of Py_ssize_t. That's probably still the case. Regards, Martin ___ 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] Removing tp_compare?
Antoine Pitrou solip...@pitrou.net wrote: Martin v. Löwis martin at v.loewis.de writes: Any thoughts? My own opinion is that it really doesn't matter that much if the slot is left in; it's just a little annoying to have such backwards-compatibility baggage already present in the shiny new 3.0 series. A little like finding a big scratch on your brand-new bright yellow Hummer H3. Or not. Well, there is also PY_SSIZE_T_CLEAN. I asked before 3.0, and was told that it was too late to remove it. Are all modules PY_SSIZE_T_CLEAN? Last I looked, _ssl.c still used int or long in various places instead of Py_ssize_t. _ssl.c does indeed use int or long in various places. I'm not sure how far it can go with Py_ssize_t -- is OpenSSL 64-bit clean? Bill ___ 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] Removing tp_compare?
Bill Janssen janssen at parc.com writes: is OpenSSL 64-bit clean? I'm afraid I'm completely incompetent on this subject...! Regards Antoine. ___ 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] Removing tp_compare?
_ssl.c does indeed use int or long in various places. I'm not sure how far it can go with Py_ssize_t -- is OpenSSL 64-bit clean? That's irrelevant for the issue at hand (PY_SSIZE_T_CLEAN). What matters is that s# etc converters output Py_ssize_t (unless in deprecated compatibility mode); if you think you then need to truncate to 32 bits, there should be explicit code that tests for truncation and raises a Python exception if appropriate. Regards, Martin ___ 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
