On Wed, 10 Feb 2021 at 01:29, Inada Naoki wrote:
> Note that many Python users don't use consoles.
I never suggested that they did. There's a GUI for setting user-level
and system-level environment variables. And whoever is introducing the
user to Python can show them how to set the necessary
On Wed, Feb 10, 2021 at 5:00 PM Paul Moore wrote:
>
> Let's just assume until you can convince me that setting UTF-8 mode
> globally is a good idea,
Oh, you misunderstood me. My proposal is not setting UTF-8 mode globally.
What I proposed is setting UTF-8 mode per env (e.g. installation,
venv,
Inada Naoki [mailto:songofaca...@gmail.com] wrote:
> There are several ways:
> * encoding="latin1" -- This is the best. Works perfectly.
> * Don't touch -- You don't need to enable EncodingWarning.
> [...]
I'm replying to Victor's statement that ``encoding="utf8" is backward
compatible´´.
If
Paul Moore [mailto:p.f.mo...@gmail.com]: wrote:
> On Wed, 10 Feb 2021 at 14:33, Anders Munch wrote:
>> The idea is to make is so that working code only needs to change once, even
>> when supporting multiple Python versions.
>> That one change is to add either an explicit encoding=None (for
>>
On 2/10/2021 10:29 AM, Paul Moore wrote:
On Wed, 10 Feb 2021 at 14:33, Anders Munch wrote:
The idea is to make is so that working code only needs to change once, even
when supporting multiple Python versions.
That one change is to add either an explicit encoding=None (for
On Wed, 10 Feb 2021 at 16:06, Anders Munch wrote:
>
> Paul Moore [mailto:p.f.mo...@gmail.com]: wrote:
> > On Wed, 10 Feb 2021 at 14:33, Anders Munch wrote:
> >> The idea is to make is so that working code only needs to change once,
> >> even when supporting multiple Python versions.
> >> That
> On 10 Feb 2021, at 01:28, Petr Viktorin wrote:
>
> On 2/9/21 9:15 PM, Serhiy Storchaka wrote:
>> 09.02.21 12:22, Erlend Aasland пише:
>>> What's the recommended approach with issues like
>>> https://bugs.python.org/issue43094? Change the docs or the implementation?
>>> I did a quick search
Thanks, Jakub.
E
> On 9 Feb 2021, at 19:42, Jakub Stasiak wrote:
>
> To provide some context as you looked for issues on bpo: in the two I was
> involved in[1][2] the resolution was to update the documenttion to reflect
> the actual situation.
>
> Best,
> Jakub
>
> [1]
On Tue, 9 Feb 2021 at 16:52, Anders Munch wrote:
>> How about swapping around "locale" and None? That is, make "locale" the new
>> default that emits a warning, and encoding=None emits no warning. That has
>> the advantage that old code can be updated to say encoding=None, and then it
>>
On Wed, Feb 10, 2021 at 1:46 AM Anders Munch wrote:
>> How about swapping around "locale" and None?
Inada Naoki wrote:
>
> I thought it, but it may not work. Consider about function like this:
>
> ```
> def read_text(self, encoding=None):
> with open(self._filename, encoding=encoding) as
On Wed, 10 Feb 2021 at 14:33, Anders Munch wrote:
>
> On Tue, 9 Feb 2021 at 16:52, Anders Munch wrote:
> >> How about swapping around "locale" and None? That is, make "locale" the
> >> new default that emits a warning, and encoding=None emits no warning.
> >> That has the advantage that old
Victor Stinner [mailto:vstin...@python.org] wrote:
> encoding="utf8" is backward compatible and is likely to fix encoding bugs
> when the locale encoding is not UTF-8
This program runs just fine on 3.8.7 Windows, against a file.txt that contains
latin-1 text:
with open('file.txt', 'rt') as f:
On Wed, Feb 10, 2021 at 11:14 PM Anders Munch wrote:
>
> This program runs just fine on 3.8.7 Windows, against a file.txt that
> contains latin-1 text:
>
> with open('file.txt', 'rt') as f:
> print(f.read())
>
> But if I change it to this:
>
> with open('file.txt', 'rt', encoding='utf-8') as
On Wed, Feb 10, 2021 at 11:58 PM Anders Munch wrote:
>
> On Wed, Feb 10, 2021 at 1:46 AM Anders Munch wrote:
> >> How about swapping around "locale" and None?
> Inada Naoki wrote:
> >
> > I thought it, but it may not work. Consider about function like this:
> >
> > ```
> > def read_text(self,
I just reread PEP 597, then re-reread the Rationale.
The PEP helps when the locale is ASCII or C, but that isn't enforced in actual
files. I am confident that this is a frequent problem for packages downloaded
from mostly-English sites, including many software repositories.
It does not seem
On Tue, Feb 9, 2021 at 9:51 PM Paul Moore wrote:
> * Realistically, I'd be surprised if developers actually use such a
> tool. If they were likely to do so, they could probably just as easily
> locate all the uses of open() in their code, and check that way. So
> I'm not sure this proposal is
The last time I noticed this question (probably around python 2.4?), it was
considered a deliberate decision.
There are languages with more open classes, such as (IIRC) Ruby and Smalltalk,
but Python chose to remain somewhat closed, because monkey-patching is
undesirable, and can be a problem
(1) Is it really a TypeGuard, or more of a TypeAssertion?
(2) Does this push too hard on "annotations only have one meaning"? If it has
to imported from typing, then probably not, but I think that is worth adding to
the PEP.
(3) Why can't the falsey case of an Optional String narrow to a set
18 matches
Mail list logo
