[Python-Dev] Changing Clinic's output

Serhiy Storchaka storchaka at gmail.com
Tue Jan 14 23:41:25 CET 2014


14.01.14 23:38, Raymond Hettinger написав(ла):
> On Jan 14, 2014, at 9:12 PM, Antoine Pitrou <solipsis at pitrou.net
> <mailto:solipsis at pitrou.net>> wrote:
>
>> I'm +1 on the sidefile approach. +0 on the various buffer approaches.
>> -0.5 on the current "sprinkled everywhere" approach.
>
> I concur with Antoine except that I'm a full -1 on commingling
> generated code with hand edited code.   Sprinked everywhere
> interferes with my ability to grok the code.  It interferes with
> code navigation.  And it creates a greater risk of accidentally
> editing the generated code.

As expected I'm same as Raymond. +1 on the sidefile approach, -1 on the 
current "sprinkled everywhere" approach, and about 0 on the various 
buffer approaches.

Yet one nitpick. I prefer to have a sidefile with some unique suffix 
(e.g. .clinic) at the end of file name rather than in the middle. 
_pickle.c.clinic is better then _pickle.clinic.c (even .c in middle is 
not needed, it can be _pickle.clinic).

My reasons:

1. I very very often use global search in sources. It's my way of 
navigation and it's my way of investigations. I don't want to get false 
results in generated files. And it is much easy to specify mask '*.[ch]' 
or '*.c,*.h' (depending on tool) than specify a mask and negative mask. 
The latter is even not always possible, I can write cumbersome 
expression for the find command, but Midnight Commander doesn't support 
negative masks at all (and perhaps your favorite IDE doesn't support 
them too).

2. I'm not use any IDE, but if you use, it can be important for you. If 
IDE shows sources tree, unlikely you want to see generated *.clinic.c 
files in them. This will increase the list of sources almost twice.

3. Pathname expansion works better with unique endings, You can open all 
Modules/_io/*.c files, but unlikely you so interested in *.clinic.c 
files which are matched by former pattern.




More information about the Python-Dev mailing list