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.

Author terry.reedy
Recipients Santiago.Piccinini, amaury.forgeotdarc, docs@python, lemburg, pitrou, terry.reedy
Date 2012-01-13.09:08:03
SpamBayes Score 8.881795e-11
Marked as misclassified No
Message-id <1326445688.11.0.3915279075.issue10344@psf.upfronthosting.co.za>
In-reply-to
Content
Something seems wrong somewhere. First,
codecs.open(filename, mode[, encoding[, errors[, buffering]]]) 
in the doc, should be, to match the code, in the current sytle
codecs.open(filename, mode='rb', encoding=None, errors='strict', buffering=1)
The other entries below follow this style.

The Note says "Files are always opened in binary mode, even if no binary mode was specified.". However, the code is
    if encoding is not None and \
       'b' not in mode:
        # Force opening of the file in binary mode
        mode = mode + 'b'
so the forcing only happens when an encoding is given. Since the intent is that codecs.open == open when no encoding is given, I believe the Note should be revised rather than the code.

(buffering=1) means line buffered. However, the doc for builtin open() says about buffering "1 to select line buffering (only usable in text mode)" So the default buffering is one that is not usable in the normal forced binary mode. Marc-Andre, can you explain this? (The doc for open() does not specify what happens when the buffering conflicts with the mode.)

The doc for StreamReader.readline() says ""size, if given, is passed as size argument to the stream’s readline() method.". If that were true, size would the max bytes to read. However, the docstring for the same in codecs.py says "size, if given, is passed as size argument to the read() method.", and that is what the code does. If not given, 72 is used as the default. (Why not 80?)

So, while the doc needs a minor tweak, I do not see what the OP's posted original result has to do with buffering. .readline does not have a fixed internal buffer of 72 chars that I can see. Rather, that is the default number of chars to read. So that is what it read, given that the file is longer than that.

I believe this is what Marc-Andre said, in different words, in his first post, in between the distraction of whether to remove open.

Santiago, yes, there is a difference between open.readline and codecs.readline. It will be more obvious when the codecs.readline size doc is corrected to specify that it is passed to read(), not readline(), and that it defaults to 72.
History
Date User Action Args
2012-01-13 09:08:09terry.reedysetrecipients: + terry.reedy, lemburg, amaury.forgeotdarc, pitrou, docs@python, Santiago.Piccinini
2012-01-13 09:08:08terry.reedysetmessageid: <1326445688.11.0.3915279075.issue10344@psf.upfronthosting.co.za>
2012-01-13 09:08:04terry.reedylinkissue10344 messages
2012-01-13 09:08:03terry.reedycreate