[Python-Dev] Pondering some changes to python.c...

[Guido van Rossum]

[me]
> >This sounds awfully ill-defined.  Do you know how this is accomplished
> >on various Unix variants besides Linux?  What if there's some platform

[Sean]
> I got this mechanism by examining sendamil (which uses the ps output to
> display various states).  Sendmail includes 6 mechanisms for setting the
> process name:
> 
>    pstat()
>    psstrings (a struct you can set argc/argv through)
>    sysmips()
>    Apparently a SCO-specific mechanism which directly accesses kernel memory
>    Overwriting the original argv[0]
>    Setting argv[0] to point to a new buffer
> 
> I have no idea how "published" one should consider these interfaces...

Oh, yuck.  Bah.  Please go away. :-)

> >guaranteed to work as Linux is upgraded?  I'd hate to hear the
> >complaints from users when they upgrade their kernel and find that it
> >breaks Python, despite ABI compatibility promises.
> 
> Indeed.  It's small consolation that it would also break sendmail...
> 
> >What code would have a hold of argv, except main() which just calls
> >Py_Main()?
> 
> In the normal python interpreter, nothing.  My concern was more with a
> system that embeddeds Python...  Which is why I'd lean more towards an
> implementation which required an explicit initialization call to enable.
> That would signal Python that the embedder knew of and condoned the
> modification of the process string.
> 
> I'm torn between making it a build-time option in the SRPM (defaulting to
> disabled) and just dropping it as "too contentious".  Sadly, the least
> objectional way to make it happen is probably making it os.pstat() and
> wrapping the pstat() system call on the platforms that have it.  "Sadly"
> because Linux doesn't seem to be one of those platforms...

Let's just drop it.

--Guido van Rossum (home page: http://www.python.org/~guido/)