On 9/10/06, <b class="gmail_sendername">Nick Coghlan</b> <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Paul Prescod wrote:<br>> The function to open a text file will tenatively be called textfile(),<br>> though the function name is not an integral part of this PEP. The<br>> function takes three arguments, the filename, the mode ("r", "w", "r+",
<br>> etc.) and the type.<br>><br>> The type could be a true encoding or one of a small set of additional<br>> symbolic values.<br><br>The 'additional symbolic values' should be implemented as true encodings<br>
(i.e., it should be possible to look up 'site', 'guess' and 'locale' in the<br>codecs registry, and replace them there as well).</blockquote><div><br>I don't believe that these are "true" encodings because when you query a stream for its encoding you will never find these names nor an alias for them.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I also agree with Guido that the right spelling for the factory function is to
<br>incorporate this into the existing open() builtin. The signature of open() is<br>already going to change to accept an encoding argument in Py3k, and the<br>special encodings proposed in the PEP are just that: special encodings that
<br>happen to take environmental information into account when deciding how to<br>decode or encode data.</blockquote><div><br>Yes, well I disagree that the open function should get a new argument. I think it should either be deprecated or used to open byte streams. The function name is a hold over from Unix/C which has no resonance with a Java, C#, Javascript, programmer.
<br><br>Plus I would like to ease the writing of code that is both valid Python 2.x and 3.x. I'd advocate the strategy that we should try to have a large enough behavioural overlap that modules can be written to run on both. Subtle changes in semantics make this difficult. To the extent that this is unavoidable (
e.g. behaviour of very core syntax) I guess we'll have to live with it. But we can easily add a function called textfile() to both Python 2.x and Python 3.x and ease the transition.<br></div><br> Paul Prescod<br><br></div>