INADA Naoki added the comment:
Yes. Actually speaking, this patch is almost copy from VersionChanged
directive.
See here:
https://github.com/sphinx-doc/sphinx/blob/master/sphinx/directives/other.py#L216-L221
--
___
Python tracker
<h
INADA Naoki added the comment:
Ah, I misunderstood your comment is about Sphinx's internal DOM.
Sphinx has own pot and po files.
In case of custom extension, `sphinx-build -b gettext` doesn't extract
messages from Python code. That's why I used dummy html template.
Anothe
Changes by INADA Naoki :
Added file: http://bugs.python.org/file44969/impl-detail2.patch
___
Python tracker
<http://bugs.python.org/issue28331>
___
___
Python-bugs-list m
INADA Naoki added the comment:
While I think this patch is safe, I need LGTM from another committer
because I'm new committer.
Could Tim or Raymond review the patch before 3.6beta2?
--
___
Python tracker
<http://bugs.python.org/is
Changes by INADA Naoki :
Added file: http://bugs.python.org/file44980/dict-perturb-shift3.patch
___
Python tracker
<http://bugs.python.org/issue28201>
___
___
Python-bug
Changes by INADA Naoki :
Added file: http://bugs.python.org/file44981/dict-perturb-shift4.patch
___
Python tracker
<http://bugs.python.org/issue28201>
___
___
Python-bug
INADA Naoki added the comment:
Thank you, Tim and Serhiy. My first commit has been pushed now!
Serhiy:
Since I prefer putting variable declaration near it's usage, and
PEP 7 permits it since Python 3.6.
--
___
Python tracker
Changes by INADA Naoki :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28201>
___
___
Python-bugs-list
Changes by INADA Naoki :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24870>
___
___
Python-bugs-list
Changes by INADA Naoki :
Added file: http://bugs.python.org/file44983/dictresize3.patch
___
Python tracker
<http://bugs.python.org/issue28199>
___
___
Python-bugs-list m
INADA Naoki added the comment:
patch is LGTM.
But there is one hidden inconsistency:
>>> r = range(2**100)
>>> type(iter(r))
>>> type(iter(r))(1, 1, 0)
Traceback (most recent call last):
File "", line 1, in
TypeError: cannot create 'longrange_itera
INADA Naoki added the comment:
FutureIter_throw is wrong, maybe.
Removing FutureIter_send and FutureIter_throw from FutureIter_methods solves
the segv and test passed.
--
___
Python tracker
<http://bugs.python.org/issue26
INADA Naoki added the comment:
Since entries array is embedded in PyDictKeysObject, we can't realloc entries.
And while values are split array, dictresize() convert split table into combine
table.
Split table may have enough size of ma_values at first in typical case.
And in not typical
INADA Naoki added the comment:
fixed
--
Added file: http://bugs.python.org/file44993/fastfuture2.patch
___
Python tracker
<http://bugs.python.org/issue26
INADA Naoki added the comment:
fastfuture3-wip.patch is work in progress implementation of
implementing __repr__ and __del__ in C.
I post it to avoid duplicated works.
Known TODOs:
* Support overriding Future._repr_info()
* Fix __del__ is not called (Research how tp_del, tp_finalize, and
INADA Naoki added the comment:
Fixed overriding Future._repr_info().
But I failed to implement overridable Future.__del__ in C yet.
(FYI, fastfuture2.patch passes tests by mix-in __del__ and __repr__)
--
Added file: http://bugs.python.org/file45012/fastfuture3.patch
INADA Naoki added the comment:
Could someone review this before 3.6b2?
Without this patch, python-gdb.py causes many RuntimeError.
--
keywords: +needs review
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issu
INADA Naoki added the comment:
Now I understand tp_dealloc, tp_finalize and subtype_dealloc.
Attached patch passes tests.
--
Added file: http://bugs.python.org/file45023/fastfuture4.patch
___
Python tracker
<http://bugs.python.org/issue26
INADA Naoki added the comment:
I've committed the patch with trivial fixes (adding curly braces to if
statements).
And I'm sorry, I committed with wrong issue number.
https://hg.python.org/cpython/rev/678424183b38 (3.6)
https://hg.python.org/cpython/rev/f8815001a390 (default)
I
INADA Naoki added the comment:
I close this issue for now.
Further improvements can be new issue.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
INADA Naoki added the comment:
How about changing module name?
_asyncio_speedup for example.
--
___
Python tracker
<http://bugs.python.org/issue26081>
___
___
INADA Naoki added the comment:
Thank you for reporting.
C-API doc
[https://docs.python.org/3.7/c-api/gcsupport.html#c._PyObject_GC_TRACK] says:
> A macro version of PyObject_GC_Track(). It should not be used for extension
> modules.
So simply replacing it to PyObject_GC_Track() may
INADA Naoki added the comment:
I need another LGTM from core developer before committing.
Yury, could you see it? This is one line patch.
--
___
Python tracker
<http://bugs.python.org/issue28
INADA Naoki added the comment:
I think the comment described "Why Py_ALLOW_RECURSION is required", not "t may
be NULL even if s is in the intern dict".
> If PyDict_GetItem fails due to stack overflow, perhaps the Python process is
> doomed to fail soon anyway.
When
INADA Naoki added the comment:
Oh! Thanks, While I ran make, I had missed error message somehow.
--
___
Python tracker
<http://bugs.python.org/issue28405>
___
___
INADA Naoki added the comment:
Is this issue OK to close?
--
nosy: +inada.naoki
___
Python tracker
<http://bugs.python.org/issue12660>
___
___
Python-bugs-list m
New submission from INADA Naoki:
Before adding more speedup functions for asyncio, I want to rename the module.
Attached patch is tested on Mac 10.11. I'll test it on Windows later.
--
files: asyncio-speedups.patch
keywords: patch
messages: 278558
nosy: inada.naoki, yselivanov
pri
INADA Naoki added the comment:
Because:
* The "futures" name is used in concurrent.futures too. This module is for
asyncio.
* Currently, this module has only Future class. But there are several ideas
about adding C speedup to improve asyncio performance. (e.g. buffer slicing and
INADA Naoki added the comment:
Since this patch renames file, I used --git option of hg diff.
But Rietvelt seems doesn't accept git format patch.
Attached patch is same to previous, but generated without --git option.
--
Added file: http://bugs.python.org/file45076/asyncio-spee
New submission from INADA Naoki:
https://travis-ci.org/tornadoweb/tornado/jobs/167252979
--
assignee: inada.naoki
components: asyncio
messages: 278569
nosy: gvanrossum, inada.naoki, yselivanov
priority: high
severity: normal
status: open
title: asyncio: C implemeted Future cause Tornado
INADA Naoki added the comment:
> Any reason why this module doesn't use argument clinic?
No reason.
But I don't want to do in this issue, since I don't know how to
generate good patch file for file rename + change in file.
I'l
INADA Naoki added the comment:
I hit this issue27705, and I have no time to reinstall Visual Studio 2015
Community today.
I'll try test on Windows later.
--
___
Python tracker
<http://bugs.python.org/is
INADA Naoki added the comment:
I found _futures module is not used on Windows for now (without this patch).
Because `{"_future", PyInit__future},` is not in PC/config.c
But, when it added, test_windows_events cause infinite loop.
This should be another issue.
With this (asyncio-speed
INADA Naoki added the comment:
> There is also an argument that this should not be a built-in module but
> should be separate (like _ctypes). I don't know if that is just a Windows
> decision or not, but I'm guessing you weren't the one who made that decision
> or
New submission from INADA Naoki:
_WaitCancelFuture in windows_events.py overrides _schedule_callbacks.
C implemented Future should allow overriding _schedule_callbacks.
Since `{"_future", PyInit__future},` is not in PC/config.c, _future is not
registered as builtin module. So Py
INADA Naoki added the comment:
Another test failure is reported.
> I have setup a 3.6 build on Travis of our project GNS3 and it seem to fail.
> https://travis-ci.org/GNS3/gns3-server/builds/167703118
--
___
Python tracker
<http://bugs.p
INADA Naoki added the comment:
Can I commit this patch without NEWS entry?
Only notable change is module name, but I don't expect no one import
it directly.
If it is required, it would be like:
- Issue #28428: Rename _futures module to _asyncio. It will have more
speedup functions or cl
Changes by INADA Naoki :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28428>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by INADA Naoki :
--
stage: commit review -> resolved
___
Python tracker
<http://bugs.python.org/issue28428>
___
___
Python-bugs-list mailing list
Un
New submission from INADA Naoki:
_asyncio._init_module() looks ugly.
This patch imports external dependency when importing _asyncio.
--
components: asyncio
files: asyncio-speedup-refactoring.patch
keywords: patch
messages: 278731
nosy: gvanrossum, inada.naoki, yselivanov
priority
Changes by INADA Naoki :
Added file: http://bugs.python.org/file45122/asyncio-speedup-refactoring2.patch
___
Python tracker
<http://bugs.python.org/issue28452>
___
___
Changes by INADA Naoki :
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45125/schedule_callbacks.patch
___
Python tracker
<http://bugs.python.org/issu
Changes by INADA Naoki :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
INADA Naoki added the comment:
https://github.com/search?p=3&q=_schedule_callbacks&type=Code&utf8=%E2%9C%93
At least, Future class in uvloop have same API.
Most of other results seems just copy of Python source tree.
(But I didn't check
INADA Naoki added the comment:
> I'm not so sure about this. Maybe we can just fix _WaitCancelFuture somehow?
@haypo, do you know why _WaitCancelFuture overrides _schedule_callbacks()
instead
of self.add_done_callback(self._unregister_wait_cb)?
_unregister_wait_cb must be called a
INADA Naoki added the comment:
I think _WaitCancelFuture can do same thing by overriding
callers of _schedule_callbacks.
Attached patch does it, and make _schedule_callbacks private
by renaming it to __schedule_callbacks.
--
Added file:
http://bugs.python.org/file45139/dont-override
INADA Naoki added the comment:
pure Python Future.__iter__ don't use what yield-ed.
def __iter__(self):
if not self.done():
self._asyncio_future_blocking = True
yield self # This tells Task to wait for completion.
assert self.done(), "
INADA Naoki added the comment:
Confirmed, thank you.
--
___
Python tracker
<http://bugs.python.org/issue28492>
___
___
Python-bugs-list mailing list
Unsubscribe:
INADA Naoki added the comment:
Test failure in GNS3 seems not relating to this.
It may be fixed via #28492, maybe.
--
___
Python tracker
<http://bugs.python.org/issue28
Changes by INADA Naoki :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
INADA Naoki added the comment:
LGTM, Thanks Mariatta.
(But one more LGTM from coredev is required for commit)
--
nosy: +inada.naoki
versions: -Python 3.5
___
Python tracker
<http://bugs.python.org/issue18
INADA Naoki added the comment:
> If you are confident (ex: if the change is simple, like this one), you can
> push it directly.
My mentor (Yury) prohibit it while I'm beginner.
And as you saw, I missed PEP 8 violation :)
--
___
Pyt
INADA Naoki added the comment:
committed.
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
INADA Naoki added the comment:
> 0 (128, 60)
> 1 (128, 60)
> 2 (128, 60)
> 3 (128, 60)
> 4 (128, 60)
> 5 (128, 60)
Minimum dict keysize is 8, and it's capacity is 5.
> 6 (196, 196)
Dict is resized. And since __dict__.update() caused the resizing,
both are normal
INADA Naoki added the comment:
And I feel current target size of dict_merge is bit larger.
When inserting new item:
* ma_used = dk_size*2 / 3 when right before increasing keys
* ma_used = dk_size/ 3 when right after increasing keys
On the other hand, current dict_merge creates:
* ma_used
Changes by INADA Naoki :
--
priority: normal -> high
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue28147>
___
___
Pyth
INADA Naoki added the comment:
> - It appears it also touches Misc/NEWS a bit too much. Please make sure to
> not to commit that.
I wont to move move this entry from "Core and Builtins" section to "Library"
section:
- Issue #26081: Added C implementation of asynci
INADA Naoki added the comment:
I'm sorry about my bad English.
> Fix iterator of C implemented asyncio.Future
This meant:
fut = asyncio.Future() # C implemented version of asyncio.Future
it = iter(fut) # Iterator of it
it.send(42) # raised TypeError before. It was not compati
New submission from INADA Naoki:
As discussed on python-dev, this patch adds -VV option to python cmdline.
$ ./python -V
Python 3.6.0b2+
$ ./python -VV
Python 3.6.0b2+ (3.6:84a3c5003510+, Oct 26 2016, 02:47:38)
[GCC 6.2.0 20161005]
The patch includes doc and man update.
Please see, especially
INADA Naoki added the comment:
@haypo, could you review this?
--
___
Python tracker
<http://bugs.python.org/issue28199>
___
___
Python-bugs-list mailing list
Unsub
INADA Naoki added the comment:
script:
import sys
for i in range(25):
a = {}
b = {j: j for j in range(i)}
a.update(b)
print(i, sys.getsizeof(a))
before:
0 256
1 256
2 256
3 256
4 256
5 256
6 384
7 384
8 664
9 664
10 664
11 664
12 664
13 664
14 664
15 664
16 1200
17 1200
18 1200
INADA Naoki added the comment:
I feel that accept one resize while merging is better.
How about this?
/* Do one big resize at the start, rather than incrementally
* resizing. At most one resize happen while merging.
*/
if (USABLE_FRACTION(mp->ma_keys->d
INADA Naoki added the comment:
OK, I won't change it to allow additional resize while merging, after
pre-resize.
But current code has two problem:
* Pre-resize happen even when resizing is not necessary. (ex. two dict has same
keys).
* Pre-resize allocates too much memory which doesn&#
Changes by INADA Naoki :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
INADA Naoki added the comment:
Wow! Great Job!
Yury, would you like to merge this before 3.6b3?
I'll look this as soon as possible.
(nit fix) Some modules doesn't sort imports in lexicography.
--
___
Python tracker
<http://bu
INADA Naoki added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue28088>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
INADA Naoki added the comment:
Why isfuture() is moved, and asyncio.coroutine uses
base_futures.isfuture() instead of futures.isfuture()?
--
___
Python tracker
<http://bugs.python.org/issue28
INADA Naoki added the comment:
LGTM.
--
___
Python tracker
<http://bugs.python.org/issue28199>
___
___
Python-bugs-list mailing list
Unsubscribe:
INADA Naoki added the comment:
Current code and my patch called insertdict_clean() or insert_index() for each
entry.
On the other hand, Serhiy's patch calls build_indices() once.
This may be faster when compiler doesn't inlining the helper function.
As a bonus, we can use memcpy to co
INADA Naoki added the comment:
Serhiy, would you commit it by 3.6b3?
-- sent from mobile
--
___
Python tracker
<http://bugs.python.org/issue28199>
___
___
Pytho
Changes by INADA Naoki :
--
keywords: +easy
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue28532>
___
___
Python-bugs-list mai
INADA Naoki added the comment:
Since I'm not good English writer, I copied & modified from -v option.
-VVV is same to -VV, similar to -vvv is same to -vv.
-v : verbose (trace import statements); also PYTHONVERBOSE=x
can be supplied multiple times to increase
Changes by INADA Naoki :
Added file: http://bugs.python.org/file45272/verbose-version2.patch
___
Python tracker
<http://bugs.python.org/issue28532>
___
___
Python-bug
INADA Naoki added the comment:
Oh, it seems I hurried too much.
Thanks to pointing it out.
--
Added file: http://bugs.python.org/file45276/verbose-version3.patch
___
Python tracker
<http://bugs.python.org/issue28
INADA Naoki added the comment:
Make sense.
--
keywords: +easy, patch
nosy: +inada.naoki
stage: -> commit review
versions: -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file45280/28553.patch
___
Python tracker
<http://bugs.pyth
Changes by INADA Naoki :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
INADA Naoki added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue28583>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by INADA Naoki :
--
nosy: +ned.deily
priority: normal -> release blocker
stage: -> commit review
___
Python tracker
<http://bugs.python.org/i
INADA Naoki added the comment:
Thanks, Xiang.
Shard-key dict is very hard to maintain...
--
___
Python tracker
<http://bugs.python.org/issue28199>
___
___
Pytho
INADA Naoki added the comment:
LGTM, too.
> Similar changes can be applied to other iteration code. dictiter_iternextkey,
> dict_keys, etc.
I agree. Xiang, would you update patch?
--
___
Python tracker
<http://bugs.python.org/i
INADA Naoki added the comment:
I'll commit.
--
assignee: -> inada.naoki
___
Python tracker
<http://bugs.python.org/issue28583>
___
___
Python-bugs-lis
Changes by INADA Naoki :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
INADA Naoki added the comment:
> Xiang Zhang added the comment:
>
> Yes, that's the point. I thought to expose an API in testcapimodule for test,
> but actually I am not willing to do that since I don't believe this patch
> could bring any visible performance chang
INADA Naoki added the comment:
LGTM again for iterate_splittable_v2.patch.
How about issue title (and commit message) to
"Cleanup iterating split table"?
--
___
Python tracker
<http://bugs.python.o
INADA Naoki added the comment:
(Off topic note)
For readability, I prefer this style:
PyDictKeyEntry *entries = DK_ENTRIES(mp->ma_keys);
while (i < n && entries[i].me_value == NULL)
i++;
But because sizeof(PyDictKeyEntry) is not 2^n, entries[i].me_value, i++
may
INADA Naoki added the comment:
LGTM.
--
___
Python tracker
<http://bugs.python.org/issue28123>
___
___
Python-bugs-list mailing list
Unsubscribe:
INADA Naoki added the comment:
> - make dicts denser by making the resize factor 2 instead of 4 for small dicts
This had been implemented already when I start compact dict.
> - improve cache locality on collisions by using linear probing
set does this. But dict doesn't do it for no
Changes by INADA Naoki :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
INADA Naoki added the comment:
LGTM. I'll commit.
--
___
Python tracker
<http://bugs.python.org/issue28580>
___
___
Python-bugs-list mailing list
Unsubscr
Changes by INADA Naoki :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by INADA Naoki :
--
nosy: +ned.deily
priority: high -> release blocker
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/i
New submission from INADA Naoki:
I surprised how functools make import time slower.
And I find namedtuple makes it slower.
When I replaced
_CacheInfo = namedtuple("CacheInfo", ["hits", "misses", "maxsize", "currsize"])
this line with `_CachedI
Changes by INADA Naoki :
--
components: +Library (Lib)
title: Creating namedtuple is too slow -> Creating namedtuple is too slow to be
used in common stdlib (e.g. functools)
versions: +Python 3.6, Python 3.7
___
Python tracker
&l
INADA Naoki added the comment:
I feel this patch is safe enough to be landed in 3.6.
--
keywords: +patch
Added file: http://bugs.python.org/file45386/28638-functools-no-namedtuple.patch
___
Python tracker
<http://bugs.python.org/issue28
INADA Naoki added the comment:
> The slow import is the case only the first time functools is imported. Later
> imports will just use the cache (sys.modules).
Yes. But first import time is also important for CLI applications.
That's why mercurial and Bazaar has lazy import system.
INADA Naoki added the comment:
> The lazy import system could benefit many libs so the result could be
> impressive. But here only functools is enhanced, half a millisecond is
> reduced.
On the other hand, implementing lazy import makes application complex.
This patch only enhance
INADA Naoki added the comment:
> What is the main culprit, importing the collections module or compiling a
> named tuple?
In this time, later.
But collections module takes 1+ ms to import too.
I'll try to optimize it.
> Using namedtuple is not new in 3.6, thus this is not a r
INADA Naoki added the comment:
(tip)
$ ~/local/py37/bin/python3 -m perf timeit -s 'import importlib, functools' --
'importlib.reload(functools)'
.
Median +- std dev: 1.21 ms +- 0.01 ms
(namedtuple-no-compile.patch)
$ ~/local/py37/bin/python3 -m pe
INADA Naoki added the comment:
@haypo, would you review this patch?
--
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/issue28023>
___
___
Pytho
INADA Naoki added the comment:
How about marking lookdict_unicode and lookdict_unicode_nodummy as hot?
--
nosy: +inada.naoki
___
Python tracker
<http://bugs.python.org/issue28
2901 - 3000 of 3039 matches
Mail list logo
