New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
source files using encoding ./. universal newlines #38984
Comments
Universal Newline Support doesn't work for source files |
Logged In: YES It's not clear to me what the problem is: Source code files Can you attach a small example that demonstrates the problem? |
Logged In: YES Attached file has encoding definition and it's newline is '\r'. C:\Python23>python .\test.py |
Logged In: YES I see. This is not about PEP-278, though, as you are not |
Logged In: YES The submitter isn't calling open explicitly, but PEP-278 is also about My guess (but I don't know the PEP-263 implementation at all) is |
Logged In: YES The only way to implement that would be to add 'U' support |
Logged In: YES I'm not sure this is correct: unless the codecs implement Now. since the stream object in the source code reader is The relevant code is in Parser/tokenizer.c:fp_setreadl(): static int
fp_setreadl(struct tok_state *tok, const char* enc)
{
PyObject *reader, *stream, *readline;
"rb", NULL); reader = PyCodec_StreamReader(enc, stream, NULL);
Py_DECREF(stream);
if (reader == NULL)
return 0;
readline = PyObject_GetAttrString(reader, "readline");
Py_DECREF(reader);
if (readline == NULL)
return 0;
tok->decoding_readline = readline;
return 1;
} |
Logged In: YES That would work indeed. The question is whether we can |
Logged In: YES Uhm, we don't impose Universal readline support on the codecs. I'm +1 on adding this to 2.3.1. |
Logged In: YES There's no such things as "rbU", I think, but simply "rU" should About 2.3.1 compatibility: technically we could break workarounds |
Logged In: YES Jack, I was just looking at the code I posted and the one The only system where 'b' does make a difference that I'm |
Logged In: YES In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated |
Logged In: YES Thanks John. Not sure whether any of codecs would actually use 0x1A, |
Logged In: YES You misunderstand what I tried to say (or I mis-said it:-): there is There is "r" == "rt" for text mode, "rb" for binary mode, |
Logged In: YES I don't see a clear resolution here. Is there something we |
Logged In: YES The changes to the codecs done in Python 2.4 added support Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> open("foo.py", "wb").write("# -*- coding: iso-8859-1
-*-\rprint 17\rprint 23\r")
>>> import foo
17
23
>>> |
Logged In: YES So this is resolved now? |
Logged In: YES It looks to me that way. Any comments from the OP? |
Logged In: YES Closing the bug. Thanks Walter. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: