Issue487277
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.
Created on 2001-11-29 22:43 by niemeyer, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
file.diff | loewis, 2001-12-03 09:02 |
Messages (19) | |||
---|---|---|---|
msg7861 - (view) | Author: Gustavo Niemeyer (niemeyer) * | Date: 2001-11-29 22:43 | |
The behavior of readline() has changed on 2.2. This should be documented. Example: Python 2.1 (#1, Jun 22 2001, 17:13:13) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> open("/etc").readline() '' Python 2.2b2+ (#1, Nov 27 2001, 21:39:35) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-ppc Type "help", "copyright", "credits" or "license" for more information. >>> open("/etc").readline() Traceback (most recent call last): File "<stdin>", line 1, in ? IOError: [Errno 21] Is a directory |
|||
msg7862 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-11-29 23:53 | |
Logged In: YES user_id=21627 I don't think this needs to be documented. The change is a bug fix, reading from a directory was never supposed to work (whether in lines or not). |
|||
msg7863 - (view) | Author: Gustavo Niemeyer (niemeyer) * | Date: 2001-11-30 00:10 | |
Logged In: YES user_id=7887 I think *any* change visible at user space should be documented. I discovered this change because a program I have never read in my life (in fact, I didn't even know it was written in python) has blown up in my hands. It was reading files and safely ignoring directories by testing readline()'s output. |
|||
msg7864 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-11-30 09:19 | |
Logged In: YES user_id=21627 Any change is user-visible: for any change, I can construct a program that behaves differently with the change. Otherwise, the change would be useless (except that it may add commentary or some such). In fact, the change *is* documented, namely in the CVS log. Extracting all those fragments into a single document would be time-consuming and pointless: nobody can read through hundreds of changes. Your program would have blown up even if there was such a document. If a change has severe effects on many existing programs, it should be implemented differently. |
|||
msg7865 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-11-30 09:36 | |
Logged In: YES user_id=38388 I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) the "What's new in Python x.x" docs. This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a program if you want to port it from one Python version to the next, so we'll have to be very careful about these changes even if they are clearly bug fixes. In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being a directory than to rely on some obscure method return value and also much safer ! |
|||
msg7866 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-11-30 12:21 | |
Logged In: YES user_id=21627 Well, I wouldn't object to anybody documenting this particular change (even though I won't do that myself, either). I'm just pointing out that there are many more changes of this kind, and that it would be an illusion that you could ever produce a complete list. |
|||
msg7867 - (view) | Author: Gustavo Niemeyer (niemeyer) * | Date: 2001-11-30 14:15 | |
Logged In: YES user_id=7887 I beg your pardon. Are you saying that there are many changes in Python 2.2 that will blow up code written in Python 2.1!? Why do we have __future__ than!? Why are we concerned about being careful with division upgrade when we have lots of small stuff breaking up *valid* code written one release ago? And, if this was not enough, these changes won't even be documented!?! |
|||
msg7868 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-11-30 16:07 | |
Logged In: YES user_id=21627 No. I think very few of the changes will ever cause problems in real software - including this one. I wouldn't be surprised if this remains the only reported incidence of that change. I *am* saying that for every change that has been made, one could construct an application that breaks under this change. This theoretical potential for breakage shouldn't cause prominent appearance in documentation; everybody who really wants to see documentation for all changes should consult the CVS logs. |
|||
msg7869 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-11-30 22:26 | |
Logged In: YES user_id=31435 Does anyone know why opening a directory for reading doesn't complain on Linux? It has always complained on Windows. If readline() is doomed to fail, why do we allow opening a directory for reading at all? OTOH, if it's not insane to open a directory for reading on Linux, why does readline() complain on Linux? |
|||
msg7870 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-11-30 22:44 | |
Logged In: YES user_id=38388 For the record, this is what I get with Python 2.2b2 on Linux: >>> f = open('/home/lemburg/') >>> f.read() Traceback (most recent call last): File "<stdin>", line 1, in ? IOError: [Errno 21] Is a directory >>> f.readline() '' >>> f.readlines() Traceback (most recent call last): File "<stdin>", line 1, in ? IOError: [Errno 21] Is a directory >>> Reading the man-page for open(), it seems that directories play some role (though it's not clear which...): open() options: ... O_DIRECTORY If pathname is not a directory, cause the open to fail. This flag is Linux-specific, and was added in kernel version 2.1.126, to avoid denial-of-ser vice problems if opendir(3) is called on a FIFO or tape device, but should not be used outside of the implementation of opendir. errno values: ... EISDIR pathname refers to a directory and the access requested involved writing. EACCES The requested access to the file is not allowed, or one of the directories in pathname did not allow search (execute) permission, or the file did not exist yet and write access to the parent directory is not allowed. |
|||
msg7871 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-12-02 13:16 | |
Logged In: YES user_id=21627 Opening a directory is the only way, on Unix, to get its contents. The file descriptor returned is then passed to getdents(2) or readdir(2) (depending on the OS version). __builtins__.open doesn't fail because it calls fopen right away, which doesn't fail because it calls open(2) with just O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will then only return EISDIR if the directory is opened for writing. Since this is the behaviour documented in Posix, it is unlikely that Linux glibc will change. |
|||
msg7872 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-12-02 20:18 | |
Logged In: YES user_id=31435 Well, my question isn't really about libc but about Python: since Python doesn't expose getdents(2) or readdir (2), how could it be anything but a mistake for a Python user on Linux to try to __builtin__.open() a directory? |
|||
msg7873 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-12-03 09:02 | |
Logged In: YES user_id=21627 I agree that Python should not allow to open a directory. Attached is a patch that implements this check; it is somewhat more involved since it must also check file object that are created through PyFile_FromFile etc. |
|||
msg7874 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-12-03 13:03 | |
Logged In: YES user_id=6380 I take it that this needn't be included in 2.2? Who knows what it would break. |
|||
msg7875 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-12-03 14:22 | |
Logged In: YES user_id=21627 Yes, changing it later is fine. |
|||
msg7876 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-12-11 22:50 | |
Logged In: YES user_id=6380 Are we even sure that open("/") should be disallowed? What if it is used as an existence test? What is allowed by open() should be the realm of the stdio fopen() function, and we shouldn't second-guess it. If fopen() allows us to open directories, why shouldn't we? |
|||
msg7877 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-12-12 08:06 | |
Logged In: YES user_id=21627 Tim was arguing that open("/") fails on some systems, anyway, since the C library will refuse to open a directory. So it would be for uniformity's sake that makes it fail on Posix, as well. I think that fopen() allows to open a directory is by a similar rationale: if open(2) allows to open it, fopen(3) should do so as well. That rationale is already broken: open(2) is needed to read a directory, but you cannot read a directory if you have a FILE*. The "used for existence test" argument isn't very convincing; use access or stat for that (specifically, os.exists). Of course, changing it might break existing code, just as changing .readline did. It is clear that posix.open should forward directly to the system call, instead of performing checks. It is not so clear that file() should do the same thing. |
|||
msg7878 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-12-12 12:46 | |
Logged In: YES user_id=6380 OK,. I buy that argument. I'll take a patch after 2.2. We really need a "2.3" group here -- for now I've set the group to feathre request. |
|||
msg7879 - (view) | Author: Neil Schemenauer (nascheme) * | Date: 2002-03-22 20:39 | |
Logged In: YES user_id=35752 Commited as fileobject.c 2.148. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:42 | admin | set | github: 35626 |
2001-11-29 22:43:40 | niemeyer | create |