Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Fleming (splitscreen)
>Assigned to: Tim Peters (tim_one)
Summary: Python does not check for POSIX compliant open() modes
Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().
According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.
This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.
----------------------------------------------------------------------
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 09:55
Message:
Logged In: YES
user_id=849994
Tim: Did you review file-modes.diff which is really the
latest patch? (There's no test in it either, but I'll add
one when I check it in)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2006-04-24 01:19
Message:
Logged In: YES
user_id=31435
This is still ;-) fine with me. There doesn't seem to be a
test in fileobject2.diff. WRT the docs, "must either be"
should say "must be one of" instead ("either" is proper for
two choices, but there are three). It should state that
this requirement is new in Python 2.5; in LaTeX, something like
\versionchanged[Restriction on first letter of mode string
introduced]{2.5}
----------------------------------------------------------------------
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-12 10:14
Message:
Logged In: YES
user_id=1126061
Yeah, your patch looks much better.
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 08:15
Message:
Logged In: YES
user_id=849994
splitscreen: your patch was incomplete and could have
overwritten memory.
tim_one: Attaching new patch implementing what I proposed in
my comment below.
----------------------------------------------------------------------
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 21:59
Message:
Logged In: YES
user_id=1126061
Ok, uploading latest patch, not quite sure I've hit the mark
here.
Please review.
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 20:43
Message:
Logged In: YES
user_id=849994
Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.
----------------------------------------------------------------------
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 19:32
Message:
Logged In: YES
user_id=1126061
Ignore my question, it's for "universal newlines", right?
Have I understood your proposal correctly in that you want
to remove the 'U' from the mode?
----------------------------------------------------------------------
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 14:14
Message:
Logged In: YES
user_id=1126061
That seems sensible. What does a mode containing 'U' mean
anyway?
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:08
Message:
Logged In: YES
user_id=849994
Instead of this patch, I'd rather like check_the_mode to
* remove any 'U' from the mode string
* if 'U' was found:
* error out if the new string begins with 'w' or 'a'
* add a 'r' and 'b' if it isn't already given
* if not:
* error out if the string doesn't begin with 'w', 'r', 'a'
What do you think of it?
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:03
Message:
Logged In: YES
user_id=31435
There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed. I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").
All that said, I'm in favor of this patch ;-). However, if
it goes in two things are needed:
1. The error message should be more informative, like
PyErr_Format(PyExc_ValueError, "mode argument must "
"begin with 'w', 'r', or 'a', not '%.200s'", mode);
2. The Python docs should change to match (i.e., the
manual should document this new restriction on mode
strings).
WRT the test case, it's more natural to write, e.g.,
TESTFN in s
than
s.find(TESTFN) != -1
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
