python code in argument clinic annotations
The whole discussion of whether clinic should write its output right in the source file (buffered or not), or in a separate sidefile, started because we currently cannot run the clinic during the build process, since it’s written in python. But what if, at some point, someone implements the Tools/clinic.py in pure C, so that integrating it directly in the build process will be possible? In this case, the question is — should we use python code in the argument clinic DSL? If we keep it strictly declarative, then, at least, we’ll have this possibility in the future. -- Yury Selivanov
On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
The whole discussion of whether clinic should write its output right in the source file (buffered or not), or in a separate sidefile, started because we currently cannot run the clinic during the build process, since it’s written in python.
But that's why the output is checked in. It's the same with the parser IIRC. (And yes, there's a bootstrap issue -- but that's solved by using an older Python version.)
But what if, at some point, someone implements the Tools/clinic.py in pure C, so that integrating it directly in the build process will be possible? In this case, the question is — should we use python code in the argument clinic DSL?
If we keep it strictly declarative, then, at least, we’ll have this possibility in the future.
Sounds like a pretty unlikely scenario. Why would you implement clinic in C? -- --Guido van Rossum (python.org/~guido)
Guido, On Thursday, January 16, 2014, Guido van Rossum <guido@python.org> wrote:
On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov <yselivanov.ml@gmail.com <javascript:;>> wrote:
The whole discussion of whether clinic should write its output right in the source file (buffered or not), or in a separate sidefile, started because we currently cannot run the clinic during the build process, since it’s written in python.
But that's why the output is checked in. It's the same with the parser IIRC. (And yes, there's a bootstrap issue -- but that's solved by using an older Python version.)
But what if, at some point, someone implements the Tools/clinic.py in pure C, so that integrating it directly in the build process will be possible? In this case, the question is — should we use python code in the argument clinic DSL?
If we keep it strictly declarative, then, at least, we’ll have this possibility in the future.
Sounds like a pretty unlikely scenario. Why would you implement clinic in C?
Unlikely, yes. There is just one reason for having it in C -- having it integrated in the build process, so that the generated output/sidefiles are not in the repository. Yury
On 01/16/2014 11:46 AM, Yury Selivanov wrote:
There is just one reason for having it in C -- having it integrated in the build process, so that the generated output/sidefiles are not in the repository.
It's possible to integrate Argument Clinic into the build process without rewriting it in C. We could write a small C program that looked on your path for a suitable Python 3 interpreter, and ran Tools/clinic/clinic.py under that interpreter. If it failed to find such an interpreter it could print a warning message. Alternatively, we could add a checksum for the Clinic *input* block to the output somewhere. This would give the C tool the ability to check and see if the Clinic input had changed, and only bother to run clinic.py if it had. However, the generated output is still going to be checked in to the repository regardless. //arry/
Larry, On January 16, 2014 at 2:58:02 PM, Larry Hastings (larry@hastings.org) wrote:
However, the generated output is still going to be checked in to the repository regardless.
OK. Since it looks like it’s 100% accepted to commit it to the repo, then my question is moot. And again, Larry, kudos for pulling the AC off. - Yury
Am 16.01.2014 20:46, schrieb Yury Selivanov:
Guido,
On Thursday, January 16, 2014, Guido van Rossum <guido@python.org <mailto:guido@python.org>> wrote:
On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov <yselivanov.ml@gmail.com <javascript:;>> wrote: > The whole discussion of whether clinic should write its output > right in the source file (buffered or not), or in a separate sidefile, > started because we currently cannot run the clinic during the build > process, since it’s written in python.
But that's why the output is checked in. It's the same with the parser IIRC. (And yes, there's a bootstrap issue -- but that's solved by using an older Python version.)
> But what if, at some point, someone implements the Tools/clinic.py in > pure C, so that integrating it directly in the build process will be > possible? In this case, the question is — should we use python code > in the argument clinic DSL? > > If we keep it strictly declarative, then, at least, we’ll have this > possibility in the future.
Sounds like a pretty unlikely scenario. Why would you implement clinic in C?
Unlikely, yes.
About as unlikely as switching the Python sources to C++ and using templates to implement a Clinic-like DSL :) Georg
On 01/16/2014 11:36 AM, Guido van Rossum wrote:
On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
If we keep it strictly declarative, then, at least, we’ll have this possibility in the future. Sounds like a pretty unlikely scenario. Why would you implement clinic in C?
We'll never reimplement Argument Clinic in C. I could list many reasons for this. Suffice to say, I'm not doing it, and I doubt anyone else would ever step up to the plate and try it. And, "form follows function". It's a bad idea to limit Argument Clinic's features today based on what might be inconvenient someday in some hypothetical rewrite in C. Argument Clinic should be maximally useful, right now. //arry/
participants (4)
-
Georg Brandl -
Guido van Rossum -
Larry Hastings -
Yury Selivanov