xplicitly UTF-8:
>
> # no surprise, always decode file content from UTF-8
> json_file = open(filename, encoding="utf-8")
>
> --
>
> I will not comment PEP 686 here. It's being discussed on Discourse:
>
> * https://discuss.python.org/t/14435
> * https:/
Hi, all.
I wrote a new PEP last month.
I'm sorry that I forgot to announce it here.
The pep is here:
https://peps.python.org/pep-0686/
Discussions:
* https://discuss.python.org/t/14737 (current thread)
* https://discuss.python.org/t/14435 (previous thread)
--
Inada
python.org/issue47000
https://github.com/python/cpython/pull/32068
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.
age archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LA6U263OUVJ2RBFHFYNFXZ2QSCZHVVUW/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
chnique don't guarantee same benefit. Like gc.freeze() is
needed before immortalize to avoid CoW, some other tricks may be
needed too.
New article is welcome, but I want sample application we can run,
profile, and measure the benefits.
Regards,
--
Inada Naoki
On Wed, Feb 23, 2022 at 10:12 AM Eric Snow wrote:
>
> Thanks for the feedback. I've responded inline below.
>
> -eric
>
> On Sat, Feb 19, 2022 at 8:50 PM Inada Naoki wrote:
> > I hope per-interpreter GIL success at some point, and I know this is
> > needed for
all immortal objects during runtime finalization,
> we must keep track of them.
>
I don't think we need to clean up all immortal objects.
Of course, we should care immortal by default objects.
But for user-marked immortal objects, it's very difficult to guarantee
__del__ or weakr
ide some data, or drop the CoW issue from this PEP until
it is proved?
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/py
rtal to be shared between subinterpreters.
If the interned dict is belonging to interpreter, should we register
immortalized string to all interpreters?
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an
e reasonable limitations.
https://en.cppreference.com/w/cpp/language/union
XL C/C++ also support it. So we can use it if we decided to use it.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an e
gt; things out seem reasonable to me.
>
I like it. I want to use anonymous union. It makes complex structure
like PyDictKeysObject simple a little.
I confirmed that XLC supports it.
https://www.ibm.com/docs/en/xl-c-and-cpp-aix/13.1.3?topic=types-structures-unions#strct__anonstruct
Regards,
-
are not interned.
I think deepfreeze should stop using statically allocated strings for
interned strings too.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mai
.python.org/archives/list/python-dev@python.org/message/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email t
tate(module);
Py_IDENTIFIER_CLEAR(state->foo);
}
```
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-de
ecause user may want to use own libmysqlclient, and I don't
want to maintain binary linking OpenSSL.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https:/
change the pull request status. So I can ignore them.
I just explain "what the motivation approve without review repeatedly".
I don't watch the cpython repository so I am not suffered from spammy
approvals. So I have no vote for it. I just mention to an option we
have.
Regards,
--
In
or triage members but not merged yet.
> I know "drive by approvals" are annoying but I think it is unfortunately part
> of open source projects.
>
Sorry, but I don't think so.
--
Inada Naoki
___
Python-Dev mailin
-github-keeps-getting-better-for-open-source-maintainers/
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org
4bytes. And NULL can not store pointer. So upper bound of refcnt is
2**30-1.
So we have two free bits in the refcnt.
On 64bit machine, we have at least four free bits as same reason.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev
the
default behavior"?
Then, we do not need to decide "PEP 563 or 649".
We can focus on whether we can replace "stock semantics + opt-in PEP
563" with PEP 649 or not.
Regards,
--
Inada Naoki
___
Python-Dev mailing list --
period and I am
helping people to use new APIs. (*)
* e.g. https://github.com/jamesturk/cjellyfish/pull/12
So I don't want to increase the minimum required deprecation period.
But I agree that a longer deprecation period is good when keeping
deprecation st
ave the same (zero) cost. Yay!
But if SQLAlchemy starts using annotations, *all applications* using
SQLAlchemy will be impacted in the future.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-l
Memory consumption is cost on process lifetime.
And longer GC time is every time when full-GC is happened.
So performance is problem for both of short lifecycle applications
like CLI tools and long lifecycle applications like Web app.
Regards,
--
Inada Naoki
__
, `42`,
`"foo"` are not rewrote).
This tool can ease transition from PEP 563 to 649, and solve
performance issues too.
PEP 649 can have the performance as PEP 563 if all annotations are constants.
--
Inada Naoki
___
Python-Dev mail
ocstring, we can not
use -OO if a time set of module depends on docstring or assertion.
So I think we need some mechanizm to disable optimization like
dropping assertions, docstrings, and annotations per module.
--
Inada Naoki
___
Python-Dev mailin
thon-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/52VFBHR7AHTXPLC434E4BPXNXVUU3SVF/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada N
deprecating PEP 563.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https
> 2021/08/11 19:22、Paul Moore のメール:
>
> Also, I don't think that improving performance is a
> justification for a non-trivial backward compatibility break (I don't
> recall a case where we've taken that view in the past) so "PEP 649
> solves forward references without a backward compatibility imp
/archives/list/python-dev@python.org/message/2OOCEE6OMBQYEIJXEGFWIBE62VPIJHP5/
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/pytho
tion of PEP 649 has been suspended.
We need to revive it and measure performance/memory impact.
As far as I remember, the reference implementation created a function
object for each methods.
It means doubles function objects. It has major impact to memory
usage, startup time, and
+1
2021年7月29日(木) 19:46 Mark Shannon :
> Hi everyone,
>
> I would like to repeal PEP 509. We don't really have a process for
> repealing a PEP. Presumably I would just write another PEP.
>
> Before I do so, I would like to know if anyone thinks we should keep
> PEP 509.
>
> The dictionary version
FWIW, GitHub announced new powerful Issues today.
https://github.com/features/issues
It may fill some gap between GitHub Issues and Roundup.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
le ABIs already.
If I am wrong, can we stop keeping stable ABI at Python 3.12?
Python 4.0 won't come in foreseeable future. Stable ABI blocks Python evolution.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To uns
n do it in Python 3.12 or 3.13.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived a
e_SizeT().
> Could we remove or merge them after making PY_SSIZE_T_CLEAN not mandatory?
They are part of stable ABIs. So we can remove/merge them at Python 4.0.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsu
Python 3.12 will be released at 2023-10.
So we can change PY_SSIZE_T_CLEAN by default from 3.12.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail
So how about making PY_SSIZE_T_CLEAN not mandatory in Python 3.11?
Extension modules can use '#' format with ssize_t, without
PY_SSIZE_T_CLEAN defined.
Or should we wait one more version?
Regards,
--
Inada Naoki
___
Python-Dev mailing li
CC optimize ("O0")
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https:/
how DeprecationWarning.
And there are many scripts without tests.
So it is hidden for some people.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org
top suppressing DeprecationWarning by default
* Use at least one PendingDeprecationWarning and one DeprecationWarning.
* More than two PendingDeprecationWarning periods is preferred.
How do you think?
--
Inada Naoki
___
Python-Dev mailing list -- python-de
@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/J6GGEKUBMPU3X3WNKUG2XUD3GDV7L2FK/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki
(c) is broken by design. It is not fixable.
IMHO, We should chose (a) or (b) and reject any idea relying on Sequence ABC.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@p
``
# co_annotations
$ ./python ~/ann_test.py 3
code size: 236106 bytes
memory: 208261 bytes
unmarshal: avg: 653.788ms +/-1.257ms
exec: avg: 95.783ms +/-0.169ms
# optimize
$ ./python ~/ann_test.py 3
code size: 162097 bytes
memory: 208261 bytes
unmarshal: avg: 458.959ms +/-0.163ms
exec: avg: 98.327ms +
On Tue, Apr 20, 2021 at 4:24 PM Inada Naoki wrote:
>
> Just an idea: do not save co_name and co_firstlineno in code object
> for function annotations.
> When creating a function object from a code object, they can be copied
> from annotated function.
>
I created a pu
__
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ZAPCP4MFDO
As far as I know, both Pydantic and marshmallow start using annotation
for runtime type after PEP 563 is accepted. Am I right?
When PEP 563 is accepted, there are some tools using runtime type in
annotation, but they are not adopted widely yet.
But we didn't have any good way to emit DeprecationWa
/compile.c:1977
#13 0x55688e51 in compiler_class (c=c@entry=0x7fffc3d0,
s=s@entry=0x56222a60) at Python/compile.c:2623
#14 0x55687ce3 in compiler_visit_stmt (s=,
c=0x7fffc3d0) at Python/compile.c:3667
#15 compiler_body (c=c@entry=0x7fffc3d0, stmts=0x
ter PEP 563, only `'List[int]'` is practical so we can stop
supporting `List["int"]` and others at some point.
So playing with runtime type will become easier in the future.
Am I wrong?
--
Inada Naoki
___
Python-Dev mailing list -- p
.
Unlike simple function case, PEP 649 creates function object instead
of code object for __co_annotation__ of methods.
It cause this overhead. Can we avoid creating functions for each annotation?
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@py
se type hinting even after I dropped Python 3.9
support.
But it is up to release manager and steering council.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.p
from
eval(). If we implement a "lazy load" mechanizm for docstrings and
annotations, overhead will become cheaper.
* pyc file become bigger (but who cares?)
I will read PEP 649 implementation to find missing optimizations other
than GH-25419 and GH-230
TYPE_CHECKING` and manually stringified annotation is used
in real world applications.
I want to mix both use cases.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https:/
+/- 0.00016614519056599577
exec: avg: 0.09546191191766411 +/- 0.00018099485135812695
```
Summary:
* Both of PEP 563 and PEP 649 has low memory consumption than Python 3.9.
* Importing time (unmarshal+exec) is about 0.7sec on old semantics and
PEP 649, 0.43sec on PEP 563.
On Thu, Apr 15, 2021 at 10:31 AM Inada Naoki
/cpython/pull/23056 too.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https
se use case used only is a limited part of application. On the
other hand, type hint can be used almost everywhere in application
code base. It must cheap enough.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe
than OpenWrapper and DocDescripter.
Additionally, if we have same issue in other module, we can just use
staticmethod, instead of copy&paste OpenWrapper and DocDescripter.
So it provides "compensating practical benefit".
Regards,
--
Inada Naoki
__
On Tue, Apr 13, 2021 at 11:18 AM Paul Bryan wrote:
>
> On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:
>
> On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings wrote:
>
>
> This is really the heart of the debate over PEP 649 vs PEP 563. If you
> examine an annotati
On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings wrote:
>
>
> On 4/12/21 4:50 PM, Inada Naoki wrote:
>
> PEP 563 solves all problems relating to types not accessible in runtime.
> There are many reasons users can not get types used in annotations at runtime:
>
> * To avoid c
On Tue, Apr 13, 2021 at 8:58 AM Larry Hastings wrote:
>
> On 4/12/21 4:50 PM, Inada Naoki wrote:
>
> As PEP 597 says, eval() is slow. But it can avoidable in many cases
> with PEP 563 semantics.
>
> PEP 597 is "Add optional EncodingWarning". You said PEP 597 in o
at
> https://mail.python.org/archives/list/python-dev@python.org/message/QSASX6PZ3LIIFIANHQQFS752BJYFUFPY/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsub
On Thu, Apr 8, 2021 at 9:54 AM Inada Naoki wrote:
>
> We are close to 3.10 beta and it is not ideal timing for removing.
> So my proposal is:
>
> * Remove 'U' in fileinput, because it makes my task little simpler.
> * Remove 'U' in other places in Python 3.1
on-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/VTROKN5UOU3EN6F3OLX5RUK7TVETAXKB/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Nao
On Wed, Apr 7, 2021 at 11:29 PM Miro Hrončok wrote:
>
> On 07. 04. 21 14:53, Inada Naoki wrote:
> > 'U' mode was removed once and resurrected.
> > https://bugs.python.org/issue39674
> >
> > As far as I can see, it is postponed to Python 3.10. Am I right?
&
'U' mode was removed once and resurrected.
https://bugs.python.org/issue39674
As far as I can see, it is postponed to Python 3.10. Am I right?
Can we remove 'U' mode in Python 3.10?
Regards,
--
Inada Naoki
___
Python-Dev mailin
On Thu, Apr 1, 2021 at 11:52 AM Brett Cannon wrote:
>
> On Wed., Mar. 31, 2021, 18:56 Inada Naoki, wrote:
>>
>> Do we need _pyio at all?
>> Does PyPy or any other Python implementation use it?
>
> https://www.python.org/dev/peps/pep-0399/ would suggest rolling back
h.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/
On Wed, Mar 17, 2021 at 5:33 PM Paul Moore wrote:
>
> On Wed, 17 Mar 2021 at 08:13, Michał Górny wrote:
> >
> > On Wed, 2021-03-17 at 13:55 +0900, Inada Naoki wrote:
> > > OK. setuptools doesn't specify encoding at all. So locale-specific
> > > encoding
OK. setuptools doesn't specify encoding at all. So locale-specific
encoding is used.
We can not fix it in short term.
On Wed, Mar 17, 2021 at 4:56 AM Brett Cannon wrote:
>
>
>
> On Mon, Mar 15, 2021 at 7:53 PM Inada Naoki wrote:
>>
>> Hi, all.
>>
>> I
.
For paths, fsencoding is the right encoding. It is UTF-8 on Windows
(excpet PYTHONLEGACYWINDOWSFSENCODING is set), and locale-specific
encoding in Linux.
What encoding should we use?
* UTF-8
* sys.getfilesystemencoding()
* Keep status-quo.
Regards,
--
Inada Naoki
on Steering Council's gratitude,
> Thomas.
> --
> Thomas Wouters
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.o
thon 3.9 support and
use `encoding="locale"` where locale encoding is needed.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/li
/1272280760280637441
>
> Anyway, this is yet another SJW non-issue (countries other than US don't have
> a modern history of slavery) so this change is a political
> statement rather than has any technical merit.
>
Yes. If we don't change the name, we need to pay our energy to sa
Thank you for all.
I finally submit the PEP 597 with PYTHONWARNDEFAULTENCODING /
warn_default_encoding.
On Mon, Feb 15, 2021 at 2:28 PM Inada Naoki wrote:
>
> I am updating PEP 597 to include discussions in the thread.
> Before finishing the PEP, I need to decide the option name.
&
do you think? about PYTHON_WARN_DEFAULT_ENCODING?
---
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archiv
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list
ferences used
only type hints, or user can not get even string form annotation which
is very useful for REPLs.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.
c and will
find many possible bugs that happen only on Windows, even if they
don't use Windows daily development.
Isn't this option worth enough?
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an emai
ew
> environment variable, and maybe a new launch flag ... these all seem to risk
> just making things more complicated without sufficient gain.
>
> Would a recipe for site-packages be sufficient, or does this need to run too
> early in the bootstrapping process?
>
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 Wind
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: https
many places before the time. At least, we can
fix all EncodingWarning in stdlib.
Maybe, the "Prepare to change the default encoding to UTF-8" is misleading.
I will try to fix the section or remove the section.
--
Inada Naoki
___
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)
>
g)
with open(filename, encoding=encoding) with f:
return f.read()
This function is not warned. Caller of this function is warned
instead. It is difficult to implement in the Linter.
--
Inada Naoki
___
Python-Dev mailing list -- p
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@p
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
Don't touch -- You don't need to enable EncodingWarning.
* encoding=locale.getpreferredencoding(False) -- Backward compatible.
But doesn't work if you enabled UTF-8 mode.
* encoding="mbcs" -- Backward compatible. Works even when you enabled
UTF-8 mode. But it doesn't work
allation,
venv, or conda env).
But this is off topic. The thread for this topic is here.
https://mail.python.org/archives/list/python-id...@python.org/thread/LQVK2UKPSOI2AHYFUWK6ZII2U6QKK6BP/
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-
On Wed, Feb 10, 2021 at 5:50 AM Paul Moore wrote:
>
> On Tue, 9 Feb 2021 at 16:54, Inada Naoki wrote:
> >
> > On Tue, Feb 9, 2021 at 9:31 PM Paul Moore wrote:
> > >
> > > Personally, I'm not at all keen on the idea of making users always
> > >
On Wed, Feb 10, 2021 at 1:46 AM Anders Munch wrote:
>
>
> Inada Naoki wrote:
> > This warning is opt-in warning like BytesWarning.
>
> What use is a warning that no-one sees?
At least, I see.
We can fix stdlib and tests first, and fix some major tools too.
After th
. I want
to see how EncodingWarning and UTF-8 mode are adopted.
I want to implement both EncodingWarning and per-site UTF-8 mode
setting in Python 3.10.
5+ years later, we will see which approach is adopted by users.
* If EncodingWarning is widely adopted by many developer
;
This warning is opt-in warning like BytesWarning.
It will be a good tool to find potential problems for people knows
what is the problem.
But it is not recommended for users who don't understand what is the problem.
--
Inada Naoki
___
Python-
False)`?
I think only we can do is documenting the option like this:
"""
EncodingWarning is warning to find missing encoding="utf-8" option. It
is common pitfall that many Windows user
Don't try to fix them if you need to use locale specific encoding.
"""
I send a pull request https://github.com/python/peps/pull/1799
* Add Backward/Forward Compatibility section
* Add How to teach this section
* Remove io.LOCALE_ENCODING constant
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To
On Tue, Feb 2, 2021 at 1:40 PM Inada Naoki wrote:
>
> On Tue, Feb 2, 2021 at 12:23 AM Victor Stinner wrote:
> >
> >
> > > Add ``io.LOCALE_ENCODING = "locale"`` constant too. This constant can
> > > be used to avoid confusing ``LookupError: unknown e
gt; No.
>
> Hum. To write code compatible with Python 3.9, I understand that
> encoding=None is the closest to encoding="locale".
>
> And I understand that encoding=getattr(io, "LOCALE_ENCODING", None) is
> backward and forward compatible ;-)
>
&
On Tue, Feb 2, 2021 at 8:40 PM Inada Naoki wrote:
>
> On Tue, Feb 2, 2021 at 7:37 PM M.-A. Lemburg wrote:
> >
> > BTW: I don't understand this comment:
> > "They are inefficient on platforms wchar_t* is UTF-16. It is because
> > built-in codecs sup
On Tue, Feb 2, 2021 at 9:40 PM Emily Bowman wrote:
>
> On Tue, Feb 2, 2021 at 3:47 AM Inada Naoki wrote:
>>
>> But when wchar_t* is UTF-16, ucs2_utf8_encoder() can not handle
>> surrogate escape.
>> We need to use a temporary Unicode object. That is what "ineff
ucs4_utf8_encoder() can encode
wchar_t* into UTF-8.
But when wchar_t* is UTF-16, ucs2_utf8_encoder() can not handle
surrogate escape.
We need to use a temporary Unicode object. That is what "inefficient" means.
I will update the section more elaborate.
Regards,
--
Inada Naoki
_
On Tue, Feb 2, 2021 at 12:23 AM Victor Stinner wrote:
>
> Hi Inada-san,
>
> I followed the discussions on your different PEP and I like overall
> your latest PEP :-) I have some minor remarks.
>
> On Mon, Feb 1, 2021 at 6:55 AM Inada Naoki wrote:
> > The warning is di
become equal.
So please don't think PEP 624 neglect only wchar_t*.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/
1 - 100 of 538 matches
Mail list logo
