[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021年6月22日 02:02:41 -0700

On 21. 06. 21 20:20, Guido van Rossum wrote:
Okay, I think your evidence can then be discounted. Really, any app that relies on the publicly installed Python runs a serious risk of breaking when that Python gets updated, regardless of whether the ABI changes or not.
Unfortunately, this includes scripts for any extensible software (Mayavi, GIMP, etc) -- even if Python is bundled with that software, upgrading the software risks breaking the scripts.
On Mon, Jun 21, 2021 at 2:46 AM Baptiste Carvello <[email protected] <mailto:[email protected]>> wrote:
 Hi,
 Le 18/06/2021 à 21:00, Guido van Rossum a écrit :
 > Can you elaborate on that use case? Which two applications are you
 > thinking of, and what was your goal in driving them? This sounds
 > interesting but I haven’t encountered this myself.
 Well, I'm not sure the case I was thinking of is still relevant to
 anything: that was plotting 3D crystal models using crystallography
 library CCTBX [1] and visualization application Mayavi [2], some 15-20
 years ago. BTW, I misremembered a bit: only CCTBX insisted on using a
 vendored python ("libtbx.python"), Mayavi used the system python.
 Anyway, it was more pain to make Mayavi use libtbx.python, than to make
 CCTBX work with the system python.
 Also, I must admit that even applications embedding the system python
 can have some limitations. For example, GIMP and GDB can execute python
 scripts, but their API can't be "imported" from the outside. Which means
 no arguments passed to the script over the command line ("sys.argv"), no
 venvs, no REPL. But at least you can install additional packages (pip /
 distro package manager) and limitations can be more or less hacked
 around. For a sophisticated example, the debugger extension Voltron [3]
 provides REPL access to GDB objects over a client-server connexion.
 Cheers,
 Baptiste
 [1] https://cci.lbl.gov/docs/cctbx/ <https://cci.lbl.gov/docs/cctbx/>
 [2] https://docs.enthought.com/mayavi/mayavi/
 <https://docs.enthought.com/mayavi/mayavi/>
 [3] https://github.com/snare/voltron <https://github.com/snare/voltron>
 > On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello
 > <[email protected]
 <mailto:[email protected]>
 > <mailto:[email protected]
 <mailto:[email protected]>>> wrote:
 >
 >   Le 18/06/2021 à 08:50, Paul Moore a écrit :
 >   >
 >   > IMO it doesn't. However for certain applications (the sort
 of thing I
 >   > was referring to) - where the user is writing their own
 scripts and
 >   > the embedding API is used merely to expose an interface to
 the Python
 >   > language, dynamically linking to whatever version of Python
 the user
 >   > has installed can be precisely the right thing to do - the
 user gets
 >   > access to the version of the language they expect, the
 installed
 >   > packages they expect to see, etc.
 >
 >   As a user, I second this. When trying to drive applications
 from the
 >   outside (as opposed to extending them through plugins), it is
 annoying
 >   when two applications won't work together because each one
 insists on
 >   using its own vendored python.
 >
 >   Of course, there are often real blockers, such as
 incompatible event
 >   loops. But not always...
 >
 >   Cheers,
 >   Baptiste
 >   _______________________________________________
 >   Python-Dev mailing list -- [email protected]
 <mailto:[email protected]>
 >   <mailto:[email protected] <mailto:[email protected]>>
 >   To unsubscribe send an email to [email protected]
 <mailto:[email protected]>
 >   <mailto:[email protected]
 <mailto:[email protected]>>
 > https://mail.python.org/mailman3/lists/python-dev.python.org/
 <https://mail.python.org/mailman3/lists/python-dev.python.org/>
 >   Message archived at
 >
 
https://mail.python.org/archives/list/[email protected]/message/PPKL7466BIG6DPCUIJURLE5ZGFNHBNSM/
 
<https://mail.python.org/archives/list/[email protected]/message/PPKL7466BIG6DPCUIJURLE5ZGFNHBNSM/>
 >   Code of Conduct: http://python.org/psf/codeofconduct/
 <http://python.org/psf/codeofconduct/>
 >
 > --
 > --Guido (mobile)
 >
 _______________________________________________
 Python-Dev mailing list -- [email protected]
 <mailto:[email protected]>
 To unsubscribe send an email to [email protected]
 <mailto:[email protected]>
 https://mail.python.org/mailman3/lists/python-dev.python.org/
 <https://mail.python.org/mailman3/lists/python-dev.python.org/>
 Message archived at
 
https://mail.python.org/archives/list/[email protected]/message/KP3SE6UWSV3VDCJOWCXUZIBPDWFJHRLU/
 
<https://mail.python.org/archives/list/[email protected]/message/KP3SE6UWSV3VDCJOWCXUZIBPDWFJHRLU/>
 Code of Conduct: http://python.org/psf/codeofconduct/
 <http://python.org/psf/codeofconduct/>
--
--Guido van Rossum (python.org/~guido <http://python.org/~guido>)
/Pronouns: he/him //(why is my pronoun here?)/ <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GC6PMZP3CI5TAZTXJ67GGEUDRZ4IZ7OJ/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/37FUSJCCQGONCCFSCJFXCXGYICZ7HXMJ/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to