[issue17852] Built-in module _io can lose data from buffered files in reference cycles

2020-11-26 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset c8aaf71dde464c0c351e2f935f87652c3d54 by Volker-Weissmann in 
branch 'master':
 bpo-17852: Doc: Fix the tutorial about closing files (GH-23135)
https://github.com/python/cpython/commit/c8aaf71dde464c0c351e2f935f87652c3d54


--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue17852>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41103] Removing old buffer support

2020-11-25 Thread Inada Naoki


Inada Naoki  added the comment:

Thank you for reporting. I removed these APIs to get such feedback as early as 
possible.

We are free to revive these APIs if it breaks too much and some projects can 
not be fixed before Python 3.10 release.

Some project maintainers ignore deprecations and wait compile errors to fix 
soemthing. (e.g. 
https://github.com/rogerbinns/apsw/issues/288#issuecomment-62322)
That's why we need to break some projects during alpha phase.


> What is the benefit of removing this? Is copy pasting the compatibility layer 
> to (possibly many) different projects worth the "cleanup"?

Oh, no need to copy-paste compatibility layer for all projects. They can 
migrate to new APIs.

--

___
Python tracker 
<https://bugs.python.org/issue41103>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42202] Optimize function annotation

2020-11-25 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42202] Optimize function annotation

2020-11-25 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset 7301979b23406220510dd2c7934a21b41b647119 by Yurii Karabas in 
branch 'master':
bpo-42202: Store func annotations as a tuple (GH-23316)
https://github.com/python/cpython/commit/7301979b23406220510dd2c7934a21b41b647119


--

___
Python tracker 
<https://bugs.python.org/issue42202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals

2020-11-22 Thread Inada Naoki


Inada Naoki  added the comment:

> I don't think we need two algorithms here. I'm +1 to add str.dedent() which 
> mirroring only inspect.cleandoc().

I withdraw this.  If we add str.dedent(), it must not be optimized for 
triple-quote literal.

Auto dedenting is very nice to have. It can be different from 
inspect.cleandoc().

We may able to cleandoc() automatically, even without `from __future__`. This 
can be different from str.dedent() or auto dedenting.

We already have a separate issue for docstring. And auto dedenting will needs 
PEP. How about focus on str.dedent() and change the issue title?

--

___
Python tracker 
<https://bugs.python.org/issue36906>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals

2020-11-21 Thread Inada Naoki


Inada Naoki  added the comment:

> (1) add a .dedent() method to str (and bytes?) - behaviors to consider 
> mirroring are textwrap.dedent() and inspect.cleandoc().  Given their utility 
> and similarities, it makes sense to offer both behaviors; behavior could be 
> selected by a kwarg passed to the method.

I don't think we need two algorithms here. I'm +1 to add str.dedent() which 
mirroring only inspect.cleandoc().

--

___
Python tracker 
<https://bugs.python.org/issue36906>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42202] Optimize function annotation

2020-11-18 Thread Inada Naoki


Change by Inada Naoki :


--
nosy: +lukasz.langa

___
Python tracker 
<https://bugs.python.org/issue42202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42202] Optimize function annotation

2020-11-17 Thread Inada Naoki


Inada Naoki  added the comment:

I don't like co_annotations.

* It changes PyCode_NewXXX() API.

* Many functions don't have annotations. Adding annotation to code object makes 
code object fatter even if the function doesn't have annotation.

* Code object is immutable & hashable. Adding annotation to code object makes 
== and hash() complex.

* We may introduce lazy loading for docstring and annotation in the future.


func.__annotations__ =  ('x', 'int', 'z', 'float', 'return', 'Hoge') is much 
better because:

* Zero overhead for functions without any annotations.
* After annotation dict is created, the tuple can be released.

--

___
Python tracker 
<https://bugs.python.org/issue42202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42202] Optimize function annotation

2020-11-16 Thread Inada Naoki


Inada Naoki  added the comment:

> Yes, but the code for creating a dict can be simpler. In any case we will 
> better see what format is better when try to write a code.

Note that many annotations are not accessed. RAM usage of annotation 
information is important than how easy to create dict.

I don't like `(('x', 'int'), ('z', 'float'), ('return', 'Hoge'))` because it 
creates 4 tuples. It means use more memory, load pyc slower.

Please use ('x', 'int', 'z', 'float', 'return', 'Hoge') instead.

--

___
Python tracker 
<https://bugs.python.org/issue42202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24886] open fails randomly on AIX

2020-11-13 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue24886>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42141] Speedup various dict inits

2020-11-12 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> rejected

___
Python tracker 
<https://bugs.python.org/issue42141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42179] Clarify chaining exceptions in tutorial/errors.rst

2020-11-08 Thread Inada Naoki

Inada Naoki  added the comment:

>> 1. Such understanding of a tutorial is debatable. Tutorial is just a 
>> material for learning written with some system in mind, which is more 
>> interesting to read than dry reference material. A tutorial, generally 
>> dpeaking, may be both for beginners and for professionals.
>
> OK, I will send this topic to python-dev first.

For the record, there is a long thread in python-dev about this issue:

* main thread: 
https://mail.python.org/archives/list/python-...@python.org/thread/MXMEFFYB6JXAKSS36SZ7DX4ASP6APWFP/
* another thread: 
https://mail.python.org/archives/list/python-...@python.org/thread/WNHVZLEO3ZVDOFP2FHRBUQR4GY24RIJJ/

## High level discussion: focus on new user vs write more and more details.

More detail:
* Abdur-Rahmaan Janhangeer

Focus on new user:
* Paul Moore 
* Brett Cannon
* Guido van Rossum
* Kyle Stanley
* Carol Willing
* Serhiy Storchaka

## About this specific case. (Adding __context__ and __suppress_context vs 
removing __cause__)

Add __context__:
(no one)

Remove __cause__:
* Kyle Stanley
* Éric Araujo (in GH-23160)

Riccardo Polignieri asked that to be very careful about removing something, but 
he did not vote for adding __context__ and __supress_context__.

--

I merged PR-23162 for keep focus on new users and consistent for now.

But I have not closed this issue yet because documentation WG may revisit the 
issue. (see 
https://mail.python.org/archives/list/python-...@python.org/message/IWW2YBLJK4T3OWSKDUDVDVXPWDGIFWTC/
 ).

--

___
Python tracker 
<https://bugs.python.org/issue42179>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11346] Generator object should be mentioned in gc module document

2020-11-06 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue11346>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42179] Clarify chaining exceptions in tutorial/errors.rst

2020-11-05 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset bde33e428d5b5f88ec7667598fd27d1091840537 by Inada Naoki in branch 
'master':
bpo-42179: Doc/tutorial: Remove mention of __cause__ (GH-23162)
https://github.com/python/cpython/commit/bde33e428d5b5f88ec7667598fd27d1091840537


--

___
Python tracker 
<https://bugs.python.org/issue42179>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42179] Clarify chaining exceptions in tutorial/errors.rst

2020-11-05 Thread Inada Naoki


Change by Inada Naoki :


--
pull_requests: +22074
pull_request: https://github.com/python/cpython/pull/23162

___
Python tracker 
<https://bugs.python.org/issue42179>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37826] Document PEP 3134 in tutorials/errors.rst

2020-11-05 Thread Inada Naoki


Change by Inada Naoki :


--
nosy: +methane
nosy_count: 4.0 -> 5.0
pull_requests: +22073
pull_request: https://github.com/python/cpython/pull/23162

___
Python tracker 
<https://bugs.python.org/issue37826>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42179] Clarify chaining exceptions in tutorial/errors.rst

2020-11-05 Thread Inada Naoki

Inada Naoki  added the comment:

> 1. Such understanding of a tutorial is debatable. Tutorial is just a material 
> for learning written with some system in mind, which is more interesting to 
> read than dry reference material. A tutorial, generally dpeaking, may be both 
> for beginners and for professionals.

