I favor a dual-mode approach. I think the existing behavior is best for the conversion of existing modules, because it's easy to interactively verify the generated code. Once that's done, long-term maintenance definitely favors a more centralized format.
+1 _pickle.original.c /* used only during conversion of existing modules */ +0 _pickle.using-buffer.c +1 _pickle.using-modified-buffer.c -1 _pickle.using-multiple-buffers.c NaN _pickle.using-sidefile.c /* not enough experience with it */ Pondering it this afternoon, I thought of a configuration that minimizes both code churn and readability impact: two buffers. One at the top containing forward declarations and defines (an inline header file if you like), and the rest of the autogenerated code at the bottom. It's not obvious that AC currently supports this configuration, or backtracking of any kind. Nonetheless: +1 _pickle.using-two-buffers.c On Tue, Jan 14, 2014 at 12:22 PM, Larry Hastings <la...@hastings.org> wrote: > > On 01/11/2014 07:35 PM, Larry Hastings wrote: > > > On 01/08/2014 07:08 AM, Barry Warsaw wrote: > > How hard would it be to put together some sample branches that provide > concrete examples of the various options? > > My own opinion could easily be influenced by having some hands-on time with > actual code, and I suspect even Guido could be influenced if he could pull > some things up in his editor and take a look around. > > > I've uploaded a prototype here: > > https://bitbucket.org/larry/python-clinic-buffer > > > > I have now received exactly zero feedback about the prototype, which > suggests people aren't using it. In an attempt to jump-start this > conversation, I've created a new repository containing the "concrete > examples of the various options" that Barry proposed above. You may find > it here: > > https://bitbucket.org/larry/clinic-buffer-samples/src > > In it I converted Modules/_pickle.c four different ways. There's a > README, please read it. > > People who want to change how Clinic writes its output: this is your big > chance. Comment on these samples, or produce your own counterexamples, or > something. If you can enough people on your side maybe Clinic will > change. If there is no further debate on this topic, nothing will happen > and Clinic will not change. > > > */arry* > > _______________________________________________ > 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/rmsr%40lab.net > >
_______________________________________________ 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
