Re: [gentoo-dev] initscripts in python

[merv]

Yep, I agree on your two cons:

->a new interpreter would have to reach stable pretty quick since we 
are mucking around with pretty system-vital stuff here (and since we 
are using python syntax [in this hypothetical instance] to message to 
the kernel, a new interpreter and a fairly fundamental re-write of the 
shell may be the end result, though it might be politic not to revise what 
was not necessary to revise)

->the structure of the interpreter and ways in which it parse shell syntax 
of a python dialect would have to be addressed with the aim of 
minimising overhead on one-liner files, in particular (small scripts incur 
overhead, unavoidably, at least conventionally, but lots of small 
python-interpreted scripts might have real potential for runtime bloat)

About your two mitigating factors:  indeed, python seems to be 
evolving as a native gentoo language (perhaps this is a bit overstating 
the point, given that python is built on C APIs, but consider that portage 
is a central characteristic and feature of gentoo and that the portage 
tree is a testimony to the practical usefulness and potential of python) 
so to weave python or python-dialect syntax into a "system-boot 
interpreter" would be a natural extension of its role in gentoo and, if 
optimised for that purpose at that point, perhaps even a fast, efficient 
and inexpensive alternative.

[Maybe it is worth saying at this point that I am trying very deliberately 
to drive a line between python the language as it is and python-
language characteristics, such as its clean syntax, it "everything is an 
object" approach to life and so on which make it very attractive for 
"collective" development where code-readability and recycleability 
really begin to matter.  I am not suggesting, at this point, a wholesale 
transplant of the python language to sh but ways of building-in some of 
its features or characteristics to ADD TO sh, to be an addition, rather 
than replace sh].

On the issue you raise in your second mitigating factor, a kind of 
runtime boot-failover could be one example of the things made 
possible by introducing a more "extensible" shell.

Just to note: i envisage several levels of control or options.  There 
would, perhaps, be an initial build-time option to include python as a 
part of an "actively extensible" shell. sh would be default and required.  
python could then be toggled on and off at any time during by the use 
of command line switches or arguments passed with shell commands. 
additionally, optimisation switches could be passed as arguments to 
shell commands, or in script files, that enable the python shell syntax 
to behave exactly as required in given conditions or environments. For 
example, (and these lame suggestions are only for illustrating my 
point):

pye -a			to activate a python-shell environment
pye -k			to kill it and return to sh
pye -a -psh		to activate a mixed sh/python shell environment
pye -k  psh		to kill the mixed environment and return to sh
pye -k  psh -p		to kill the mixed environment but allow python 
    shell to persist 
pye -a -swoff		to activate the python shell environment 
    (when swap off) except when swap is activated 
    and performance might be an issue (if the 
    python shell environment proved to have 
    performance issues)

etc etc etc...you see my point

of course, the python shell environment could be invoked and killed in 
scripts in similar ways.

maybe we would in such cases be faced with the infinitive question of 
whether to trade performance for functionality, vice versa, or whether 
the trade-off in itself was necessary

the end result would be a new way to think of and use the shell

but now i pontificate :)

On 16 Apr 2003 at 16:54, Justin Whitney wrote:

> Thanks for the arguments thus far.
>
> So added to the cons list is:
>
> *addition of newer less-tested interpreter could add instability
> *very small/short scripts incur overhead
>
> Here are two mitigating arguments to counter the first statement.
>
> First - a separate, stable build of python could be used as the
> system-boot interpreter.  it might make sense to statically link it and
> so forth to lower dependencies... perhaps even to optimize it in some
> respects, for its task.
>
> Second, a shell script like the runscript.sh that is already used could
> be used to launch the interpreter and check for a runtime failure.  On
> failure it could launch the .sh version of the bootscript.  This means
> keeping two copies of the shellscripts obviously (which wouldn't be a
> bad idea anyway...)  this would at least have the benefit of salvaging
> the boot...
>
> As for the overhead problem with very small scripts, I don't see that
> going away... in fact converting such scripts would be a waste of time
> in the first place, because it doesn't make use of any of the advantages
> proposed by the change.  It would make more sense to set up the boot
> process to be able to run both kinds so you don't waste your time.
>
> --Justin
>
>
> --
> gentoo-dev@g.o mailing list
>


--
Merv Hammer
mailto: merv@×××××××××××××.cy

--
gentoo-dev@g.o mailing list