What about just adding the -I (isolated mode) flag to the #! line of
installed scripts?
I was actually surprised this is not already done for the Python scripts in
/use/bin on my Ubuntu box.
Stephan
Op 5 jun. 2017 02:52 schreef "Mike Miller" :
> I'd like to throw some cold water on this one, fo
Stephan Houben wrote:
What about just adding the -I (isolated mode) flag to the #! line of
installed scripts?
Not all unix systems support passing extra arguments on a #! line.
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mai
What about doing it on the systems which *do* support it?
(Which probably covers 99% of the installed base...)
Stephan
Op 5 jun. 2017 11:59 schreef "Greg Ewing" :
> Stephan Houben wrote:
>
>> What about just adding the -I (isolated mode) flag to the #! line of
>> installed scripts?
>>
>
> Not a
On Mon, Jun 05, 2017 at 09:59:35PM +1200, Greg Ewing
wrote:
> Stephan Houben wrote:
> >What about just adding the -I (isolated mode) flag to the #! line of
> >installed scripts?
>
> Not all unix systems support passing extra arguments on a #! line.
In case of #!/usr/bin/env - yes. In case of
On Mon, Jun 05, 2017 at 12:06:45PM +0200, Stephan Houben
wrote:
> What about doing it on the systems which *do* support it?
> (Which probably covers 99% of the installed base...)
That's the job of Linux distribution packagers, not Python Core
developers.
> Stephan
>
> Op 5 jun. 2017 11:59 s
Would it not be a job for setuptools?
Setuptools creates the scripts.
Stephan
Op 5 jun. 2017 12:12 schreef "Oleg Broytman" :
On Mon, Jun 05, 2017 at 12:06:45PM +0200, Stephan Houben <
stephan...@gmail.com> wrote:
> What about doing it on the systems which *do* support it?
> (Which probably cove
Le 5 juin 2017 00:52, "Guido van Rossum" a écrit :
I really don't want people to start using the "from . import foo" idiom for
their first steps into programming. It seems a reasonable "defensive
programming" maneuver to put in scripts and apps made by professional
Python programmers for surpris
On 5 June 2017 at 19:49, Stephan Houben wrote:
> What about just adding the -I (isolated mode) flag to the #! line of
> installed scripts?
Fedora & derivatives generally do do that, but as others noted, it can
sometimes cause issues with shebang line parsers. It's also easy to
lose the setting wh
On 5 June 2017 at 20:55, Victor Stinner wrote:
> A minimum change would be to add the (empty string) at the end of sys.path
> in Python 3.7 rather than adding it at the start.
>
> It would increase Python usability since it avoids the "random has no
> randint() function" caused by a random.py file
So it seems the best thing would be to have a system-python executable
which always runs in isolated mode?
In fact I could imagine that security-conscious distributions would only
install system-python by default and relegate the ordinary python to some
python-dev package.
Stephan
Op 5 jun. 2017
On Mon, Jun 5, 2017 at 4:14 AM, Nick Coghlan wrote:
> The biggest problem with this approach is that it means that adding
> new standard library modules becomes a backwards compatibility break -
> scripts that used to work will now fail since they'll get the standard
> library module rather than t
On Mon, Jun 5, 2017 at 3:55 AM, Victor Stinner
wrote:
> A minimum change would be to add the (empty string) at the end of sys.path
> in Python 3.7 rather than adding it at the start.
>
> It would increase Python usability since it avoids the "random has no
> randint() function" caused by a random
On 6/5/17, Chris Barker wrote:
> On Mon, Jun 5, 2017 at 3:55 AM, Victor Stinner
> wrote:
>
>> A minimum change would be to add the (empty string) at the end of
>> sys.path
>> in Python 3.7 rather than adding it at the start.
>>
>> It would increase Python usability since it avoids the "random has
On Mon, Jun 5, 2017 at 10:52 AM Chris Barker wrote:
> On Mon, Jun 5, 2017 at 3:55 AM, Victor Stinner
> wrote:
>
>> A minimum change would be to add the (empty string) at the end of
>> sys.path in Python 3.7 rather than adding it at the start.
>>
>> It would increase Python usability since it avo
On 5 June 2017 at 22:25, Nathaniel Smith wrote:
> On Mon, Jun 5, 2017 at 4:14 AM, Nick Coghlan wrote:
>> The biggest problem with this approach is that it means that adding
>> new standard library modules becomes a backwards compatibility break -
>> scripts that used to work will now fail since t
15 matches
Mail list logo