[Python-Dev] Re: [python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

2022-04-08 Thread Inada Naoki
itly 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://discuss.p

[Python-Dev] PEP 686 – Make UTF-8 mode default

2022-04-07 Thread Inada Naoki
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 Naoki

[Python-Dev] Re: [python-committers] [IMPORTANT] Preparations for 3.11.0 beta 1

2022-04-06 Thread Inada Naoki
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.

[Python-Dev] Re: New PEP website is horrible to read on mobile device

2022-03-16 Thread Inada Naoki
rchived 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 To u

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

2022-02-22 Thread Inada Naoki
tee 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 ___ Pytho

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)

2022-02-22 Thread 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 per-

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)

2022-02-19 Thread Inada Naoki
ng 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 weakref callback is called safely. Addi

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

2022-02-16 Thread Inada Naoki
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/python-dev.python

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

2022-02-15 Thread Inada Naoki
ed 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 email to pytho

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

2022-02-11 Thread Inada Naoki
ions. 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 email to python-dev-l

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

2022-02-09 Thread Inada Naoki
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, -- Inada Naoki ___

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

2022-02-07 Thread Inada Naoki
k 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://mail.python.org/mailman3/lis

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

2022-02-07 Thread Inada Naoki
v@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 to python-dev-le...@python.org >

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

2022-02-02 Thread Inada Naoki
e); 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-dev.python.o

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

2022-01-30 Thread Inada Naoki
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, -- Inada Naoki ___

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

2022-01-29 Thread Inada Naoki
riage 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 mailing list -- pytho

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

2022-01-29 Thread Inada Naoki
-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.

[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

2022-01-05 Thread Inada Naoki
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

[Python-Dev] Re: The current state of typing PEPs

2021-11-29 Thread Inada Naoki
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 --

[Python-Dev] Re: Do we need to remove everything that's deprecated?

2021-11-14 Thread Inada Naoki
od 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 stuff has ne

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-23 Thread Inada Naoki
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-le...@python.org http

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-23 Thread Inada Naoki
ry 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 ___

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-20 Thread 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 mailing l

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-20 Thread Inada Naoki
e docstring, 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 mai

[Python-Dev] Re: Regressions caused the recent work on ceval.c and frame objects

2021-09-20 Thread Inada Naoki
n.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 Naoki _

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

2021-08-12 Thread Inada Naoki
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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

2021-08-11 Thread Inada Naoki
> 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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

2021-08-10 Thread Inada Naoki
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/python-dev.python.or

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

2021-08-09 Thread Inada Naoki
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 GC time. There was an idea to avoid creating function objec

[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)

2021-07-29 Thread Inada Naoki
+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

[Python-Dev] Re: [python-committers] Roundup to GitHub Issues migration

2021-06-23 Thread Inada Naoki
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

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-09 Thread Inada Naoki
Is 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 unsubscribe sen

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-08 Thread Inada Naoki
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 at https:/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-07 Thread Inada Naoki
> 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 unsubscribe se

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-07 Thread Inada Naoki
ule 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

[Python-Dev] Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-06 Thread Inada Naoki
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 list -- python-dev@python.org

[Python-Dev] Re: GDB not breaking at the right place

2021-05-25 Thread Inada Naoki
timize ("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://mail

[Python-Dev] Re: Using FutureWarning for last version before deletion.

2021-05-11 Thread Inada Naoki
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/mailman3/lists

[Python-Dev] Using FutureWarning for last version before deletion.

2021-05-10 Thread Inada Naoki
uppressing 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-dev@

[Python-Dev] Re: Can't sync cpython main to my fork

2021-05-06 Thread Inada Naoki
> https://mail.python.org/archives/list/python-dev@python.org/message/J6GGEKUBMPU3X3WNKUG2XUD3GDV7L2FK/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Inada Naoki ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe s

[Python-Dev] Re: Keeping Python a Duck Typed Language.

2021-04-22 Thread Inada Naoki
ken 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...@python.org

[Python-Dev] Re: PEP 563 in light of PEP 649

2021-04-20 Thread Inada Naoki
`` # 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 +

[Python-Dev] Re: PEP 563 in light of PEP 649

2021-04-20 Thread Inada Naoki
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] Re: PEP 563 in light of PEP 649

2021-04-20 Thread Inada Naoki
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/ZAPCP4MFDOF34E3G2TWAVY7JUQRHDOOB/ > Code o

[Python-Dev] Re: In support of PEP 649

2021-04-18 Thread Inada Naoki
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

[Python-Dev] Re: PEP 563 in light of PEP 649

2021-04-17 Thread Inada Naoki
7fffc3d0, 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=0x563014c0) at Python/compile.c:1977 #16 0x5568db00 in compi

[Python-Dev] Re: In support of PEP 649