OK, I will send this topic to python-dev first.

> 2. The question about exception chaining is popular on Stackoverflow in 
> people who came to Python with Java or C# background (see “python inner 
> exception”).
> 3. Whatever material is given, it should not cause confusion, but now it does.

I searched it but I can not find confusion caused by this tutorial section. 
Please write a concrete URL caused by current tutorial?

> Since this section has been added recently, it is better to fix it rather 
> than remove entirely, aren’t you agree?

I prefer removing mention to __cause__, instead of adding mention to 
__context__.

No need to remove entire section. We can introduce high level overview of 
context chaining. Describing the default behavior and "from None" is enough for 
new users.

--

___
Python tracker 
<https://bugs.python.org/issue42179>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42179] Clarify chaining exceptions in tutorial/errors.rst

2020-11-04 Thread Inada Naoki


Inada Naoki  added the comment:

Please note that tutorial is a tutorial. It is document to help new user who 
are learning Python.
Do you believe special attributes like __cause__ and __contexts__ are really 
worth to teach for tutorial readers?

Generally speaking, I think we should *reduce* some details from tutorial.

--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue42179>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42049] Add image/webp to list of media types in mimetypes.py

2020-11-03 Thread Inada Naoki


Change by Inada Naoki :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42049>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42205] Add image/webp to list of non-standard mimetypes

2020-11-03 Thread Inada Naoki


Change by Inada Naoki :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42205>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38902] image/webp support in mimetypes

2020-11-03 Thread Inada Naoki


Inada Naoki  added the comment:

I'm +1 to add it in common types, because webp is really de-facto standard.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types

If no objection, I will merge this in next week.

--
nosy: +methane
versions: +Python 3.10 -Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38902>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42205] Add image/webp to list of non-standard mimetypes

2020-11-03 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> duplicate
superseder:  -> image/webp support in mimetypes

___
Python tracker 
<https://bugs.python.org/issue42205>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42049] Add image/webp to list of media types in mimetypes.py

2020-11-03 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> duplicate
superseder:  -> image/webp support in mimetypes

___
Python tracker 
<https://bugs.python.org/issue42049>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42236] os.device_encoding() doesn't respect the UTF-8 Mode

2020-11-02 Thread Inada Naoki


Inada Naoki  added the comment:

I don't think UTF-8 mode should override os.device_encoding() on Windows.

UTF-8 mode can be used to ignore legacy locale encoding, and 
os.device_encoding() uses the locale encoding on Unix. So overriding it make 
sense.

But locale encoding and console cp are different on Windows. Users may want to 
know console cp even when they want to use UTF-8 by default for reading/writing 
text files.

--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue42236>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-11-02 Thread Inada Naoki


Inada Naoki  added the comment:

While this is an interesting optimization, the gain is not enough.
I close this issue for now.

@Marco Sulla
Optimizing dict is a bit hard job. If you want to continue, I have an idea:
`dict(zip(keys, row))` is common use case. It is used by asdict() in datacalss, 
_asdict() in namedtuple, and csv DictReader.
Sniffing zip object and presizing dict may be interesting optimization.

But note that this idea has low chance of accepted too. We tries many ideas 
like this and reject them by ourselves even without creating a pull request.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-11-02 Thread Inada Naoki


Inada Naoki  added the comment:

And bench_kwcall.py is a microbenchmark for _PyEval_EvalCode.

$ cpython/release/python -m pyperf compare_to master.json kwcall-nodup.json

kwcall-3: Mean +- std dev: [master] 192 us +- 2 us -> [kwcall-nodup] 175 us +- 
1 us: 1.09x faster (-9%)
kwcall-6: Mean +- std dev: [master] 327 us +- 6 us -> [kwcall-nodup] 291 us +- 
4 us: 1.12x faster (-11%)
kwcall-9: Mean +- std dev: [master] 436 us +- 10 us -> [kwcall-nodup] 373 us +- 
5 us: 1.17x faster (-14%)

Geometric mean: 0.89 (faster)

--
Added file: https://bugs.python.org/file49561/bench_kwcall.py

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-11-02 Thread Inada Naoki


Inada Naoki  added the comment:

Short result (minspeed=2):

Slower (4):
- unpack_sequence: 65.2 ns +- 1.3 ns -> 69.2 ns +- 0.4 ns: 1.06x slower (+6%)
- unpickle_list: 5.21 us +- 0.04 us -> 5.44 us +- 0.02 us: 1.04x slower (+4%)
- chameleon: 9.80 ms +- 0.08 ms -> 10.0 ms +- 0.1 ms: 1.02x slower (+2%)
- logging_silent: 202 ns +- 5 ns -> 206 ns +- 5 ns: 1.02x slower (+2%)

Faster (9):
- pickle_dict: 30.7 us +- 0.1 us -> 29.0 us +- 0.1 us: 1.06x faster (-5%)
- scimark_lu: 169 ms +- 3 ms -> 163 ms +- 3 ms: 1.04x faster (-4%)
- sympy_str: 396 ms +- 8 ms -> 383 ms +- 5 ms: 1.04x faster (-3%)
- sqlite_synth: 3.46 us +- 0.08 us -> 3.34 us +- 0.04 us: 1.03x faster (-3%)
- scimark_fft: 415 ms +- 3 ms -> 405 ms +- 3 ms: 1.03x faster (-3%)
- pickle_list: 4.91 us +- 0.07 us -> 4.79 us +- 0.04 us: 1.03x faster (-3%)
- dulwich_log: 82.4 ms +- 0.8 ms -> 80.4 ms +- 0.8 ms: 1.02x faster (-2%)
- scimark_sparse_mat_mult: 5.49 ms +- 0.03 ms -> 5.37 ms +- 0.02 ms: 1.02x 
faster (-2%)
- spectral_norm: 157 ms +- 1 ms -> 153 ms +- 4 ms: 1.02x faster (-2%)

Benchmark hidden because not significant (47): ...

Geometric mean: 1.00 (faster)

Long result is attached.

--
Added file: https://bugs.python.org/file49560/pr23106.txt

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42126] Optimize BUILD_CONST_KEY_MAP for distinct keys

2020-11-02 Thread Inada Naoki


Inada Naoki  added the comment:

OK. Microbenchmark don't justify adding complexity to the eval loop and the 
compiler.

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42126>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-11-02 Thread Inada Naoki


Inada Naoki  added the comment:

> I did PGO+LTO... --enable-optimizations --with-lto

I'm sorry about that. PGO+LTO *reduce* noises, but there are still noises. And 
unpack_sequence is very fragile.
I tried your branch again, and unpack_sequence is 10% *slower* than master 
branch.

I am running pyperformance with PR-23106, which simplifies your function and 
use it from _PyStack_AsDict() and _PyEval_EvalCode().

--
stage: patch review -> 

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-11-02 Thread Inada Naoki


Change by Inada Naoki :


--
pull_requests: +22023
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23106

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42160] unnecessary overhead in tempfile

2020-10-31 Thread Inada Naoki


Change by Inada Naoki :


--
pull_requests: +21987
pull_request: https://github.com/python/cpython/pull/23068

___
Python tracker 
<https://bugs.python.org/issue42160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-10-31 Thread Inada Naoki


Inada Naoki  added the comment:

> It should *not* be affected by the change. Anyway, I run the bench other 10 
> times, and the lowest value with the CPython code without the PR is not lower 
> than 67.7 ns. With the PR, it reaches 53.5 ns. And I do not understand why.

The benchmark is very affected by code placement.
Even adding dead function affects speeds. Read vstinner's blog and presentation:

* https://vstinner.github.io/journey-to-stable-benchmark-deadcode.html
* https://speakerdeck.com/haypo/how-to-run-a-stable-benchmark?slide=9

That's why we recommend PGO+LTO build for benchmarking.

--

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42217] compiler: merge co_code and co_lnotab

