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.)

Oh, so it's possible to not have the fstat() syscall. I asked me the question when I modified import.c (and other files related to importing a module).

Should the .pyc/.pyo file writing be disabled altogether if stat() and/or fstat() is not available. In this case, there's no way to check mtimes, right?

Does your filesystem store the modification time? Why don't you have/want fstat()? Do you have stat() or a similar function?

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?

> Should the .pyc/.pyo file writing be disabled altogether
> if stat() and/or fstat() is not available.

If we cannot get the file modification time, .pyc/.pyo writing must be disabled. If your OS/libc/filesystem doesn't have fstat(), you don't have file modification, so no .pyc/.pyo write.

STINNER Victor wrote:
> If we cannot get the file modification time, .pyc/.pyo writing must be disabled. If your OS/libc/filesystem doesn't have fstat(), you don't have file modification, so no .pyc/.pyo write.

Should I go on and write a patch? Any hints on how this code path (of
not writing .pyc/.pyo because of missing stat() and fstat()) could be
tested?

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.

> Should I go on and write a patch?

Yes please, write a patch, I will review it.

To emulate a system without stat or fstat, you may use:
#define fstat dont_have_fstat
#define stat dont_have_stat

The link will fail if the code still refer to fstat() or stat().

I tried to compile Python 3.3 (from default branch) with DONT_HAVE_FSTAT and DONT_HAVE_STAT. It seems to depend even more heavily on stat() being available, in other files than Python/import.c.

With 2.7, it was quite easy to disable the .pyc/.pyo writing in the absence of fstat(), but the NullImporter needs to be able to check for a directory. In addition, the build process fails when trying to run "setup.py build", because distutils cannot be imported. And it cannot be imported because it's a package, and packages (directories) cannot be detected without having stat().

So... Unless we have another way to check for a directory, I'm not sure whether it will be possible to compile Python at all without stat().

Rather than checking for a directory, how about just opening foo/__init__.py, and if that fails opening foo.py?

The NullImporter is documented to raise ImportError on directories, not directories containing __init__.py:

    http://docs.python.org/library/imp.html#imp.NullImporter

Checking for __init__.py{,c,o} seems doable to me without having stat().

My vote is for won't fix. Systems without stat() or fstat() are clearly broken from Python's point of view; at the very least, they aren't POSIX-compliant.

Should the defines be removed then, because they're kind of false promises for the user.

Actually many people try to compile python on an environment with freestanding C library, so this can be a specific case of that. Is there any issue or thread where compiling python with freestanding headers is discussed? As this relates to that.

Shall you remove the defines, please put instructions in the source code to let user know how they can provide their self-invented fstat function to the code.

For those of you who are concerned with this issue, could you explain your use case on the following discussion thread: http://mail.python.org/pipermail/python-dev/2013-May/126285.html ?

I would personally like to remove HAVE_FSTAT and make Python unconditionally use fstat(). It will make the code quite simpler in some places.