2021-04-16 Thread Inada Naoki
t;]` 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 -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-15 Thread Inada Naoki
like 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@python.

[Python-Dev] Re: In support of PEP 649

2021-04-15 Thread Inada Naoki
nting 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.python.org/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-15 Thread Inada Naoki
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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-14 Thread Inada Naoki
ECKING` 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://mail.pyth

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-14 Thread Inada Naoki
+/- 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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-14 Thread 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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-13 Thread Inada Naoki
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 send an email to python-dev-le...@

[Python-Dev] Making staticmethod callable, any oposite?

2021-04-13 Thread Inada Naoki
DocDescripter. Additionally, if we have same issue in other module, we can just use staticmethod, instead of copy OpenWrapper and DocDescripter. So it provides "compensating practical benefit". Regards, -- Inada Naoki ___ Python-Dev mailin

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-12 Thread 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 annot

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-12 Thread Inada Naoki
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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-12 Thread Inada Naoki
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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-12 Thread Inada Naoki
gt; 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 unsubscrib

[Python-Dev] Re: When we remove 'U' mode of open()?

2021-04-07 Thread Inada Naoki
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.11, after 3.10 b

[Python-Dev] Re: When we remove 'U' mode of open()?

2021-04-07 Thread Inada Naoki
ttps://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 Naoki _

[Python-Dev] Re: When we remove 'U' mode of open()?

2021-04-07 Thread Inada Naoki
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? > > C

[Python-Dev] When we remove 'U' mode of open()?

2021-04-07 Thread Inada Naoki
'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 mailing list -- python-dev

[Python-Dev] Re: Weird io.OpenWrapper hack to use a function as method

2021-04-01 Thread Inada Naoki
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

[Python-Dev] Re: Weird io.OpenWrapper hack to use a function as method

2021-03-31 Thread 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/python-dev@pyth

[Python-Dev] Re: pth file encoding

2021-03-17 Thread Inada Naoki
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 is us

[Python-Dev] Re: pth file encoding

2021-03-16 Thread Inada Naoki
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 found

[Python-Dev] pth file encoding

2021-03-15 Thread Inada Naoki
. 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

[Python-Dev] Re: Accepting PEP 624 (Remove Py_UNICODE encoder APIs)

2021-03-15 Thread Inada Naoki
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.org To unsubscri

[Python-Dev] Re: [python-committers] Re: Accepting PEP 597 (Add optional EncodingWarning)

2021-03-15 Thread Inada Naoki
upport 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/lists/python

[Python-Dev] Re: Steering Council update for February

2021-03-09 Thread Inada Naoki
> > 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 same discussion every year. It i

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

2021-02-21 Thread Inada Naoki
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. &

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

2021-02-19 Thread Inada Naoki
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

[Python-Dev] PEP 597 bikeshedding: envvar / option name.

2021-02-14 Thread Inada Naoki
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

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

2021-02-14 Thread Inada Naoki
ces 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.org h

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-13 Thread Inada Naoki
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 email to python-dev

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-12 Thread Inada Naoki
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? >

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-11 Thread Inada Naoki
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

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-11 Thread Inada Naoki
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

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-11 Thread Inada Naoki
e 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 ___ Python-Dev mailing l

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-11 Thread 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) >

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-11 Thread Inada Naoki
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 -- python-dev@

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-11 Thread Inada Naoki
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

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-10 Thread Inada Naoki
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

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-10 Thread Inada Naoki
arning. * 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 only on Windows. Regards, -- Inada Naoki ___

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-10 Thread Inada Naoki
ion, 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-dev@p

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-09 Thread Inada Naoki
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 > > > spec

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-09 Thread Inada Naoki
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

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-09 Thread Inada Naoki
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 developers, we can discuss approach (a). * If UTF-8 mode be

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-09 Thread Inada Naoki
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-Dev mailing lis

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-09 Thread Inada Naoki
)`? 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. """ -- Inada

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-06 Thread Inada Naoki
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

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-06 Thread Inada Naoki
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: unknow

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-04 Thread Inada Naoki
th 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 ;-) > > Well, encoding=None will hopefully remain acce

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

2021-02-04 Thread Inada Naoki
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 supports

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

2021-02-02 Thread Inada Naoki
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

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

2021-02-02 Thread Inada Naoki
ncoder() 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 _

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

2021-02-01 Thread 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

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

2021-02-01 Thread Inada Naoki
al. 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/python-dev.pyth

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

2021-02-01 Thread Inada Naoki
s? > That would keep extensions working after a recompile, since > Py_UNICODE is already a typedef to wchar_t. > That idea is written in the PEP already. https://www.python.org/dev/peps/pep-0624/#replace-py-unicode-with-wchar-t Regards, -- Inada Naoki ___

  1   2   3   4   5   6   >