2020-10-31 Thread Inada Naoki


Inada Naoki  added the comment:

@Serhiy 

> Do you mean sharing values of co_code and co_lnotab between code objects of 
> the same module?

Yes.

> How much memory does this save (in absolute and relative value)?

Maybe 1~3%, but I am not sure. I am more interested in reducing number of 
objects, because it will reduce import time.
Additionally, co_code is used while executing code. Unlike other cold data 
(e.g. docstring, annotations), sharing co_code will improve CPU cache 
utilization.

> Which functions have the same co_code?

For example,

```
# logging/__init__.py

@property
def manager(self):
return self.logger.manager
...
@property
def name(self):
return self.logger.name
```

Such simple functions are very common in OO-style code.

@Mark Shannon

Sure.

--

___
Python tracker 
<https://bugs.python.org/issue42217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-10-31 Thread Inada Naoki


Inada Naoki  added the comment:

> Both changes add significant amount of code (100 and 85 lines 
> correspondingly). Even if they speed up a particular case of dict constructor 
> it is not common use case.

You are right, but please wait.

Marco is new contributor and he can write correct C code for now.
So I am searching some parts which can be optimized by his code before 
rejecting it.

* bpo-42126, GH-22911: I can make dict display (aka. dict literal) 50% faster. 
But it introduce additional complexity to compiler and ceval. So I will reject 
it unless I find real world code using dict display in performance critical 
part.

* _PyStack_AsDict (https://github.com/methane/cpython/pull/25): I thought this 
is performance critical function. But I could not see significant performance 
gain in pyperformance.

* _PyEval_EvalCode 
(https://github.com/python/cpython/blob/master/Python/ceval.c#L4465): I am 
still not sure we can assume there are no duplicated keyword argument here. If 
we can assume it, we can optimize calling function receiving **kwds argument.

These three parts are all I found. I will reject this issue after I failed to 
optimize _PyEval_EvalCode.

--

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42217] compiler: merge co_code and co_lnotab

2020-10-31 Thread Inada Naoki


Change by Inada Naoki :


--
keywords: +patch
pull_requests: +21975
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23056

___
Python tracker 
<https://bugs.python.org/issue42217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42217] compiler: merge co_code and co_lnotab

2020-10-31 Thread Inada Naoki


New submission from Inada Naoki :

co_consts are merged already, but I forget about code attributes other than 
co_consts.
Duplication ratio is vary by code style, but in case of logging, we can reduce 
25% of them.

```
>>> data = open('Lib/logging/__pycache__/__init__.python-310.pyc', 'rb').read()
>>> import marshal
>>> x = []
>>> def walk(c):
... x.append(c.co_code)
... x.append(c.co_lnotab)
... for cc in c.co_consts:
... if hasattr(cc, 'co_code'):
... walk(cc)
...
>>> code = marshal.loads(data[16:])
>>> walk(code)
>>> len(x)
336
>>> len(set(x))
249
>>> 249/336
0.7410714285714286
```

--
components: Interpreter Core
messages: 380045
nosy: methane
priority: normal
severity: normal
status: open
title: compiler: merge co_code and co_lnotab
type: resource usage
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42216] Optimize dict.popitem() & insert use case.

2020-10-30 Thread Inada Naoki


Inada Naoki  added the comment:

> But `dict.popitem()` returns the last item in the insertion order. The item 
> must be the last item of collision chain too.

This assumption was wrong. Inserting new item may overwrite dummy entry. In 
this case, the last item in the middle of collision chain.

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42216>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42160] unnecessary overhead in tempfile

2020-10-30 Thread Inada Naoki


Inada Naoki  added the comment:

@Deric-W Please create another PR to change from `choise` to `choises` if you 
want to optimize it.

--

___
Python tracker 
<https://bugs.python.org/issue42160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42160] unnecessary overhead in tempfile

2020-10-30 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset 43ca084c88d1e46a44199f347c72e26db84903c9 by Inada Naoki in branch 
'master':
Revert "bpo-42160: tempfile: Reduce overhead of pid check. (GH-22997)"
https://github.com/python/cpython/commit/43ca084c88d1e46a44199f347c72e26db84903c9


--

___
Python tracker 
<https://bugs.python.org/issue42160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-10-30 Thread Inada Naoki


Inada Naoki  added the comment:

unpack_sequence is very sensitive benchmark. Speed is dramatically changed by 
code alignment. PGO+LTO will reduce the noise, but we see noise always.

I believe there is no significant performance change in macro benchmarks when 
optimizing this part.

Not significant in macro benchmarks doesn't mean we must reject the 
optimization, because pyperformance doesn't cover whole application in the 
world.
But it means that we must be conservative about the optimization.

--

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42160] unnecessary overhead in tempfile

2020-10-30 Thread Inada Naoki


Change by Inada Naoki :


--
pull_requests: +21974
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/23055

___
Python tracker 
<https://bugs.python.org/issue42160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42160] unnecessary overhead in tempfile

2020-10-30 Thread Inada Naoki


Inada Naoki  added the comment:

Oh, _RandomNameSequence is not true singleton. Instance is used in tests 
actually.
Using `os.register_at_fork` was but idea. Let's reject it.

--

___
Python tracker 
<https://bugs.python.org/issue42160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42216] Optimize dict.popitem() & insert use case.

2020-10-30 Thread Inada Naoki


Change by Inada Naoki :


--
keywords: +patch
pull_requests: +21973
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23054

___
Python tracker 
<https://bugs.python.org/issue42216>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42216] Optimize dict.popitem() & insert use case.

2020-10-30 Thread Inada Naoki


New submission from Inada Naoki :

PyDict_DelItem stores DUMMY entry in the hash table. Without DUMMY, collision 
chain will be broken so proving will be not working.

But `dict.popitem()` returns the last item in the insertion order. The item 
must be the last item of collision chain too.
So `dict.popitem()` can use EMPTY entry instead of DUMMY, and reduce dict 
resizing.

--
components: Interpreter Core
messages: 380022
nosy: methane
priority: normal
severity: normal
status: open
title: Optimize dict.popitem() & insert use case.
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42216>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42202] Optimize function annotation

2020-10-30 Thread Inada Naoki


Inada Naoki  added the comment:

> Are annotations now always known at compile time?

Yes, because `from __future__ import annotations` is enabled by default from 
Python 3.10.

> As for representation, it can also be a sequence of pairs (('x', 'int'), 
> ('z', 'float'), ('return', 'Hoge')) or a pair of sequences (('x', 'z', 
> 'return'), ('int', 'float', 'Hoge')). It would be better to save a dict 
> directly in pyc files, but it needs changing the marshal protocol.

Yes, but it is bit larger than my single tuple idea in most cases.
Since most annotations are not used by runtime, we don't need to create a dict 
until `func.__annotation__` is read.

> Also, it makes sense to make annotations attribute of the code object, so 
> avoid the overhead at function creation time.

I am not sure this is the best option because there are many code object 
without annotation.

> I have a dream to split the pyc file into several files or sections and save 
> docstrings and annotations (and maybe line numbers) separately from the main 
> code. They should be loaded by demand, when you read __doc__ or 
> __annotation__. Most code does not use them at run time, so we can save 
> memory and loading time. It can also help with internationalization.

I have same dream.

--

___
Python tracker 
<https://bugs.python.org/issue42202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42202] Optimize function annotation

2020-10-30 Thread Inada Naoki


New submission from Inada Naoki :

Look this example:

code:

```
# code
def foo(x: int, /, y, *, z: float) -> Hoge:
pass

# dis
 2  12 LOAD_CONST   2 ('int')
14 LOAD_CONST   3 ('float')
16 LOAD_CONST   4 ('Hoge')
18 LOAD_CONST   5 (('x', 'z', 'return'))
20 BUILD_CONST_KEY_MAP  3
22 LOAD_CONST   6 ()
24 LOAD_CONST   7 ('foo')
26 MAKE_FUNCTION4 (annotations)
28 STORE_NAME   2 (foo) 
```

