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 bui
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
Josh Triplett 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
Josh Triplett 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
Josh Triplett 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
<http://bugs.python.org/issue12
New submission from Josh Triplett :
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 m
New submission from Josh Triplett :
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
m
Josh Triplett 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
New submission from Josh Triplett :
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
New submission from Josh Triplett :
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
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 t
Josh Triplett 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.
Josh Triplett 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
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 e
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 co
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
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
<http://bugs.python.org/issue27
17 matches
Mail list logo