On Mon, Jan 6, 2014 at 10:17 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Mon, 6 Jan 2014 00:25:53 +0100 > Stefan Krah <ste...@bytereef.org> wrote: >> Nick Coghlan <ncogh...@gmail.com> wrote: >> > > I had that working at one point. Guido said no, keep it all in one file. >> > > I'm flexible but first you'd have to convince him. >> > >> > It's also not something we're stuck with forever - we can start with it >> > inline >> > (which has the advantage of keeping all the code in the same place), and >> > later >> > move to having the helpers in a separate file included from the >> > implementation >> > file if we decide it makes sense to do so. >> >> If we move big chunks of code around twice, I guess "hg blame" will break >> twice, too. That is another thing worth considering. > > Breaking on generated code doesn't sound very annoying, though.
That depends on how stressed you are when you are trying to use hg blame to figure out where a certain breakage was introduced, when and by whom. >> I agree with Serhiy, but that is probably known at this point. :) > > I agree with Serhiy and you too. Clinic's current output makes C files > more tedious to read, and I'm not really willing to participate in the > "conversion derby" because of that. What were Guido's arguments? > > Also, see http://bugs.python.org/issue19723 I added a hopefully useful suggestion there; ISTM the situation can easily be improved by changing the wording of the magic comments. I'm not yet convinced that the generated code is better off in separate files nor why that is considered such a big deal. And how would you prevent the generated functions from becoming externally visible? As long as they are in the same file they can be static. (I'm not a fan of #include to stitch files together.) -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com