A can of worms... (does Python C code have a new C style?)
Hi all I'd like to know what the policy is on the source code indentation for C code in the interpreter. At the Need-for-Speed sprints, there was consensus that there is a "new" indentation for style for the Python C source files, with * indentation (emacs: c-basic-offset): 4 chars * no tabs (so tab-width does not matter) * 79 chars max for lines (I think) (Correct me if any of this is wrong.) I cannot find where this discussion comes from, PEP 7 seems to imply that the new style only applies to Python 3k. Is this correct? However, people were maintaining the existing styles when they were editing part of existing files (I setup emacs users with two c-styles, "python" and "python-new", so they could switch per-file), but using the new guidelines for new files. I look at the source code, and there is a bit of a mix of the two styles in some places. Is there a "grand plan" to convert all the code at once at some point? If not, how is it that these new guidelines are supposed to take effect? I could easily contribute to the vaccuuming here, by writing a script that will run emacs in batch mode on all the C code with the appropriate new style to do the following for each C file present: * re-indent the entire file according to the new guidelines * convert all the tabs to whitespace * delete trailing whitespace on all lines * remove those pesky CR if there are any * (anything else you'd like that's easily done from emacs?) The problem is that if someone was to check-in the result of this automation there would be a huge wave of complaints from merge conflicts for people who have a checkouts with lots of uncommitted changes. I don't see any painless way to do this. To ease the pain, however, it could be done at a fixed time, giving everyone a wide margin of chance to commit beforehand. In addition, should this be applied, we should probably create a Subversion hook that will automatically convert tabs to spaces, or fails the commit if the files don't comply. I realize this is potentially opening a can of worms, but on the one hand I'd like to know what's the low-down on the indentation, and on the other hand I won't spend a second on this if this is only going to lead to trouble. Then again, maybe I misunderstood and the new rules apply only to Python 3k, in which case, well, press delete and move on. cheers,
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 31 May 2006 07:02:02 -0400
"Martin Blais"
I'd like to know what the policy is on the source code indentation for C code in the interpreter. At the Need-for-Speed sprints, there was consensus that there is a "new" indentation for style for the Python C source files, with
* indentation (emacs: c-basic-offset): 4 chars * no tabs (so tab-width does not matter) * 79 chars max for lines (I think)
(Correct me if any of this is wrong.) I cannot find where this discussion comes from, PEP 7 seems to imply that the new style only applies to Python 3k. Is this correct?
AFAIK, yes it only applies to Py3K. There are no plans to re-indent the Python 2.x C code. Or maybe, there have been plans to do so for > 10 years and in Py3K those plans might finally come to fruition. :) BTW, A while back I think I posted a "py3k" cc-mode style for you X/Emacs hackers out there. It's based on the standard "python" style but changes c-basic-offset and indent-tabs-mode. Let me know if you can't find it in the archives. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iQCVAwUBRH2HvnEjvBPtnXfVAQJv/wQAhKBvh49xW59JgKv6tq9O/QvU/jvZJSPw qHMjOi55IGdFUG4zrSOH08U0VSkkM/mhoBgAqggNnsWMsFjtEu0NeOcroKIPBmLK RU1B4sw78RQFj/phEBpCvgObYRoI8lEVJYnXKFAp6yY9qGdJRGIRGhVX5nnBz/as 4BLr5tADpHo= =IFzC -----END PGP SIGNATURE-----
Martin Blais wrote:
Hi all
I'd like to know what the policy is on the source code indentation for C code in the interpreter. At the Need-for-Speed sprints, there was consensus that there is a "new" indentation for style for the Python C source files, with
* indentation (emacs: c-basic-offset): 4 chars * no tabs (so tab-width does not matter) * 79 chars max for lines (I think)
(Correct me if any of this is wrong.) I cannot find where this discussion comes from, PEP 7 seems to imply that the new style only applies to Python 3k. Is this correct?
The consensus at NFS was that it also applies to newly written C files. I did update the PEP, but that doesn't seem to have propagated to the web site yet.
However, people were maintaining the existing styles when they were editing part of existing files (I setup emacs users with two c-styles, "python" and "python-new", so they could switch per-file), but using the new guidelines for new files. I look at the source code, and there is a bit of a mix of the two styles in some places.
That's bad, but is the way the code was written and should not be changed for the sake of changing.
Is there a "grand plan" to convert all the code at once at some point? If not, how is it that these new guidelines are supposed to take effect?
AFAIK not before Python 3.0 since it would unnecessarily break, for instance, svn blame and make merging more difficult. [...]
In addition, should this be applied, we should probably create a Subversion hook that will automatically convert tabs to spaces, or fails the commit if the files don't comply.
For the future (=Py3k), I think this would be nice. Georg
I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type->tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type->tp_alloc(type, 0) also be used in the case of allocating complex subtypes? This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors. I can work around this by not calling the __new__ method for the base type but this is not consistent. Thanks for any feedback, -Travis
I wouldn't be surprised if this is a genuine bug; the complex type
doesn't get a lot of love from core developers.
Could you come up with a proposed fix, and a unit test showing that it
works (and that the old version doesn't)? (Maybe a good unit test
would require writing a custome C extension; in that case just show
some sample code.)
--Guido
On 5/31/06, Travis E. Oliphant
I'm curious about the difference between
float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c
The former uses type->tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator).
It seems like this is a bug. Shouldn't type->tp_alloc(type, 0) also be used in the case of allocating complex subtypes?
This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors.
I can work around this by not calling the __new__ method for the base type but this is not consistent.
Thanks for any feedback,
-Travis
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> (Maybe a good unit test would require writing a custome C Guido> extension; in that case just show some sample code.) Isn't that what Module/_testcapimodule.c is for? Skip
Guido van Rossum wrote:
I wouldn't be surprised if this is a genuine bug; the complex type doesn't get a lot of love from core developers.
Could you come up with a proposed fix, and a unit test showing that it works (and that the old version doesn't)? (Maybe a good unit test would require writing a custome C extension; in that case just show some sample code.)
Attached is a sample module that exposes the problem. The problem goes away by replacing op = PyType_GenericAlloc(type, 0); with op = type->tp_alloc(type, 0); in the function complex_subtype_from_c_complex in the file complexobject.c (about line #191). The problem with a unit test is that it might not fail. On my Linux system, it doesn't complain about the problem unless I first use strict pointer checking with export MALLOC_CHECK_=2 Then the code import bugtest a = bugtest.newcomplex(3.0) del a Aborts Valgrind also shows the error when running the simple code. It seems pretty clear to me that the subtype code should be calling the sub-types tp_alloc code instead of the generic one. Best regards, -Travis
participants (6)
-
Barry Warsaw -
Georg Brandl -
Guido van Rossum -
Martin Blais -
skip＠pobox.com -
Travis E. Oliphant