On Fri, Feb 12, 2021 at 12:45 PM Jim J. Jewett wrote:
>
> On Thu, Feb 11, 2021 at 7:35 PM Inada Naoki wrote:
>
> > The PEP helps developers living on UTF-8 locale to find missing
> > `encoding="utf-8"` bug.
> > This type of bug is very common, and many Windows users are suffered
> > by the bug
On Fri, Feb 12, 2021 at 12:28 PM Jim J. Jewett wrote:
>
> (I apologize if my summaries distort what Inada Naoki
> explained.)
>
> He said that some people use the default None when they really want
> either UTF-8 or ASCII.
Yes. Even Python core developers.
For example:
On 2/11/2021 3:23 PM, Michał Górny wrote:
Hello,
I'm the primary maintainer of CPython packages in Gentoo. I would like
to discuss possible improvement to the release process in order to
accelerate releasing security fixes to users.
I feel that vulnerability fixes do not make it to end users
On Thu, Feb 11, 2021 at 7:35 PM Inada Naoki wrote:
> The PEP helps developers living on UTF-8 locale to find missing
> `encoding="utf-8"` bug.
> This type of bug is very common, and many Windows users are suffered
> by the bug when reading JSON, YAML, TOML, Markdown, or any other UTF-8
> files.
(I apologize if my summaries distort what Inada Naoki
explained.)
He said that some people use the default None when they really want
either UTF-8 or ASCII.
My concern is that the warning will be a false alarm if they really do
need whatever locale returns, and that case may still be common.
I think the use case (for x.is_foo()) is rare. And instead of writing
x.is_foo(x), if you make the guard a function you can write is_foo(x).
On Thu, Feb 11, 2021 at 6:51 PM Sebastian Kreft wrote:
> I still think that we should reconsider deferring what happens to class
> and instance methods.
>
I still think that we should reconsider deferring what happens to class and
instance methods.
The arguments given in https://www.python.org/dev/peps/pep-0647/#id13 seem
insufficient, specially considering than the workaround provided is quite
awkward.
The author suggests to write def
On 2/11/21, Inada Naoki wrote:
>
> There is little difference between `encoding=None` and
> `encoding=locale.getpreferredencoding(False)`. The difference is:
>
> * When Python is using Windows, and
> * When when the file is console, and
> * (for open()) When PYTHONLEGACYWINDOWSSTDIO is set
> *
On Thu, Feb 11, 2021 at 4:44 PM Jim J. Jewett wrote:
>
> 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.
>
The PEP
On Fri, Feb 12, 2021 at 5:18 AM Jim J. Jewett wrote:
>
> Inada Naoki wrote:
>
> > Default encoding is used for:
>
> > a. Really need to use locale specific encoding
> > b. UTF-8 (bug. not work on Windows)
> > c. ASCII (not a bug, but slow on Windows)
>
> > I assume most usages are (b) and (c).
On Fri, Feb 12, 2021 at 6:34 AM Paul Moore wrote:
>
> On Thu, 11 Feb 2021 at 21:05, Jim J. Jewett wrote:
> >
> > Who will benefit from this new warning?
> >
> > Is this basically just changing builtins.open by adding:
> >
> > if encoding is None and sys.flags.encoding_warning: # and not
It means "I can't prove it matches". This should be clear from the spec
already (it's an important point actually, since it means type checkers
cannot narrow in an else clause). So please don't file a PR to "add" this.
On Thu, Feb 11, 2021 at 11:49 AM Jim J. Jewett wrote:
> If a TypeGuard
On Thu, 11 Feb 2021 at 21:05, Jim J. Jewett wrote:
>
> Who will benefit from this new warning?
>
> Is this basically just changing builtins.open by adding:
>
> if encoding is None and sys.flags.encoding_warning: # and not Android and
> not -X utf8 ?
>
Who will benefit from this new warning?
Is this basically just changing builtins.open by adding:
if encoding is None and sys.flags.encoding_warning: # and not Android and
not -X utf8 ?
warnings.warn(EncodingWarning("Are you sure you want locale instead of
utf-8?"))
Even for the
Hello,
I'm the primary maintainer of CPython packages in Gentoo. I would like
to discuss possible improvement to the release process in order to
accelerate releasing security fixes to users.
I feel that vulnerability fixes do not make it to end users fast enough.
For example, according to the
Inada Naoki wrote:
> Default encoding is used for:
> a. Really need to use locale specific encoding
> b. UTF-8 (bug. not work on Windows)
> c. ASCII (not a bug, but slow on Windows)
> I assume most usages are (b) and (c). This PEP can reduce them soon.
Is this just an assumption, based on
If a TypeGuard returns false, does that mean "it doesn't match", or just "I
can't prove it matches, but it still might"? That seems relevant to the else
clause ... and seems to have changed since the last version I looked at.
-jJ
___
Python-Dev
On Thu, Feb 11, 2021 at 12:00 AM Jim J. Jewett wrote:
> (1) Is it really a TypeGuard, or more of a TypeAssertion?
>
It's a query, not an assertion. The same concept is called type guard in
TypeScript.
> (2) Does this push too hard on "annotations only have one meaning"? If
> it has to
On Thu, Feb 11, 2021 at 4:44 PM Jim J. Jewett wrote:
>
> I just reread PEP 597, then re-reread the Rationale.
>
Do you read current PEP 597, or old PEP 597 in discuss.python.org?
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
19 matches
Mail list logo