Four `LOAD_CONST` and `BUILD_CONST_KEY_MAP` are used to generate annotation 
dict. This makes program load slow and eat more memory.

Annotation information can be stored in some compact form. And creating 
annotation dict can be postponed to when `func.__annotation__` is accessed.

Ideas for the compact form:

1. Tuple.
   In above example, `('int', None, 'float', 'Hoge')` can be used. None means 
no annotation for the 'y' parameter.

2. Serialize into str or bytes.
   JSON like format can be used, like `x:int,z:float;Hoge`. Compact. But the 
string/bytes has lower chance to be shared with other constants in same module.

--
components: Interpreter Core
messages: 379923
nosy: methane
priority: normal
severity: normal
status: open
title: Optimize function annotation
type: resource usage
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42160] unnecessary overhead in tempfile

2020-10-30 Thread Inada Naoki


Inada Naoki  added the comment:

Thanks

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue42160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40255] Fixing Copy on Writes from reference counting

2020-10-29 Thread Inada Naoki


Inada Naoki  added the comment:

>> Fast shutdown option
>
> You can use os._exit(0).

Yes. Instagram use it as `atexit.register(os._exit, 0)`.

https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172

I think this hack can be supported in multiprocessing module in some way.

--

___
Python tracker 
<https://bugs.python.org/issue40255>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42160] unnecessary overhead in tempfile

2020-10-29 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset 8e409cebad42032bb7d0f2cadd8b1e36081d98af by Eric W in branch 
'master':
bpo-42160: tempfile: Reduce overhead of pid check. (GH-22997)
https://github.com/python/cpython/commit/8e409cebad42032bb7d0f2cadd8b1e36081d98af


--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue42160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42176] Valgrind reports "Conditional jump or move depends on uninitialised value(s)" in `PyUnicode_AsEncodedString` and `PyUnicode_Decode`

2020-10-28 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42176>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40255] Fixing Copy on Writes from reference counting

2020-10-26 Thread Inada Naoki


Change by Inada Naoki :


--
versions: +Python 3.10 -Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40255>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40255] Fixing Copy on Writes from reference counting

2020-10-26 Thread Inada Naoki


Inada Naoki  added the comment:

I'm big -1 too. But I am interested in Instagram usage.

* How % of heap are CoW-ed with gc.freeze()?
* When CoW happen? in execution time, or shutdown?
* Which type cause CoW?

I have two ideas to reduce CoW:

* Fast shutdown option
  Currently Python try to free object as possible in finalization. It will 
cause much CoW. It will very bad for applications using multiprocessing.Pool 
for parallel processing of large data.

* Use "legacy" Unicode representation for large strings.
  Unicode is cold, immutable. But refcount is not immutable. Currentlly, most 
unicode object is "compact": object header and data is in one memory block. We 
may be able to use "legacy" representation and put cold data into another page.

For long term, multi process friendly `pyc` format can share more memory inter 
processes, even though they are not created by prefork.

--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue40255>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39189] Use io.DEFAULT_BUFFER_SIZE for filecmp BUFSIZE variable

2020-10-26 Thread Inada Naoki


Inada Naoki  added the comment:

I concur with Benjamin.

Although two variables are similar, they are used in the different layer.

--
nosy: +methane
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue39189>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41662] Bugs in binding parameters in sqlite3

2020-10-25 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset a053a7ecfef006b834a9957468fa461dafb332db by Miss Skeleton (bot) 
in branch '3.8':
bpo-41662: Fix bugs in binding parameters in sqlite3 (GH-21998)
https://github.com/python/cpython/commit/a053a7ecfef006b834a9957468fa461dafb332db


--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue41662>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39871] math.copysign raises SystemError with non-float x and custom y

2020-10-25 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset f6255a2ccb55a63194caf698f471c803c08be359 by Zackery Spytz in 
branch '3.8':
bpo-39871: Fix an error in a news entry (GH-21749)
https://github.com/python/cpython/commit/f6255a2ccb55a63194caf698f471c803c08be359


--

___
Python tracker 
<https://bugs.python.org/issue39871>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33557] Windows multiprocessing doesn't propagate tabcheck to children

2020-10-25 Thread Inada Naoki


Inada Naoki  added the comment:

Python 2.7 became EOL.

--
nosy: +methane
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue33557>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32122] Improve -x option documentation

2020-10-25 Thread Inada Naoki


Change by Inada Naoki :


--
keywords: +newcomer friendly
versions: +Python 3.10 -Python 2.7, Python 3.6, Python 3.7

___
Python tracker 
<https://bugs.python.org/issue32122>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42147] Micro optimization for longrange iteration if step is 1

2020-10-25 Thread Inada Naoki

Inada Naoki  added the comment:

Oh, I didn't know that. Thank you.

I thought Chinese and Korean use surname-given name order because of "Xí 
Jìnpíng", "Moon Jae-in", and "Kim Jong-un". Japanese previous P.M. used "Shinzo 
Abe" English notation, but changed it to "Abe Shinzo" recently.

--

___
Python tracker 
<https://bugs.python.org/issue42147>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42147] Micro optimization for longrange iteration if step is 1

2020-10-25 Thread Inada Naoki


Inada Naoki  added the comment:

> On the other hand, GH-22479 is affect to all index API() whether the number 
> is large or small.

Then, no need to revert GH-22479 for consistency. Thanks.

> p.s by the way, Naoki is the last name or first name? ;)

It is difficult to say what is first name. Inada is surname and Naoki is given 
name. Surname comes first in Japanese.

Traditionally, we used reversed name order when write name in English to follow 
English-world manner. But China and Korea don't reverse name. And Japan is 
stopping reversed name order too. Japanese junior high schools teach 
surname-given name since about 2000.

--

___
Python tracker 
<https://bugs.python.org/issue42147>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42147] Micro optimization for longrange iteration if step is 1

2020-10-25 Thread Inada Naoki


Inada Naoki  added the comment:

I had not noticed that there are rangeobject and longrangeobject. It doesn't 
affect to range(1) definitely.

--

___
Python tracker 
<https://bugs.python.org/issue42147>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42147] Micro optimization for longrange iteration if step is 1

2020-10-25 Thread Inada Naoki


Inada Naoki  added the comment:

I agree that 1<<1000 is artificial example. But isn't this patch affects more 
regular patterns like [[] for _ in range(1)]?

If we reject this, shouldn't we revert GH-22479 too?
I believe iterating range object is much more common use  case than range.index.

--

___
Python tracker 
<https://bugs.python.org/issue42147>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42141] Speedup various dict inits

2020-10-25 Thread Inada Naoki


Inada Naoki  added the comment:

I run pyperformance=1.0.0 for your speedup_dictinit branch (7df3b9c) and master 
branch, with PGO+LTO build.

