Mailing List Archive

1 2  View All
Re: Making PY_SSIZE_T_CLEAN not mandatory. [ In reply to ]
Hi,

I'm afraid we are talking past each other. In my case, the applications
are either part of my Python-based work setup, which needs to be rebuilt
anyway in the very infrequent occurrence of a major Python upgrade (I
could get away with using the system python for that on a "stable" distro).

Or they are installed using my distro's package manager, which takes
care of upgrading dependent packages together. This is the classical
"DLL hell" problem, right? Or is there some Python specificity that I
don't get?

Cheers,
Baptiste

Le 21/06/2021 à 20:20, Guido van Rossum a écrit :
> 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.
>
> On Mon, Jun 21, 2021 at 2:46 AM Baptiste Carvello
> <devel2021@baptiste-carvello.net
> <mailto:devel2021@baptiste-carvello.net>> 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/
> [2] https://docs.enthought.com/mayavi/mayavi/
> [3] https://github.com/snare/voltron
>
> > On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello
> > <devel2021@baptiste-carvello.net
> <mailto:devel2021@baptiste-carvello.net>
> > <mailto:devel2021@baptiste-carvello.net
> <mailto:devel2021@baptiste-carvello.net>>> 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 -- python-dev@python.org
> <mailto:python-dev@python.org>
> >     <mailto:python-dev@python.org <mailto:python-dev@python.org>>
> >     To unsubscribe send an email to python-dev-leave@python.org
> <mailto:python-dev-leave@python.org>
> >     <mailto:python-dev-leave@python.org
> <mailto:python-dev-leave@python.org>>
> >     https://mail.python.org/mailman3/lists/python-dev.python.org/
> >     Message archived at
> >   
>  https://mail.python.org/archives/list/python-dev@python.org/message/PPKL7466BIG6DPCUIJURLE5ZGFNHBNSM/
> >     Code of Conduct: http://python.org/psf/codeofconduct/
> >
> > --
> > --Guido (mobile)
> >
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> <mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-leave@python.org
> <mailto:python-dev-leave@python.org>
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/KP3SE6UWSV3VDCJOWCXUZIBPDWFJHRLU/
> Code of Conduct: 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 -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FG44N6RL5CT5O3XQ6UV6LBLUCET7IF6I/
Code of Conduct: http://python.org/psf/codeofconduct/

1 2  View All