Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
2015-03-19 21:47 GMT+01:00 Toshio Kuratomi : > I think I've found the Debian discussion (October 2012): > > http://comments.gmane.org/gmane.linux.debian.devel.python/8188 > > Lack of PYTHONWARNINGS was brought up late in the discussion thread Maybe we need to modify -E or add a new option to only ignore PYTHONPATH. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On 19Mar2015 19:57, Sturla Molden wrote: Orion Poplawski wrote: It would be good to get some feedback from the broader python community before implementing anything, so I'm asking for feedback here. On my systems I have /use/bin/python for the system and ~/anaconda/python for me. Apple and Ubuntu can do whatever they want with their Python's, I am not touching them. The main thing is to keep the system Python and the user Python separate. That is, both the executable and the folder where packages are installed. Whatever I install for myself can fuck up ~/anaconda, but is not allowed to mess with the system files or system folders. Me too. I keep my default virtualenvs in ~/var/venv, and have personal "py2" and "py3" scripts that invoke via the venvs. Having a similar separation in the system would be a good thing, for the same reasons. Also, it would let the OS supplier keep a _much_ smaller package/addon list for the "core" admin python instance, making QA etc easier and more reliable. Popular OSes let the local sysadmin (== "the user") pull in all sorts of stuff to the "system" Python, even from the supplier's repositories. Having a walled off "core" admin python as well seems very prudent. Cheers, Cameron Simpson conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, /viz./ to those who like to show how clever they are. I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. - Edsger Dijkstra, _The Humble Programmer_ (CACM, Ocotber, 1972) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
I think I've found the Debian discussion (October 2012): http://comments.gmane.org/gmane.linux.debian.devel.python/8188 Lack of PYTHONWARNINGS was brought up late in the discussion thread but I think the understanding that when a particular user sets an environment variable they want it to apply to all scripts they run was kind of lost in the followups (It wasn't directly addressed or mentioned again.) -Toshio On Thu, Mar 19, 2015 at 12:27 PM, Barry Warsaw wrote: > On Mar 19, 2015, at 11:15 AM, Toshio Kuratomi wrote: > >>I could see that as a difference. However, the environment variables >>give users the ability to change things globally whereas overriding >>the shebang line is case-by-case so it's not a complete replacement >>of the functionality. > > You make some good points. I guess it's a trade-off between flexibility and a > known secure execution environment. I'm not sure there's a right answer; > different admins might have valid different opinions. > > Cheers, > -Barry > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/a.badger%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
Orion Poplawski wrote: > It would be good to get some feedback from the broader python community > before implementing anything, so I'm asking for feedback here. On my systems I have /use/bin/python for the system and ~/anaconda/python for me. Apple and Ubuntu can do whatever they want with their Python's, I am not touching them. The main thing is to keep the system Python and the user Python separate. That is, both the executable and the folder where packages are installed. Whatever I install for myself can fuck up ~/anaconda, but is not allowed to mess with the system files or system folders. Sturla ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On Mar 19, 2015, at 11:15 AM, Toshio Kuratomi wrote: >I could see that as a difference. However, the environment variables >give users the ability to change things globally whereas overriding >the shebang line is case-by-case so it's not a complete replacement >of the functionality. You make some good points. I guess it's a trade-off between flexibility and a known secure execution environment. I'm not sure there's a right answer; different admins might have valid different opinions. Cheers, -Barry pgpniq0DKukw3.pgp Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On Wed, Mar 18, 2015 at 2:56 PM, Barry Warsaw wrote: > On Mar 18, 2015, at 02:44 PM, Toshio Kuratomi wrote: > >>Interesting, I've cautiously in favor of -s in Fedora but the more I've >>thought about it the less I've liked -E. It just seems like PYTHONPATH is >>analagous to LD_LIBRARY_PATH for C programs and PATH for shell scripting. >>We leave both of those for local admins and users to affect the behaviour of >>programs if they needed to. > > It is, and it isn't. It's different because you can always explicitly > override the shebang line if needed. So if a local admin really needed to > override $PYTHONPATH (though I can't come up with a use case right now), they > could just: > > $ python3 -s /usr/bin/foo > I could see that as a difference. However, the environment variables give users the ability to change things globally whereas overriding the shebang line is case-by-case so it's not a complete replacement of the functionality. LD_LIBRARY_PATH can be used for things like logging all calls to a specific function, applying a bugfix to a library when you don't have root on the box, evaluating how a potential replacement for a system library will affect the whole system, and other things that are supposed to affect a large number of the files on the OS. PYTHONPATH can be used for the same purposes as long as -E is not embedded into the shebang lines. (I suppose you could write a "python" wrapper script that discards -E... but you'd need root on the box to install your wrapper [since system packages are encouraged to use the full path to python rather than env python] and the change would affect everyone on the box rather than just the person setting the env var). Using -E by default for all system applications would prevent that. The benefit of -E is that it isolates the effects of PYTHONPATH to only specific programs. However, that benefit doesn't seem as striking as it first appears (or at least, as it first appeared to me :-). Unix env vars have their own method of isolation: if the env var is marked for export then it is sent to child processes. If it is not marked for export then it only affects the current process. So it seems like -E isn't adding something new; it's just protecting users from themselves. That seems contrary to "consenting adults" (although distributions are separate entities from python-dev ;-). What makes -s different from -E? If you think about it in the context of users being able to set PYTHONPATH to add libraries that can override system packages then I think specifying -s for system packages establishes a default behaviour: The user can override the defaults but only if they change the environment. Without -s, this expectation is violated for libraries in the user site directory. With -s, the user would have to add the user site directory to PYTHONPATH if they want the libraries there to override system packages. So I guess I'm still leaning towards -E being the wrong choice for Fedora but Fedora lives within a broader ecosystem of python-providing distributions. So I'm interested in seeing whether Debian thought about these aspects when they decided on using -E or if that would change anyone's minds and also what other distributions think about adding -s and/or -E to their packaged applications' shebang lines. -Toshio ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Needed reviews
Here is list of my ready for review patches. It is incomplete and
contains only patches for which I don't expect objections or long
discussion. Most of them are relative easy and need only formal review.
Most of them wait for a review many months.
https://bugs.python.org/issue23681
Have -b warn when directly comparing ints and bytes
https://bugs.python.org/issue23676
Add support of UnicodeTranslateError in standard error handlers
https://bugs.python.org/issue23671
string.Template doesn't work with the self keyword argument
https://bugs.python.org/issue23637
Outputting warnings fails when file patch is not ASCII and message
is unicode on 2.7.
https://bugs.python.org/issue23622
Deprecate unrecognized backslash+letter escapes in re
https://bugs.python.org/issue23611
Pickle nested names (e.g. unbound methods) with protocols < 4
https://bugs.python.org/issue23583
IDLE: printing unicode subclasses broken (again)
https://bugs.python.org/issue23573
Avoid redundant memory allocations in str.find and like
https://bugs.python.org/issue23509
Speed up Counter operators
https://bugs.python.org/issue23502
Tkinter doesn't support large integers (out of 32-bit range)
https://bugs.python.org/issue23488
Random objects twice as big as necessary on 64-bit builds
https://bugs.python.org/issue23466
PEP 461: Inconsistency between str and bytes formatting of integers
https://bugs.python.org/issue23419
Faster default __reduce__ for classes without __init__
https://bugs.python.org/issue23290
Faster set copying
https://bugs.python.org/issue23252
Add support of writing to unseekable file (e.g. socket) in zipfile
https://bugs.python.org/issue23502
pprint: added support for mapping proxy
https://bugs.python.org/issue23001
Accept mutable bytes-like objects in builtins that for now support
only read-only bytes-like objects
https://bugs.python.org/issue22995
Restrict default pickleability. Fail earlier for some types instead
of producing incorrect data.
https://bugs.python.org/issue22958
Constructors of weakref mapping classes don't accept "self" and
"dict" keyword arguments
https://bugs.python.org/issue22831
Use "with" to avoid possible fd leaks. Large patch with many simple
changes.
https://bugs.python.org/issue22826
Support context management protocol in bkfile and simplify
Tools/freeze/bkfile.py
https://bugs.python.org/issue22721
pprint output for sets and dicts is not stable
https://bugs.python.org/issue22687
horrible performance of textwrap.wrap() with a long word
https://bugs.python.org/issue22682
Add support of KZ1048 (RK1048) encoding
https://bugs.python.org/issue22681
Add support of KOI8-T encoding
https://bugs.python.org/issue23671
string.Template doesn't work with the self keyword argument
https://bugs.python.org/issue23171
Accept arbitrary iterables in cvs.writerow()
https://bugs.python.org/issue23136
Fix inconsistency in handling week 0 in _strptime()
https://bugs.python.org/issue22557
Speed up local import
https://bugs.python.org/issue22493
Deprecate the use of flags not at the start of regular expression
https://bugs.python.org/issue22390
test.regrtest should complain if a test doesn't remove temporary files
https://bugs.python.org/issue22364
Improve some re error messages using regex for hints
https://bugs.python.org/issue22115
Add new methods to trace Tkinter variables
https://bugs.python.org/issue22035
Fatal error in dbm.gdbm
https://bugs.python.org/issue21802
Reader of BufferedRWPair is not closed if writer's close() fails
https://bugs.python.org/issue21859
Add Python implementation of FileIO
https://bugs.python.org/issue21717
Exclusive mode for ZipFile
https://bugs.python.org/issue21708
Deprecate nonstandard behavior of a dumbdbm database
https://bugs.python.org/issue21526
Support new booleans in Tkinter
https://bugs.python.org/issue20168
Derby: Convert the _tkinter module to use Argument Clinic
https://bugs.python.org/issue20159
Derby: Convert the ElementTree module to use Argument Clinic
https://bugs.python.org/issue20148
Derby: Convert the _sre module to use Argument Clinic
https://bugs.python.org/issue19930
os.makedirs('dir1/dir2', 0) always fails
https://bugs.python.org/issue18684
Pointers point out of array bound in _sre.c
https://bugs.python.org/issue18473
Some objects pickled by Python 3.x are not unpicklable in Python 2.x
https://bugs.python.org/issue17711
Persistent id in pickle with protocol version 0
https://bugs.python.org/issue17530
pprint could use line continuation for long bytes literals
https://bugs.python.org/issue16314
Support xz compression in distutils
https://bugs.python.org/issue15490
Correct __sizeof__ support for StringIO
https://bugs.python.org/issue15133
Make tkinter.getboolean() and BooleanVar.get() support Tcl_Obj and
alway