```
$ ./python -m pyperf compare_to master-opt.json dictinit.json -G --min-speed=1
Slower (22):
- unpack_sequence: 62.7 ns +- 0.7 ns -> 70.3 ns +- 0.5 ns: 1.12x slower (+12%)
- pickle_dict: 28.6 us +- 0.1 us -> 30.7 us +- 0.1 us: 1.07x slower (+7%)
- regex_dna: 233 ms +- 1 ms -> 245 ms +- 0 ms: 1.05x slower (+5%)
- unpickle_list: 5.22 us +- 0.22 us -> 5.46 us +- 0.10 us: 1.05x slower (+5%)
- sqlite_synth: 3.29 us +- 0.05 us -> 3.43 us +- 0.05 us: 1.04x slower (+4%)
- regex_v8: 26.1 ms +- 0.1 ms -> 27.1 ms +- 0.4 ms: 1.04x slower (+4%)
- spectral_norm: 147 ms +- 1 ms -> 153 ms +- 2 ms: 1.04x slower (+4%)
- scimark_sparse_mat_mult: 5.28 ms +- 0.03 ms -> 5.48 ms +- 0.01 ms: 1.04x 
slower (+4%)
- unpickle_pure_python: 326 us +- 4 us -> 338 us +- 3 us: 1.04x slower (+4%)
- nbody: 143 ms +- 3 ms -> 148 ms +- 2 ms: 1.03x slower (+3%)
- regex_effbot: 3.43 ms +- 0.01 ms -> 3.53 ms +- 0.02 ms: 1.03x slower (+3%)
- django_template: 52.7 ms +- 0.7 ms -> 54.1 ms +- 0.9 ms: 1.03x slower (+3%)
- scimark_fft: 405 ms +- 4 ms -> 415 ms +- 9 ms: 1.03x slower (+3%)
- fannkuch: 523 ms +- 2 ms -> 535 ms +- 2 ms: 1.02x slower (+2%)
- xml_etree_process: 80.2 ms +- 0.8 ms -> 82.0 ms +- 0.8 ms: 1.02x slower (+2%)
- json_dumps: 14.6 ms +- 0.1 ms -> 14.9 ms +- 0.1 ms: 1.02x slower (+2%)
- scimark_sor: 209 ms +- 2 ms -> 213 ms +- 2 ms: 1.02x slower (+2%)
- genshi_text: 32.1 ms +- 0.5 ms -> 32.7 ms +- 0.4 ms: 1.02x slower (+2%)
- logging_format: 10.9 us +- 0.2 us -> 11.0 us +- 0.2 us: 1.02x slower (+2%)
- pyflate: 734 ms +- 6 ms -> 745 ms +- 8 ms: 1.01x slower (+1%)
- float: 134 ms +- 1 ms -> 135 ms +- 2 ms: 1.01x slower (+1%)
- raytrace: 511 ms +- 5 ms -> 517 ms +- 5 ms: 1.01x slower (+1%)

Faster (2):
- logging_silent: 209 ns +- 5 ns -> 205 ns +- 6 ns: 1.02x faster (-2%)
- pickle_list: 5.04 us +- 0.03 us -> 4.96 us +- 0.04 us: 1.02x faster (-2%)

Benchmark hidden because not significant (36):
```

I suppose all delta are noise. But there is a possibility small performance 
down caused by fatter binary.

--

___
Python tracker 
<https://bugs.python.org/issue42141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29981] Update Index for set, dict, and generator 'comprehensions'

2020-10-24 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7

___
Python tracker 
<https://bugs.python.org/issue29981>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42141] Speedup various dict inits

2020-10-24 Thread Inada Naoki


Inada Naoki  added the comment:

> 1. dicts from other dicts that are not "perfect" (combined and without holes)
> 3. copies of dicts with many holes

Note that I have optimized and rejected it by myself already.
See https://github.com/python/cpython/pull/21669
and https://bugs.python.org/issue41431#msg374556

Code duplication is too huge compared to performance gain.

--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue42141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-10-24 Thread Inada Naoki


Inada Naoki  added the comment:

I confirmed _PyDict_FromItems() can be used to optimize _PyStack_AsDict() too.
See https://github.com/methane/cpython/pull/25

But I can not confirm significant performance gain from it too.

--

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-10-24 Thread Inada Naoki


Inada Naoki  added the comment:

@Marco Sulla

> @methane: well, to be honest, I don't see much difference between the two 
> pulls. The major difference is that you merged insertdict_init in 
> dict_merge_init.

Not only it but also some simplification which make 10% faster than GH-22346.

> But I kept insertdict_init separate on purpose, because this function can be 
> used in other future dedicated function on creation time only.

Where do you expect to use it? Would you implement some more optimization based 
on your PR to demonstrate your idea?

I confirmed that GH-22909 can be used to optimize BUILD_CONST_KEY_MAP 
(GH-22911). That's why I merged two functions.

> AssertionError: would build wheel with unsupported tag ('cp310', 'cp310', 
> 'linux_x86_64')

Try `pip install pyperformance==1.0.0`.

--

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-10-24 Thread Inada Naoki


Inada Naoki  added the comment:

@Mark.Shannon I had seen some speedup on tornado benchmark when I didn't use 
PGO+LTO. but it was noise.

Now I use PGO+LTO. master vs PR-22909:

$ ./python -m pyperf compare_to master-opt.json speedup_kw-opt.json -G 
--min-speed=1
Slower (11):
- spectral_norm: 147 ms +- 1 ms -> 153 ms +- 2 ms: 1.04x slower (+4%)
- pickle_dict: 28.6 us +- 0.1 us -> 29.5 us +- 0.6 us: 1.03x slower (+3%)
- regex_compile: 199 ms +- 1 ms -> 204 ms +- 4 ms: 1.03x slower (+3%)
- chameleon: 9.75 ms +- 0.10 ms -> 9.99 ms +- 0.09 ms: 1.02x slower (+2%)
- logging_format: 10.9 us +- 0.2 us -> 11.1 us +- 0.2 us: 1.02x slower (+2%)
- sqlite_synth: 3.29 us +- 0.05 us -> 3.36 us +- 0.05 us: 1.02x slower (+2%)
- regex_v8: 26.1 ms +- 0.1 ms -> 26.5 ms +- 0.3 ms: 1.02x slower (+2%)
- json_dumps: 14.6 ms +- 0.1 ms -> 14.8 ms +- 0.1 ms: 1.02x slower (+2%)
- logging_simple: 9.88 us +- 0.18 us -> 10.0 us +- 0.2 us: 1.02x slower (+2%)
- nqueens: 105 ms +- 1 ms -> 107 ms +- 2 ms: 1.01x slower (+1%)
- raytrace: 511 ms +- 5 ms -> 517 ms +- 6 ms: 1.01x slower (+1%)

Faster (10):
- regex_dna: 233 ms +- 1 ms -> 229 ms +- 1 ms: 1.02x faster (-2%)
- unpickle: 14.7 us +- 0.1 us -> 14.5 us +- 0.2 us: 1.02x faster (-1%)
- deltablue: 8.17 ms +- 0.29 ms -> 8.06 ms +- 0.17 ms: 1.01x faster (-1%)
- mako: 16.8 ms +- 0.2 ms -> 16.6 ms +- 0.1 ms: 1.01x faster (-1%)
- xml_etree_iterparse: 117 ms +- 1 ms -> 116 ms +- 1 ms: 1.01x faster (-1%)
- scimark_monte_carlo: 117 ms +- 2 ms -> 115 ms +- 1 ms: 1.01x faster (-1%)
- xml_etree_parse: 164 ms +- 3 ms -> 162 ms +- 1 ms: 1.01x faster (-1%)
- unpack_sequence: 62.7 ns +- 0.7 ns -> 62.0 ns +- 0.7 ns: 1.01x faster (-1%)
- regex_effbot: 3.43 ms +- 0.01 ms -> 3.39 ms +- 0.02 ms: 1.01x faster (-1%)
- scimark_fft: 405 ms +- 4 ms -> 401 ms +- 1 ms: 1.01x faster (-1%)

Benchmark hidden because not significant (39)

--

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24165] Free list for single-digits ints

2020-10-24 Thread Inada Naoki


Inada Naoki  added the comment:

I close this issue for now. Please reopen or create a new issue if you came up 
with better idea.

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.7

___
Python tracker 
<https://bugs.python.org/issue24165>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-10-23 Thread Inada Naoki


Inada Naoki  added the comment:

@Marco Sulla Please take a look at GH-22909. It is simplified version of your 
PR. And I wrote another optimization based on it #42126.

--

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42126] Optimize BUILD_CONST_KEY_MAP for distinct keys

2020-10-23 Thread Inada Naoki


Inada Naoki  added the comment:

