14.01.14 23:38, Raymond Hettinger написав(ла):
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou <solip...@pitrou.net
<mailto:solip...@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.
_______________________________________________
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
