Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

Victor Stinner wrote: Users don't use stdin and stdout as regular files, they are more used as pipes to pass data between programs with the Unix pipe in a shell like "producer | consumer". Sometimes stdout is redirected to a file, but I consider that it is expected to behave as a pipe and the reg

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

> Or locale.getpreferredencoding() returns UTF-8 in UTF-8 mode too? Or should we change loale.getpreferredencoding() to return UTF-8 instead of ASCII always, regardless of PEP 538 and 540? INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

Looks nice. But I want to clarify more about difference/relationship between PEP 538 and 540. If I understand correctly: Both of PEP 538 (locale coercion) and PEP 540 (UTF-8 mode) shares same logic to detect POSIX locale. When POSIX locale is detected, locale coercion is tried first. And if loc

Re: [Python-Dev] iso8601 parsing

Guess the argument for limiting what it accepts would be that every funky variation will need to be supported until the endtimes, even those of little use or utility. On the other hand, it might be good to keep the two implementations the same for consistency reasons. Thanks either way, -Mik

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

I made the following two changes to the PEP 540: * open() error handler remains "strict" * remove the "Strict UTF8 mode" which doesn't make much sense anymore +1 — ignore my previous note. -CHB I wrote the Strict UTF-8 mode when open() used surrogateescape error handler in the UTF-8 mode. I d

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

I’m a bit confused: File names and the like are one thing, and the CONTENTS of files is quite another. I get that there is theoretically a “default” encoding for the contents of text files, but that is SO likely to be wrong as to be ignorable. open() already defaults to utf-8. Which is a fine de

Re: [Python-Dev] iso8601 parsing

>but is it that hard to parse arbitrary ISO8601 strings in once you've gotten this far? It's a bit uglier than I'd like, but not THAT bad a spec. No, and in fact this PR is adapted from a *more general* ISO-8601 parser that I wrote (which is now merged into master on python-dateutil). In the CP

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

On 12/7/2017 5:45 PM, Jonathan Goble wrote: On Thu, Dec 7, 2017 at 8:38 PM Glenn Linderman > wrote: If it were to be changed, one could add a text-mode option in 3.7, say "t" in the mode string, and a PendingDeprecationWarning for open calls without th

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

On Thu, Dec 7, 2017 at 8:38 PM Glenn Linderman wrote: > If it were to be changed, one could add a text-mode option in 3.7, say "t" > in the mode string, and a PendingDeprecationWarning for open calls without > the specification of either t or b in the mode string. > "t" is already supported in o

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

On 12/7/2017 4:48 PM, Victor Stinner wrote: Ok, now comes the real question, open(). For open(), I used the example of a code snippet *writing* the content of a directory (os.listdir) into a text file. Another example is to read filenames from a text files but pass-through undecodable bytes tha

[Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

Hi, I made the following two changes to the PEP 540: * open() error handler remains "strict" * remove the "Strict UTF8 mode" which doesn't make much sense anymore I wrote the Strict UTF-8 mode when open() used surrogateescape error handler in the UTF-8 mode. I don't think that a Strict UTF-8 mod

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

2017-12-08 0:26 GMT+01:00 Guido van Rossum : > You will quickly get decoding errors, and that is INADA's point. (Unless you > use encoding='Latin-1'.) His worry is that the surrogateescape error handler > makes it so that you won't get decoding errors, and then the failure mode is > much harder to

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

On Thu, Dec 7, 2017 at 3:02 PM, Victor Stinner wrote: > 2017-12-06 5:07 GMT+01:00 INADA Naoki : > > And opening binary file without "b" option is very common mistake of new > > developers. If default error handler is surrogateescape, they lose a > chance > > to notice their bug. > > To come back

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

2017-12-06 5:07 GMT+01:00 INADA Naoki : > And opening binary file without "b" option is very common mistake of new > developers. If default error handler is surrogateescape, they lose a chance > to notice their bug. To come back to your original point, I didn't know that it was a common mistake t

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

While I'm not strongly convinced that open() error handler must be changed for surrogateescape, first I would like to make sure that it's really a very bad idea because changing it :-) 2017-12-07 7:49 GMT+01:00 INADA Naoki : > I just came up with crazy idea; changing default error handler of open

Re: [Python-Dev] iso8601 parsing

> And I'm sorry, I got a bit lost in the PR, but you are attaching an > "offset" tzinfo, when parsing an iso string that has one, yes? Yes, a fixed offset time zone (since the original zone information is lost): >>> from dateutil import tz >>> from datetime import datetime >>> datetim

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

On 12/7/17 3:27 PM, Raymond Hettinger wrote: ... I'm looking for guidance or workarounds for two issues that have arisen. First, the use of default values seems to completely preclude the use of __slots__. For example, this raises a ValueError: class A: __slots__ = ['x', 'y']

[Python-Dev] Issues with PEP 526 Variable Notation at the class level

Both typing.NamedTuple and dataclasses.dataclass use the somewhat beautiful PEP 526 variable notations at the class level: @dataclasses.dataclass class Color: hue: int saturation: float lightness: float = 0.5 and class Color(typing.NamedTuple): hue: i

Re: [Python-Dev] iso8601 parsing

On Wed, Dec 6, 2017 at 3:07 PM, Paul Ganssle wrote: > Here is the PR I've submitted: > > https://github.com/python/cpython/pull/4699 > > The contract that I'm supporting (and, I think it can be argued, the only > reasonable contract in the intial implementation) is the following: > > dtstr =

[Python-Dev] Announcing importlib_resources 0.1

Brett and I have been working on a little skunkworks project for a few weeks, and it’s now time to announce the first release. We’re calling it importlib_resources and its intent is to replace the “Basic Resource Access” APIs of pkg_resources with more efficient implementations based directly o