It is difficult to estimate. Real world applications has different code-style 
than stdlib. And pyperformance didn't include whole real world applications too.
Some application may use dict display in heavy loop. But it is difficult to say 
how much exactly.

One example from pyperformance. It uses inner function and function annotations 
heavily.
BUILD_CONST_KEY_MAP is used to build annotation dict, instead of dict display.
https://github.com/tornadoweb/tornado/blob/5eb7bb8efb4e1be8a2cec1744c857a8dadd43af9/tornado/gen.py

```
591  32 LOAD_CONST   1 ('Future')
 34 LOAD_CONST   2 ('None')
 36 LOAD_CONST   3 (('future', 'return'))
 38 BUILD_CONST_KEY_MAP  5
 40 LOAD_CLOSURE 3 (quiet_exceptions)
 42 BUILD_TUPLE  1
 44 LOAD_CONST   4 ()
 46 LOAD_CONST   5 
('with_timeout..error_callback')
 48 MAKE_FUNCTION   12 (annotations, closure)
 50 STORE_DEREF  0 (error_callback)
```

I have not posted pyperformance result because this pull request is based on 
#41835 and I don't measure each performance.
But #41835 + this is 16% faster than master on bm_tornado_http.

--

___
Python tracker 
<https://bugs.python.org/issue42126>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42126] Optimize BUILD_CONST_KEY_MAP for distinct keys

2020-10-23 Thread Inada Naoki


Inada Naoki  added the comment:

$ ./python -m pyperf timeit --compare-to ~/pyenv/versions/3.10-dev/bin/python 
'{}'
/home/inada-n/pyenv/versions/3.10-dev/bin/python: . 23.5 ns 
+- 0.2 ns
/home/inada-n/work/python/cpython/python: . 22.4 ns +- 0.1 
ns

Mean +- std dev: [/home/inada-n/pyenv/versions/3.10-dev/bin/python] 23.5 ns +- 
0.2 ns -> [/home/inada-n/work/python/cpython/python] 22.4 ns +- 0.1 ns: 1.05x f
aster (-5%)

$ ./python -m pyperf timeit --compare-to ~/pyenv/versions/3.10-dev/bin/python 
'{1:1,2:2}'
/home/inada-n/pyenv/versions/3.10-dev/bin/python: . 83.5 ns 
+- 0.3 ns
/home/inada-n/work/python/cpython/python: . 96.7 ns +- 0.2 
ns

Mean +- std dev: [/home/inada-n/pyenv/versions/3.10-dev/bin/python] 83.5 ns +- 
0.3 ns -> [/home/inada-n/work/python/cpython/python] 96.7 ns +- 0.2 ns: 1.16x s
lower (+16%)

$ ./python -m pyperf timeit --compare-to ~/pyenv/versions/3.10-dev/bin/python 
'{1:1,2:2,3:3}'
/home/inada-n/pyenv/versions/3.10-dev/bin/python: . 108 ns 
+- 0 ns
/home/inada-n/work/python/cpython/python: . 110 ns +- 1 ns

Mean +- std dev: [/home/inada-n/pyenv/versions/3.10-dev/bin/python] 108 ns +- 0 
ns -> [/home/inada-n/work/python/cpython/python] 110 ns +- 1 ns: 1.01x slower
(+1%)

$ ./python -m pyperf timeit --compare-to ~/pyenv/versions/3.10-dev/bin/python 
'{1:1,2:2,3:3,4:4}'
/home/inada-n/pyenv/versions/3.10-dev/bin/python: . 134 ns 
+- 1 ns
/home/inada-n/work/python/cpython/python: . 122 ns +- 1 ns

Mean +- std dev: [/home/inada-n/pyenv/versions/3.10-dev/bin/python] 134 ns +- 1 
ns -> [/home/inada-n/work/python/cpython/python] 122 ns +- 1 ns: 1.10x faster
(-9%)

$ ./python -m pyperf timeit --compare-to ~/pyenv/versions/3.10-dev/bin/python 
'{1:1,2:2,3:3,4:4,5:5}'
/home/inada-n/pyenv/versions/3.10-dev/bin/python: . 168 ns 
+- 1 ns
/home/inada-n/work/python/cpython/python: . 112 ns +- 1 ns

Mean +- std dev: [/home/inada-n/pyenv/versions/3.10-dev/bin/python] 168 ns +- 1 
ns -> [/home/inada-n/work/python/cpython/python] 112 ns +- 1 ns: 1.50x faster
(-33%)

$ ./python -m pyperf timeit --compare-to ~/pyenv/versions/3.10-dev/bin/python 
'{1:1,2:2,3:3,4:4,5:5,6:6}'
/home/inada-n/pyenv/versions/3.10-dev/bin/python: . 223 ns 
+- 1 ns
/home/inada-n/work/python/cpython/python: . 150 ns +- 4 ns

Mean +- std dev: [/home/inada-n/pyenv/versions/3.10-dev/bin/python] 223 ns +- 1 
ns -> [/home/inada-n/work/python/cpython/python] 150 ns +- 4 ns: 1.48x faster
(-33%)

$ ./python -m pyperf timeit --compare-to ~/pyenv/versions/3.10-dev/bin/python 
'{1:1,2:2,3:3,4:4,5:5,6:6,7:7,8:8}'
/home/inada-n/pyenv/versions/3.10-dev/bin/python: . 273 ns 
+- 1 ns
/home/inada-n/work/python/cpython/python: . 177 ns +- 1 ns

Mean +- std dev: [/home/inada-n/pyenv/versions/3.10-dev/bin/python] 273 ns +- 1 
ns -> [/home/inada-n/work/python/cpython/python] 177 ns +- 1 ns: 1.54x faster
(-35%)

--

___
Python tracker 
<https://bugs.python.org/issue42126>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42126] Optimize BUILD_CONST_KEY_MAP for distinct keys

2020-10-23 Thread Inada Naoki


Change by Inada Naoki :


--
keywords: +patch
pull_requests: +21842
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22911

___
Python tracker 
<https://bugs.python.org/issue42126>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42126] Optimize BUILD_CONST_KEY_MAP for distinct keys

2020-10-23 Thread Inada Naoki


New submission from Inada Naoki :

BUILD_CONST_KEY_MAP can be optimized based on #41835 optimization.

1. compiler checks keys tuple is distinct.
2. Add distinct flag to BUILD_CONST_KEY_MAP oparg

To be considered:

* Should we use new opcode, instead of flag in oparg?
* Is this technique safe? Wrong co_consts can make invalid dict instance.

--
assignee: methane
components: Interpreter Core
messages: 379415
nosy: methane
priority: normal
severity: normal
status: open
title: Optimize BUILD_CONST_KEY_MAP for distinct keys
type: performance
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42126>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-10-22 Thread Inada Naoki


Inada Naoki  added the comment:

Ok. Performance improvement comes from:

a. Presizing
b. Bypassing some checks in PyDict_SetItem
c. Avoiding duplication check.

(b) is relatively small so I tried to focus on (a) and (b). See GH-22909.

In case of simple keyword arguments, it is 10% faster than GH-22346:

```
$ ./python -m pyperf timeit --compare-to ./python-speedup_kw 
"dict(ihinvdono='doononon', gowwondwon='nwog', bdjbodbob='nidnnpn', 
nwonwno='vndononon', dooodbob='iohiwipwgpw', doidonooq='ndwnnpnpnp', 
fndionqinqn='ndjboqoqjb', nonoeoqgoqb='bdboboqbgoqeb', 
jdnvonvoddo='nvdjnvndvonoq', njnvodnoo='hiehgieba', nvdnvwnnp='wghgihpa', 
nvfnwnnq='nvdknnnqkm', ndonvnipnq='fndjnaobobvob', fjafosboab='ndjnodvobvojb', 
nownwnojwjw='nvknnndnow', niownviwnwnwi='nownvwinvwnwnwj')"
python-speedup_kw: . 357 ns +- 10 ns
python: . 323 ns +- 4 ns

Mean +- std dev: [python-speedup_kw] 357 ns +- 10 ns -> [python] 323 ns +- 4 
ns: 1.11x faster (-10%)
```

