This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: can be a directory
Type: behavior Stage: resolved
Components: Documentation Versions: Python 3.4, Python 3.5, Python 2.7
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: docs@python Nosy List: abraithwaite, berker.peksag, docs@python, eric.smith, georg.brandl, rhettinger, vstinner
Priority: low Keywords:

Created on 2014-06-17 02:48 by abraithwaite, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (9)
msg220787 - (view) Author: (abraithwaite) Date: 2014-06-17 02:48
Is this expected?  It was very confusing when I cloned a repo that didn't have the there when I had just made it, but of course git doesn't track files, only directories.  I had accidentaly done mkdir instead of touch.

$ mkdir pkg/
$ touch pkg/
$ python
Python 3.4.1 (default, May 19 2014, 17:23:49) 
[GCC 4.9.0 20140507 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg import foobar
>>> foobar
<module 'pkg.foobar' from '/home/abraithwaite/pkg/'>
msg220788 - (view) Author: (abraithwaite) Date: 2014-06-17 03:30
> but of course git doesn't track files, only directories.

but of course git doesn't track *directories*, only *files*.
msg220789 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-06-17 04:54
> Is this expected? 

It is a little weird but usually problematic.  The cause that import checks for the existence of '' but doesn't then add isfile() or  isdir() check which would be unnecessary 99.9% of the time.

I classify this a harmless oddity.
msg220802 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2014-06-17 07:10
I think this is related to PEP 420.

    $ tree pkg/

    $ python3.2 -c "from pkg import foobar"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    ImportError: No module named pkg

But, with Python 3.3 and newer:

    $ python3.3 -c "from pkg import foobar"

See for the whatsnew entry.
msg220832 - (view) Author: (abraithwaite) Date: 2014-06-17 14:25
Interesting.  I saw the same behavior on 2.7.7 as well:

$ python2
Python 2.7.7 (default, Jun  3 2014, 01:46:20) 
[GCC 4.9.0 20140521 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg import foobar
>>> foobar
<module 'pkg.foobar' from 'pkg/'>

Anyways, it doesn't bother me too much.  I opened a ticket because I couldn't find an already open bug about it or any reference to it on google (although the keywords aren't great for google searches).

msg220841 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-06-17 15:54
See also the issue #7732.
msg220842 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-06-17 16:00
I remember that I added an check in Python 3.2 on the file type to explicitly reject directories:

+            if (stat(buf, &statbuf) == 0 && S_ISDIR(statbuf.st_mode))
+                /* it's a directory */
+                fp = NULL;
+            else

I wrote this change in the C code, I didn't report the change to the Python code (importlib).

A huge work was also done in importlib to reduce the number of calls to stat(). So maybe a check was dropped by mistake?
msg221131 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-06-20 22:56
> So maybe a check was dropped by mistake?

Why do we care?  For the most part, Linux treats directories as files (if I do a mkdir twice, the error is "mkdir: tmp: File exists".  We don't care about the other flags rwx so why should we care about d?

Python should avoid adding superfluous checks when it doesn't have to.

> Anyways, it doesn't bother me too much.

AFAICT, it hasn't bothered anyone.
msg228698 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2014-10-06 14:38
I agree, closing.
Date User Action Args
2022-04-11 14:58:05adminsetgithub: 65983
2014-10-06 14:38:36georg.brandlsetstatus: open -> closed

nosy: + georg.brandl
messages: + msg228698

resolution: wont fix
2014-06-20 22:56:55rhettingersetmessages: + msg221131
2014-06-20 21:08:55terry.reedysetversions: - Python 3.1, Python 3.2, Python 3.3
2014-06-17 16:00:59vstinnersetmessages: + msg220842
2014-06-17 15:54:12vstinnersetnosy: + vstinner
messages: + msg220841
2014-06-17 14:25:06abraithwaitesetstatus: pending -> open
resolution: not a bug -> (no value)
messages: + msg220832
2014-06-17 07:10:53berker.peksagsetstatus: open -> pending

nosy: + berker.peksag, eric.smith
messages: + msg220802

resolution: not a bug
stage: resolved
2014-06-17 04:54:33rhettingersetpriority: normal -> low
nosy: + rhettinger
messages: + msg220789

2014-06-17 03:30:11abraithwaitesetmessages: + msg220788
2014-06-17 02:48:32abraithwaitecreate