[issue46645] Portable python3 shebang for Windows, macOS, and Linux
Josh Triplett added the comment: Correction to the above evaluation of `#!/usr/bin/env python3`, based on some retesting on Windows systems: The failure case we encounter reasonably often involves the official Python installer for Windows, but applies specifically in the case of third-party shells such as MSYS2, which fail with that shebang. `#!/usr/bin/env python3` does work with the official Python installer when running from cmd or PowerShell, it just doesn't work from third-party shells. We have enough users that cases like this come up reasonably often, and it'd be nice to Just Work in those cases too. Thank you. -- ___ Python tracker <https://bugs.python.org/issue46645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46645] Portable python3 shebang for Windows, macOS, and Linux
New submission from Josh Triplett : I'm writing this issue on behalf of the Rust project. The build system for the Rust compiler is a Python 3 script `x.py`, which orchestrates the build process for a user even if they don't already have Rust installed. (For instance, `x.py build`, `x.py test`, and various command-line arguments for more complex cases.) We currently run into various issues making this script easy for people to use on all common platforms people build Rust on: Windows, macOS, and Linux. If we use a shebang of `#!/usr/bin/env python3`, then x.py works for macOS and Linux users, and also works on Windows systems that install Python via the Windows store, but fails to run on Windows systems that install via the official Python installer, requiring users to explicitly invoke Python 3 on the script, and adding friction, support issues, and complexity to our documentation to help users debug that situation. If we use a shebang of `#!/usr/bin/env python`, then x.py works for Windows users, fails on some modern macOS systems, works on other modern macOS systems (depending on installation method I think, e.g. homebrew vs Apple), fails on some modern Linux systems, and on macOS and Linux systems where it *does* work, it might be python2 or python3. So in practice, people often have to explicitly run `python3 x.py`, which again results in friction, support issues, and complexity in our documentation. We've even considered things like `#!/bin/sh` and then writing a shell script hidden inside a Python triple-quoted string, but that doesn't work well on Windows where we can't count on the presence of a shell. We'd love to write a single shebang that works for all of Windows, macOS, and Linux systems, and doesn't resort in recurring friction or support issues for us across the wide range of systems that our users use. As far as we can tell, `#!/usr/bin/env python3` would work on all platforms, if the Python installer for Windows shipped a `python3.exe` and handled that shebang by using `python3.exe` as the interpreter. Is that something that the official Python installer could consider adding, to make it easy for us to supply cross-platform Python 3 scripts that work out of the box for all our users? Thank you, Josh Triplett, on behalf of many Rust team members -- messages: 412553 nosy: joshtriplett priority: normal severity: normal status: open title: Portable python3 shebang for Windows, macOS, and Linux type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42799] Please document fnmatch LRU cache size (256) and suggest alternatives
New submission from Josh Triplett : fnmatch translates shell patterns to regexes, using an LRU cache of 256 elements. The documentation doesn't mention the cache size, just "They cache the compiled regular expressions for speed.". Without this knowledge, it's possible to get pathologically bad performance by exceeding the cache size. Please consider adding documentation of the cache size to the module documentation for fnmatch, along with a suggestion to use fnmatch.translate directly if you have more patterns than that. -- components: Library (Lib) messages: 384141 nosy: joshtriplett priority: normal severity: normal status: open title: Please document fnmatch LRU cache size (256) and suggest alternatives versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27450] bz2: BZ2File should expose compression level as an attribute
Josh Triplett added the comment: As part of a reproducible build project, to allow recompressing a file with the same compression level previously used. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27451] gzip.py: Please save more of the gzip header for later examination
New submission from Josh Triplett: GzipFile currently reads and discards various fields from the gzip header, such as the original filename and timestamp. Please consider reading all the fields of the gzip header into fields of the GzipFile instance, so that users of GzipFile can access these fields. -- components: Library (Lib) messages: 269808 nosy: joshtriplett priority: normal severity: normal status: open title: gzip.py: Please save more of the gzip header for later examination type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27450] bz2: BZ2File should expose compression level as an attribute
New submission from Josh Triplett: (This exists in both Python 3 and Python 2.) When opening an existing .bz2 file with BZ2File, I'd like to have access to the compression level, so that I don't have to manually parse the file's header to get it. BZ2File could provide the compression level as an attribute on itself. -- components: Library (Lib) messages: 269806 nosy: joshtriplett priority: normal severity: normal status: open title: bz2: BZ2File should expose compression level as an attribute type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12556] Disable size checks in mmap.mmap()
Josh Triplett added the comment: This rejection is indeed problematic. If mmap.mmap receives an explicit size, checking that size against stat will break on devices or special files. It's perfectly reasonable that mmap.mmap's automatic logic when passed length=0 (to map the entire file) won't work if stat says the file has length 0, but the mmap syscall works fine on special files with length 0 (or devices), and mmap.mmap should work in that case as well. -- nosy: +joshtriplett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12556 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Josh Triplett j...@joshtriplett.org added the comment: I currently use Python 2.7, and I'd like to make use of memoryview. Specifically, I work on BITS (http://biosbits.org/), which runs Python in ring 0 as part of GRUB, and I'd like to use memoryview to give Python access to data in physical memory. I ran into several of the problems documented here when trying to do so. I'd really love to see a backport of this fixed version into 2.7. -- nosy: +joshtriplett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Josh Triplett j...@joshtriplett.org added the comment: I currently use Python 2.7, and I'd like to make use of memoryview. Specifically, I work on BITS (http://biosbits.org/), which runs Python in ring 0 as part of GRUB, and I'd like to use memoryview to give Python access to data in physical memory. I ran into several of the problems documented here when trying to do so. I'd really love to see a backport of this fixed version into 2.7. More specifically, the primary functionality that I'd like to use exists in 3.3 as PyMemoryView_FromMemory. I've tried to approximate that function using the available API in 2.7, but that led me here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
Josh Triplett j...@joshtriplett.org added the comment: The current behavior of pydoc will cause synopsis to always incorrectly return None as the synopsis for any module with mtime == 0. Both of the proposed fixes will fix that bug without affecting any case where mtime != 0, so I don't think either one has backward-compatibility issues. I'd suggest using the fix of changing the .get call to return a default of (None, None) and changing the conditional to lastupdate is not None and lastupdate mtime. That variant seems like more obvious code (since None clearly means no lastupdate time), and it avoids special-casing an mtime of 0 and bypassing the synopsis cache. I don't mind writing a patch if that would help this fix get in. I'll try to write onein the near future, but I certainly won't mind if someone else beats me to it. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12603 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0 (common for filesystems without mtime)
New submission from Josh Triplett j...@joshtriplett.org: In Python 2.7.2, pydoc.py's synopsis contains this code implementing a cache: mtime = os.stat(filename).st_mtime lastupdate, result = cache.get(filename, (0, None)) if lastupdate mtime: Many filesystems don't have any concept of mtime or don't have it available, including many FUSE filesystems, as well as our implementation of stat for GRUB in BITS. Such systems typically return an mtime of 0. (In addition, 0 represents a valid mtime.) Since the cache in pydoc.synopsis initializes lastupdate to 0 for entries not found in the cache, this causes synopsis to always return None. I'd suggest either extending the conditional to check lastupdate != 0 and lastupdate mtime (which would always treat an mtime of 0 as requiring an update, which would make sense for filesystems without valid mtimes) or changing the .get to return (None, None) and checking lastupdate is not None and lastupdate mtime, which would treat an mtime of 0 as valid but still handle the case of not having a cache entry the first time. -- components: Library (Lib) messages: 140826 nosy: joshtriplett priority: normal severity: normal status: open title: pydoc.synopsis breaks if filesystem returns mtime of 0 (common for filesystems without mtime) versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12603 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12604] VTRACE macro in _sre.c should use do {} while (0)
New submission from Josh Triplett j...@joshtriplett.org:
In _sre.c, the VTRACE macro normally gets defined to nothing. It later gets
used as the body of control structures such as else without braces, which
causes many compilers to warn (to catch stray semicolons like else;). This
makes it difficult to compile Python as part of a project which uses -Werror,
such as GRUB. Please consider defining VTRACE as do {} while(0) instead, as
the standard convention for an empty function-like macro with no return value.
--
messages: 140827
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: VTRACE macro in _sre.c should use do {} while (0)
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12604
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12082] Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT
Josh Triplett j...@joshtriplett.org added the comment: Rather than checking for a directory, how about just opening foo/__init__.py, and if that fails opening foo.py? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12082 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12082] Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT
Josh Triplett j...@joshtriplett.org added the comment: Given that GRUB doesn't support writing to filesystems at all, I already have to set Py_DontWriteBytecodeFlag, so disabling .pyc/.pyo entirely would work fine for my use case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12082 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12082] Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT
Josh Triplett j...@joshtriplett.org added the comment: GRUB's filesystem drivers don't support reading mtime. And no, no form of stat() function exists, f or otherwise. On a related note, without HAVE_STAT, import.c can't import package modules at all, since it uses stat to check in advance for a directory. In the spirit of Python's usual try it and see if it works approach, why not just try opening foo/__init__.py, and if that doesn't work try opening foo.py? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12082 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12082] Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT
New submission from Josh Triplett j...@joshtriplett.org: Even if pyconfig.h defines DONT_HAVE_STAT and DONT_HAVE_FSTAT (which prevents the definitions of HAVE_STAT and HAVE_FSTAT), Python still references fstat in Python/import.c, along with struct stat and constants like S_IXUSR. I ran into this when attempting to compile Python for an embedded platform, which has some basic file operations but does not have stat. (I will likely end up faking fstat for now, but I'd rather not have to do so.) -- components: Build messages: 136055 nosy: joshtriplett priority: normal severity: normal status: open title: Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12082 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12083] Compile-time option to avoid writing files, including generated bytecode
New submission from Josh Triplett j...@joshtriplett.org: PEP 304 provides a runtime option to avoid saving generating bytecode files. However, for embedded usage, it would help to have a compile-time option to remove all the file-writing code entirely, hardcoding PYTHONBYTECODEBASE=. I ran into this when porting Python to an embedded platform, which will never support any form of filesystem write operations; currently, I have to provide dummy functions for writing files, which error out when attempting to write to anything other than stdout or stderr. -- components: Build messages: 136056 nosy: joshtriplett priority: normal severity: normal status: open title: Compile-time option to avoid writing files, including generated bytecode type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12083 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