In case of `dict(d, key=val)` case, it is 8% slower than GH-22346, but still 8% 
faster than master.

```
$ ./python -m pyperf timeit --compare-to ./python-speedup_kw -s 
'd={"foo":"bar"}' "dict(d, ihinvdono='doononon', gowwondwon='nwog', 
bdjbodbob='nidnnpn', nwonwno='vndononon', dooodbob='iohiwipwgpw', 
doidonooq='ndwnnpnpnp', fndionqinqn='ndjboqoqjb', nonoeoqgoqb='bdboboqbgoqeb', 
jdnvonvoddo='nvdjnvndvonoq', njnvodnoo='hiehgieba', nvdnvwnnp='wghgihpa', 
nvfnwnnq='nvdknnnqkm', ndonvnipnq='fndjnaobobvob', fjafosboab='ndjnodvobvojb', 
nownwnojwjw='nvknnndnow', niownviwnwnwi='nownvwinvwnwnwj')"
python-speedup_kw: . 505 ns +- 15 ns
python: . 546 ns +- 17 ns

Mean +- std dev: [python-speedup_kw] 505 ns +- 15 ns -> [python] 546 ns +- 17 
ns: 1.08x slower (+8%)

$ ./python -m pyperf timeit --compare-to ./python-master -s 'd={"foo":"bar"}' 
"dict(d, ihinvdono='doononon', gowwondwon='nwog', bdjbodbob='nidnnpn', 
nwonwno='vndononon', dooodbob='iohiwipwgpw', doidonooq='ndwnnpnpnp', 
fndionqinqn='ndjboqoqjb', nonoeoqgoqb='bdboboqbgoqeb', 
jdnvonvoddo='nvdjnvndvonoq', njnvodnoo='hiehgieba', nvdnvwnnp='wghgihpa', 
nvfnwnnq='nvdknnnqkm', ndonvnipnq='fndjnaobobvob', fjafosboab='ndjnodvobvojb', 
nownwnojwjw='nvknnndnow', niownviwnwnwi='nownvwinvwnwnwj')"
python-master: . 598 ns +- 10 ns
python: . 549 ns +- 19 ns

Mean +- std dev: [python-master] 598 ns +- 10 ns -> [python] 549 ns +- 19 ns: 
1.09x faster (-8%)
```

Additionally, I expect we can reuse this new code to optimize 
BUILD_CONST_KEY_MAP.

--
stage: patch review -> 

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41835] Speed up dict vectorcall creation using keywords

2020-10-22 Thread Inada Naoki


Change by Inada Naoki :


--
keywords: +patch
pull_requests: +21840
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22909

___
Python tracker 
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24165] Free list for single-digits ints

2020-10-22 Thread Inada Naoki


Inada Naoki  added the comment:

I had suspected that pypeformance just don't have enough workload for non-small 
int.

For example, spectral_norm is integer heavy + some float warkload. But 
bm_spectral_norm uses `DEFAULT_N = 130`. So most integers are fit into smallint 
cache.

On the othar hand, spectral_norm in the benchmarkgame uses N=5500.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-python3-8.html

So I ran the benchmark on my machine:

master:
real1m24.647s
user5m37.515s

patched:
real1m19.033s
user5m14.682s

master+increased small int from [-5, 256] to [-9, 1024]
real1m23.742s
user5m33.569s


314.682/337.515 = 0.9323496733478512. So ther is only 7% speedup even when 
N=5500.

After all, I think it is doubtful. Let's stop this idea until situation is  
changed.

--

___
Python tracker 
<https://bugs.python.org/issue24165>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24165] Free list for single-digits ints

2020-10-22 Thread Inada Naoki


Inada Naoki  added the comment:

I heard pyperformance 1.0.0 works and here is the result of PR-22884.

$ ./python-master -m pyperf compare_to master.json patched.json -G --min-speed=1
Slower (8):
- pathlib: 26.3 ms +- 0.3 ms -> 26.8 ms +- 0.4 ms: 1.02x slower (+2%)
- chameleon: 12.8 ms +- 0.1 ms -> 13.0 ms +- 0.1 ms: 1.02x slower (+2%)
- genshi_text: 38.3 ms +- 0.7 ms -> 38.9 ms +- 0.6 ms: 1.02x slower (+2%)
- sqlalchemy_imperative: 40.4 ms +- 0.9 ms -> 41.0 ms +- 0.8 ms: 1.02x slower 
(+2%)
- sympy_str: 441 ms +- 4 ms -> 448 ms +- 4 ms: 1.01x slower (+1%)
- chaos: 146 ms +- 1 ms -> 148 ms +- 2 ms: 1.01x slower (+1%)
- unpickle: 18.7 us +- 0.1 us -> 18.9 us +- 0.2 us: 1.01x slower (+1%)
- xml_etree_parse: 177 ms +- 2 ms -> 179 ms +- 3 ms: 1.01x slower (+1%)

Faster (11):
- scimark_sparse_mat_mult: 6.74 ms +- 0.18 ms -> 6.26 ms +- 0.03 ms: 1.08x 
faster (-7%)
- scimark_fft: 511 ms +- 7 ms -> 496 ms +- 4 ms: 1.03x faster (-3%)
- spectral_norm: 181 ms +- 2 ms -> 176 ms +- 3 ms: 1.03x faster (-3%)
- pidigits: 225 ms +- 1 ms -> 219 ms +- 1 ms: 1.03x faster (-3%)
- pickle_dict: 35.5 us +- 1.3 us -> 34.8 us +- 0.3 us: 1.02x faster (-2%)
- pickle_list: 5.32 us +- 0.09 us -> 5.23 us +- 0.09 us: 1.02x faster (-2%)
- pyflate: 883 ms +- 7 ms -> 867 ms +- 6 ms: 1.02x faster (-2%)
- scimark_sor: 264 ms +- 2 ms -> 259 ms +- 2 ms: 1.02x faster (-2%)
- sqlite_synth: 4.04 us +- 0.10 us -> 3.98 us +- 0.09 us: 1.02x faster (-1%)
- regex_dna: 243 ms +- 3 ms -> 240 ms +- 1 ms: 1.01x faster (-1%)
- crypto_pyaes: 165 ms +- 3 ms -> 163 ms +- 1 ms: 1.01x faster (-1%)

Benchmark hidden because not significant (41)

--
nosy:  -pablogsal

___
Python tracker 
<https://bugs.python.org/issue24165>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24165] Free list for single-digits ints

2020-10-22 Thread Inada Naoki


Inada Naoki  added the comment:

