While I agree that the textfile() may be a nice idea I think
it's outside of the scope of PEP278. I'd like 278 to be purely
about being able to use source code and data files with a
foreign newline convention, and these last few mails go into
Unicode support for files, which will open a very large new can
of worms (such as conversion between non-unicode 8-bit formats
and what have you). Unicode would definitely need output support
also, which means we have to think of printfs and lots more.
How about a new PEP on this?
On donderdag, maart 14, 2002, at 08:36 , Martin v. Loewis wrote:
> Paul Prescod <paul@prescod.net> writes:
>
>>> f = textfile(filename, mode="r", encoding=None)
>>
>> Enthusiastic +1.
>>
>> But I think that encoding should default to "ASCII". We also need to
>> discuss under what circumstances textfile("foo").read()
>> returns Unicode
>> string versus 8-bit string.
>
> My suggestion would be "always", while I'm fine with the default
> encoding as "ascii".
>
> "Universal" newline support then means that additional newline markers
> should be recognized:
> U+0080 NEXT LINE (NEL)
> U+2028 LINE SEPARATOR
>
> If possible, Unicode TR 13
> (http://www.unicode.org/unicode/reports/tr13/)
> should be followed as much as possible.
>
> Regards,
> Martin
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
>
--
- Jack Jansen <Jack.Jansen@oratrix.com>
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution --
Emma Goldman -
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4