I updated the patch.
I can not run pyperformance for now, because:

  AssertionError: would build wheel with unsupported tag ('cp310', 'cp310', 
'linux_x86_64'

I added this config, but it can not solve the problem:

```
$ cat ~/.config/pip/pip.conf
[global]
no-cache-dir = true
```

--

___
Python tracker 
<https://bugs.python.org/issue24165>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24165] Free list for single-digits ints

2020-10-22 Thread Inada Naoki


Change by Inada Naoki :


--
pull_requests: +21823
pull_request: https://github.com/python/cpython/pull/22884

___
Python tracker 
<https://bugs.python.org/issue24165>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

2020-10-22 Thread Inada Naoki


Inada Naoki  added the comment:

One more idea: BINARY_ADD_INT. Operand is int immediate.
This idea can be implemented without opcode cache. I will try it.

--

___
Python tracker 
<https://bugs.python.org/issue42115>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

2020-10-22 Thread Inada Naoki


Inada Naoki  added the comment:

FWIW, php7 is about 5x faster than Python on spectral norm benchmark.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php-python3.html

There two major reasons:

* PHP uses scalar type for float and int
* PHP uses type-specialized bytecode (PHP8 will use JIT, but PHP7 dosn't)

Source code is here:
php: 
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-php-1.html
Python: 
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-python3-8.html

The most hot function is eval_A()

```
def eval_A(i, j): # i and j are int.
ij = i + j
return ij * (ij + 1) // 2 + i + 1
```

And its bytecode:

```
Disassembly of :
  2   0 LOAD_FAST0 (i)
  2 LOAD_FAST1 (j)
  4 BINARY_ADD
  6 STORE_FAST   2 (ij)

  3   8 LOAD_FAST2 (ij)
 10 LOAD_FAST2 (ij)
 12 LOAD_CONST   1 (1)
 14 BINARY_ADD
 16 BINARY_MULTIPLY
 18 LOAD_CONST   2 (2)
 20 BINARY_FLOOR_DIVIDE
 22 LOAD_FAST0 (i)
 24 BINARY_ADD
 26 LOAD_CONST   1 (1)
 28 BINARY_ADD
 30 RETURN_VALUE
```

My thoughts:

* bytecode specialized for `int op int` will some help.
* there are many incref/decref overhead.
  * multi operand bytecode (e.g. BINARY_ADD_FAST_FAST, BINARY_ADD_FAST_CONST, 
etc) will reduce refcount overhead.

--

___
Python tracker 
<https://bugs.python.org/issue42115>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42057] peephole optimizer bug relating to JUMP_IF_NOT_EXC_MATCH

2020-10-21 Thread Inada Naoki


Inada Naoki  added the comment:

Thank you for reporting with reproducer.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42057>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32431] Two bytes objects of zero length don't compare equal

2020-10-21 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue32431>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42057] peephole optimizer bug relating to JUMP_IF_NOT_EXC_MATCH

2020-10-21 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset 8f6787d93db1b6022db44b1e1d22460c2b74f60b by Inada Naoki in branch 
'3.9':
bpo-42057: Add a test case (GH-22878)
https://github.com/python/cpython/commit/8f6787d93db1b6022db44b1e1d22460c2b74f60b


--

___
Python tracker 
<https://bugs.python.org/issue42057>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42057] peephole optimizer bug relating to JUMP_IF_NOT_EXC_MATCH

2020-10-21 Thread Inada Naoki


Change by Inada Naoki :


--
pull_requests: +21820
pull_request: https://github.com/python/cpython/pull/22878

___
Python tracker 
<https://bugs.python.org/issue42057>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42057] peephole optimizer bug relating to JUMP_IF_NOT_EXC_MATCH

2020-10-21 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset 07a44d9572c7746568a7fe2fbcd42127fd6d4019 by Inada Naoki in branch 
'3.9':
bpo-42057: Fix peephole optimizer (GH-22802)
https://github.com/python/cpython/commit/07a44d9572c7746568a7fe2fbcd42127fd6d4019


--

___
Python tracker 
<https://bugs.python.org/issue42057>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42106] docs.python.org prioritises search horribly

2020-10-21 Thread Inada Naoki


Inada Naoki  added the comment:

Can we add search box using DuckDuckGo?
https://duckduckgo.com/?q=site%3Adocs.python.org%2F3%2F+list+append

--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue42106>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41819] Fix some compiler warnings

2020-10-21 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset c756c2b507b088919ac0c1aa8b0d8c8bdbdd75ee by Miss Skeleton (bot) 
in branch '3.8':
bpo-41819: Fix compiler warning in init_dump_ascii_wstr() (GH-22332)
https://github.com/python/cpython/commit/c756c2b507b088919ac0c1aa8b0d8c8bdbdd75ee


--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue41819>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41819] Fix some compiler warnings

2020-10-21 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

___
Python tracker 
<https://bugs.python.org/issue41819>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41316] tarfile: Do not write full path in FNAME field

2020-10-21 Thread Inada Naoki


Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5, Python 3.6, Python 3.7

___
Python tracker 
<https://bugs.python.org/issue41316>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41646] shutil.copy documentation should clarify support for path-like objects

2020-10-20 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset 19019eccdeeb8dea027bd7766ca9fe2892972da4 by Miss Skeleton (bot) 
in branch '3.9':
bpo-41646: Mention path-like objects support in the docs for shutil.copy() 
(GH-22208)
https://github.com/python/cpython/commit/19019eccdeeb8dea027bd7766ca9fe2892972da4


--

___
Python tracker 
<https://bugs.python.org/issue41646>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41646] shutil.copy documentation should clarify support for path-like objects

2020-10-20 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset 6443a8ccc886749f5e83a8ca073006742b605d90 by Miss Skeleton (bot) 
in branch '3.8':
bpo-41646: Mention path-like objects support in the docs for shutil.copy() 
(GH-22208)
https://github.com/python/cpython/commit/6443a8ccc886749f5e83a8ca073006742b605d90


--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue41646>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41744] NuGet python.props only works in python nuget, not other variants

2020-10-20 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset d0bfce992c4ce0e6e71f13a993c91903a97a62f3 by Miss Skeleton (bot) 
in branch '3.9':
bpo-41744: Package python.props with correct name in NuGet package (GH-22154)
https://github.com/python/cpython/commit/d0bfce992c4ce0e6e71f13a993c91903a97a62f3


--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue41744>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30680] textwrap should treat Unicode em-dash like ASCII em-dash

2020-10-20 Thread Inada Naoki


Change by Inada Naoki :


--
versions: +Python 3.10 -Python 3.7

___
Python tracker 
<https://bugs.python.org/issue30680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30680] textwrap should treat Unicode em-dash like ASCII em-dash

2020-10-20 Thread Inada Naoki


Inada Naoki  added the comment:

> Agreed. It makes great sense that textwrap started as highly ASCII-centric. 
> But in the Python 3, Unicode-friendly era, ASCII-biased isn't where we should 
> leave things.

It needs Unicode experts. If we support Unicode, we should implemente UAX #14.
http://www.unicode.org/reports/tr14/tr14-45.html

But I am not sure some core developer love textwrap and Unicode enough to 
implement it.
It can be implemented in 3rd party package before adding it in stdlib.

Then, is U+2014 really important to implement even though we can not implement 
UAX#14 in foreseeable future?
It doesn't make sense to me.

--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue30680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38980] Compile libpython with -fno-semantic-interposition

2020-10-20 Thread Inada Naoki


Inada Naoki  added the comment:

+1

--
versions: +Python 3.10 -Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38980>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23706] pathlib.Path.write_text should include a newline argument

2020-10-20 Thread Inada Naoki


Inada Naoki  added the comment:

Thank you

--
nosy: +methane
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue23706>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41902] Micro optimization for range.index if step is 1

2020-10-20 Thread Inada Naoki


Inada Naoki  added the comment:


New changeset 25492a5b59c5b74328278f195540e318ab87674f by Dong-hee Na in branch 
'master':
bpo-41902: Micro optimization for compute_item of range (GH-22492)
https://github.com/python/cpython/commit/25492a5b59c5b74328278f195540e318ab87674f


--
nosy: +methane

___
Python tracker 
<https://bugs.python.org/issue41902>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42057] peephole optimizer bug relating to JUMP_IF_NOT_EXC_MATCH

2020-10-19 Thread Inada Naoki


Change by Inada Naoki :


--
pull_requests: +21759
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22802

___
Python tracker 
<https://bugs.python.org/issue42057>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42057] peephole optimizer bug relating to JUMP_IF_NOT_EXC_MATCH

2020-10-19 Thread Inada Naoki


Change by Inada Naoki :


--
title: pytest case which catch  exceptions become segfault -> peephole 
optimizer bug relating to JUMP_IF_NOT_EXC_MATCH

___
Python tracker 
<https://bugs.python.org/issue42057>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   5   6   7   8   9   10   >