Re: [Python-Dev] On the METH_FASTCALL calling convention

oved, it's not necessary. METH_VARARGS | METH_KEYWORDS is fine. -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comparing PEP 576 and PEP 580

On Fri, Jul 6, 2018 at 7:50 PM Jeroen Demeyer wrote: > > On 2018-07-05 14:20, INADA Naoki wrote: > > like you ignored my advice about creating realistic benchmark for > > calling 3rd party callable before talking about performance... > > I didn't really want to ignore

Re: [Python-Dev] On the METH_FASTCALL calling convention

rds easily, like Python. So this can be worthless... -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comparing PEP 576 and PEP 580

On Thu, Jul 5, 2018 at 9:02 PM Jeroen Demeyer wrote: > > On 2018-07-05 13:32, INADA Naoki wrote: > > Core devs interested in this area is limited resource. > > I know and unfortunately there is nothing that I can do about that. It > would be a pity that PEP 580 (or a

Re: [Python-Dev] Comparing PEP 576 and PEP 580

On Thu, Jul 5, 2018 at 6:31 PM Jeroen Demeyer wrote: > > On 2018-07-05 05:41, INADA Naoki wrote: > > And stabilizing calling convention is prerequirements of designing new > > calling APIs. > > I don't see why. I made my PEP with the assumption that the > METH_FASTCA

Re: [Python-Dev] Comparing PEP 576 and PEP 580

On Thu, Jul 5, 2018 at 1:13 AM Jeroen Demeyer wrote: > > On 2018-07-04 03:31, INADA Naoki wrote: > > I think both PEPs are relying on FASTCALL calling convention, > > and can't be accepted until FASTCALL is stable & public. > > First of all, the fact that FASTCALL has

Re: [Python-Dev] Comparing PEP 576 and PEP 580

gt; > Thanks, > Jeroen. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com >

Re: [Python-Dev] Examples for PEP 572

string or ternary expression. f-string and ternary expression can do only what expressions can. But PEP 572 expands "what expressions can". I feel PEP 572 breaks border between expression and statement, and it makes readability of dirty code worse. On the other hand, I understand PEP 572 allo

Re: [Python-Dev] Policy on refactoring/clean up

On Wed, Jun 27, 2018 at 2:27 PM Jeroen Demeyer wrote: > On 2018-06-27 00:02, Guido van Rossum wrote: > > And TBH a desire to refactor a lot of code is often a sign of a > > relatively new contributor who hasn't learned their way around the code > > yet, so they tend to want to make the code

Re: [Python-Dev] Policy on refactoring/clean up

t; Real need is important than my preference. If it is needed PEP 580, I'm OK. But I didn't know which part of the PR is required by PEP 580. Regards, -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy on refactoring/clean up

not problem about general policy about refactoring / clean up. It's just my preference. If Victor and Serhiy prefer the PR, I'm OK to merge it. Regards, -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman

Re: [Python-Dev] PEP 580 (C call protocol) draft implementation

pydoc fail for me. I still > have to fix those. > > > Jeroen. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofacandy%40

Re: [Python-Dev] About [].append == [].append

2018年6月21日(木) 20:27 Jeroen Demeyer : > Currently, we have: > > >>> [].append == [].append > False > > However, with a Python class: > > >>> class List(list): > ... def append(self, x): super().append(x) > >>> List().append == List().append > True > > In the former case, __self__ is

Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579

On Thu, Jun 21, 2018 at 2:57 PM Jeroen Demeyer wrote: > On 2018-06-20 17:42, INADA Naoki wrote: > > I don't have any idea about changing METH_FASTCALL more. > > If Victor and Serhiy think so, and PyPy maintainers like it too, I want > > to make it public &g

Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579

blication before evaluating PEP 580. That's my main point, and "from 3.7" part is just a bonus, sorry. -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe

Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579

2018年6月21日(木) 1:59 Serhiy Storchaka : > 20.06.18 18:42, INADA Naoki пише: > > First of all, thank you Jeroen for writing nice PEPs. > > > > When I read PEP 579, I think "6. METH_FASTCALL is private and > undocumented" > > should be solved first. >

Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579

2018年6月21日(木) 1:17 Antoine Pitrou : > On Wed, 20 Jun 2018 18:09:00 +0200 > Victor Stinner wrote: > > > > > If we can't at Python 3.7, I think we should do it at 3.8. > > > > What's the rationale to make it public in 3.7? Can't it wait for 3.8? > > The new PEPs target 3.8 anyway, no? > > > > IMHO

[Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579

lready. I suppose that making it public doesn't make Python 3.7 unstable much. If we can't at Python 3.7, I think we should do it at 3.8. Regards, -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

That's why I suggested to add new benchmark. 2018年6月19日(火) 22:22 Ivan Levkivskyi : > On 19 June 2018 at 13:02, Nick Coghlan wrote: > >> On 19 June 2018 at 16:12, INADA Naoki wrote: >> > >> > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer >> wrote: >>

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer wrote: > On 2018-06-18 16:55, INADA Naoki wrote: > > Speeding up most python function and some bultin functions was very > > significant. > > But I doubt making some 3rd party call 20% faster can make real > > appl

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

making some 3rd party call 20% faster can make real applications significant faster. -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/opt

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

I didn't meant comparing tp_fastcall and your PEP. I just meant we need to compare complexity and benefit (performance), and we need reference implementation for comparing. On Mon, Jun 18, 2018 at 3:03 PM Jeroen Demeyer wrote: > On 2018-06-18 03:34, INADA Naoki wrote: > > Victor

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

it covers most calls. But calling callable object other than them are relatively rare. It may not affect real world performance of most applications. So, until I can compare it's complexity and benefits, I can say only "it's interesting." Regards, -- I

Re: [Python-Dev] Keeping an eye on Travis CI, AppVeyor and buildbots: revert on regression

​ ​2018年6月7日(木) 2:44 Brett Cannon : > > On Wed, 6 Jun 2018 at 09:27 INADA Naoki wrote: > >> First I was also >>> confused between travis-ci.com and travis-ci.org ... The documentation >>> shows an example with .com, but Python organization uses .org. >&g

Re: [Python-Dev] Keeping an eye on Travis CI, AppVeyor and buildbots: revert on regression

> > First I was also > confused between travis-ci.com and travis-ci.org ... The documentation > shows an example with .com, but Python organization uses .org. > > Victor > .org is legacy. Open source projects can migrate to new .com. Maybe, ssh is .com only feature.

[Python-Dev] Compact GC Header

and buildbots are stable, if Antoine or other GC expert accept it. I estimate it reduces 5% memory usage (RSS) and negligible performance difference. If someone interested in it, please test and benchmark it on GC heavy application. Regards, -- INADA Naoki

Re: [Python-Dev] Add __reversed__ methods for dict

On Sun, May 27, 2018 at 12:43 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > On May 26, 2018, at 7:20 AM, INADA Naoki <songofaca...@gmail.com> wrote: > > > > Because doubly linked list is very memory inefficient, every implementation > > wo

Re: [Python-Dev] Add __reversed__ methods for dict

tion order" is requirement from 3.7 which is not released yet. I feel it's too early to add more stronger requirements to core type. Regards, --- INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@python.org https

Re: [Python-Dev] Python startup time

2018年5月15日(火) 2:17 Antoine Pitrou <anto...@python.org>: > > Le 14/05/2018 à 19:12, INADA Naoki a écrit : > > I'm sorry, the word *will* may be stronger than I thought. > > > > I meant if memory image dumped on disk is used casually, > > it m

Re: [Python-Dev] Python startup time

useful and safe when it's used carefully. Regards, On Tue, May 15, 2018 at 1:58 AM Antoine Pitrou <solip...@pitrou.net> wrote: > On Tue, 15 May 2018 01:33:18 +0900 > INADA Naoki <songofaca...@gmail.com> wrote: > > > > It will broke hash randomization. > > > >

Re: [Python-Dev] Python startup time

-CHB It will broke hash randomization. See also: https://www.cvedetails.com/cve/CVE-2017-11499/ Regards, -- Inada Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.

Re: [Python-Dev] Python startup time

Recently, I reported how stdlib slows down `import requests`. https://github.com/requests/requests/issues/4315#issuecomment-385584974 For Python 3.8, my ideas for faster startup time are: * Add lazy compiling API or flag in `re` module. The pattern is compiled when first used. * Add IntEnum and

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

(e.g. bytes[index]) when doing such big change next time. -- INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailm

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On Fri, Apr 27, 2018 at 10:52 AM Paul G wrote: > Rust has a few syntactic ways to accomplish the same thing, though. I think match expressions are used for the equivalent of conditionals that carry the condition value into the body of the expression, and all blocks return the

Re: [Python-Dev] Timing for removing legacy Unicode APIs deprecated by PEP 393

ytes, but for memoryview, which doesn't guarantee any alignment. > Oh, I'm sad about hear that... > Note that after removing the wchar_t* field the gap will not gone, because > the size of the structure should be a multiple of the alignment of the first > field (which is a pointer). Of

[Python-Dev] Timing for removing legacy Unicode APIs deprecated by PEP 393

oving `wstr` before `state`. Off course, it needs siphash support 4byte aligned data instead of 8byte. Regards, -- INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/pyt

Re: [Python-Dev] Trying to build from source, test-poplib fails

FYI, there is filed issue. https://bugs.python.org/issue33099 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Nuking wstr [Re: How can we use 48bit pointer safely?]

tring object is not negligible. But, of course, it's vary according to applications and libraries. -- INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https

Re: [Python-Dev] Nuking wstr [Re: How can we use 48bit pointer safely?]

Some of APIs are stated as "Deprecated since version 3.3, will be removed in version 4.0:". e.g. https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_AS_UNICODE So we will remove them (and wstr) at Python 4.0. ___ Python-Dev mailing list

[Python-Dev] How can we use 48bit pointer safely?

hash and 48bit*2 for key and value. CompactEntry may be 16byte instead of 24byte. Regards, -- INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscri

Re: [Python-Dev] Replacing self.__dict__ in __init__

a, b, c): ... self.a, self.b, self.c = a, b, c ... >>> class D: ... def __init__(self, a, b, c): ... self.__dict__ = {'a':a, 'b':b, 'c':c} ... >>> import sys >>> sys.getsizeof(C(1,2,3).__dict__) 112 >>> sys.getsizeof(D(1,2,3).__dict__) 240 -- INADA

[Python-Dev] Backward incompatible change about docstring AST

So it's backward incompatible for both of reading and writing docstring too. But it keeps lineno and column of docstring in AST. 3 is most conservative because 3.7b2 was cut now and there are some tools supporting 3.7 already. I prefer 2 or 3. If we took 3, I don't want to do 2 in 3.8. One backw

Re: [Python-Dev] OS-X builds for 3.7.0

gt;=1.2x,<1.3x faster. > 5 that are >=1.1x,<1.2x faster. > 0 that are < 1.1x faster/slower. > > Pretty good numbers overall I think. > > Yay!! Congrats for all of us! -- INADA Naoki <songofaca...@gmail.com> ___

[Python-Dev] GH-NNNN vs #NNNN in merge commit

re are more # than GH- in commit log. https://github.com/python/cpython/commits/master Where should we go? Encourage GH-? or abandon it and use default #NNNN? Regards, -- INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mail

Re: [Python-Dev] Decision of having a deprecation period or not for changing csv.DictReader returning type.

applications loading large CSV with DictReader. While I think application should use tuple when memory consumption is matter, there is significant benefit. INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@python.org https

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

OrderedDict implementation. Regards, INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

nough room to optimize. * It can make stop discussion like "Does X keeps insertion order? It's language spec?", "What about Y? Z?". Everything on top of dict keeps insertion order. It's simple to learn and explain. Regards, INADA Naoki <songofaca...@gmail.com> On Su

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

TF-8 should use surrogateescape, it may make confusing situation like: "This script works in English Linux desktop, but doesn't work in Japanese Linux desktop!" I accepted PEP 540. So even if failed to coerce locale, it is better than Python 3.6. Regards, INADA Naoki

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

Except one typo I commented on Github, I accept PEP 540. Well done, Victor and Nick for PEP 540 and 538. Python 3.7 will be most UTF-8 friendly Python 3 than ever. INADA Naoki <songofaca...@gmail.com> On Mon, Dec 11, 2017 at 2:21 AM, Victor Stinner <victor.stin...@gmail.com> wr

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

"surrogateescape" default for stdin > and stderr error handling to also apply to the three potential coercion > target locales. https://www.python.org/dev/peps/pep-0538/#defaulting-to-surrogateescape-error-handling-on-the-standard-io-streams I don't think en_US.UTF-8 should use su

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

licitly, locale coercion affects Python code too. locale.getpreferredencoding() is UTF-8, open()' s default encoding is UTF-8, and stdio is UTF-8/surrogateescape. So shouldn't this sentence is: "Locale coercion impacts both of Python code and non-Python code like C libraries, whereas ..."?

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

ps://www.python.org/dev/peps/pep-0538/#changes-to-the-default-error-handling-on-the-standard-streams Since coercion target locales and UTF-8 mode do same thing, I think this is not a big issue. But I want it is clarified in the PEP. Regards, --- INADA Naoki <songofaca...@gmail.com>

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

> Or locale.getpreferredencoding() returns UTF-8 in UTF-8 mode too? Or should we change loale.getpreferredencoding() to return UTF-8 instead of ASCII always, regardless of PEP 538 and 540? INADA Naoki <songofaca...@gmail.com> ___ Python-De

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)

on locale.getpreferredencoding() may raise UnicodeErrors. Am I correct? Or locale.getpreferredencoding() returns UTF-8 in UTF-8 mode too? INADA Naoki <songofaca...@gmail.com> On Fri, Dec 8, 2017 at 9:50 AM, Victor Stinner <victor.stin...@gmail.com> wrote: > Hi, > > I made the following two c

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

ary data, not UTF-8 return f.read() I'm not sure about this is good idea. And I don't know when is good for changing write error handler; only when PEP 538 or PEP 540 is used? Or always when os.fsencoding() is UTF-8? Any thoughts? INADA Naoki <songofaca...@gmail.com> _

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

>> And I have one worrying point. >> With UTF-8 mode, open()'s default encoding/error handler is >> UTF-8/surrogateescape. > > The Strict UTF-8 Mode is for you if you prioritize correctness over usability. Yes, but as I said, I cares about not experienced developer who doesn't know what UTF-8

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

r, without modifying code to use "surrogateescape" explicitly. Which is more important scenario? Anyone has opinion about it? Are there any rationals and use cases I missing? Regards, INADA Naoki <songofaca...@gmail.com> On Wed, Dec 6, 2017 at 12:17 PM, INADA Naoki <songofa

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

I'm sorry about my laziness. I've very busy these months, but I'm back to OSS world from today. While I should review carefully again, I think I'm close to accept PEP 540. * PEP 540 really helps containers and old Linux machines PEP 538 doesn't work. And containers is really important for

Re: [Python-Dev] OrderedDict(kwargs) optimization?

eal performance gain. > Is there an opportunity to support a fast cast to OrderedDict from 3.6 dict? > Can it just copy .keys() into the OrderedDict linked list?Or is there more > overhead to the transition? https://bugs.python.org/issue31265 Regards, INADA Naoki <songofa

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

ef __init__(self): self.a, self.b, self.c = 1, 2, 3 a = A() print(a.__dict__) a.__dict__.pop('a') print(a.__dict__) Anyway, I'm -1 on adding such option to dict. dict in CPython is complicated already for performance and compatibility reason. I don't want to add more complexity to dict for s

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> 2. Switches keyword args and class body execution namespaces over to > odict so the test suite passes again > 3. Measures the impact such a change would have on the benchmark suite For now, odict use twice memory and 2x slower on iteration. https://bugs.python.org/issue31265#msg3019

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> By the way, I only just realized I can delete a key to demonstrate > non-order-preservation on py 3.6. So at least I know what to tell students > now. > You can't. dict in Python 3.6 preserves insertion order even after key deletion. ___ Python-Dev

Re: [Python-Dev] The current dict is not an "OrderedDict"

ge spec from 3.6. So we should have two mode for such optimization. It makes dict more complicated. So I'm +0.5 on making dict order as language spec, and -1 on "preserves insertion order until deletion" idea. But my expect may be wrong. Serhiy

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

uot;MicroPython is almost compatible with Python language spec, but has some restriction"? If it's very important, how about "strong recommendation for implementations" instead of "language spec"? Users who don't care implementations other than CPython and PyPy can rely on

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

As memory footprint and import time point of view, I prefer string to thunk. We can intern strings, but not lambda. Dict containing only strings is not tracked by GC, dict containing lambdas is tracked by GC. INADA Naoki <songofaca...@gmail.com> On Tue, Nov 7, 2017 at 8:20 AM, Lukasz

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

t have strong opinion about what should we do about dict and OrderedDict. But I feel PyPy's approach (using same implementation and just override __eq__ and add move_to_end() method) is most simple. Regards, INADA Naoki <songofaca...@gmail.com> ___

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

I'm 100% agree with Łukasz and Brett. +1 and thanks for writing this PEP. INADA Naoki <songofaca...@gmail.com> On Fri, Nov 3, 2017 at 2:00 AM, Brett Cannon <br...@python.org> wrote: > > > On Thu, 2 Nov 2017 at 08:46 Steven D'Aprano <st...@pearwood.info> wrote: >&

[Python-Dev] Make re.compile faster

LETTER LONG S (0x73, 0x17f), # sſ There are some other `re.I(GNORECASE)` options in stdlib. I'll check them. More optimization can be done with implementing sre_parse and sre_compile in C. But I have no time for it in this year. Regards, -- Inada Naoki <songofaca...@gmail.

Re: [Python-Dev] Python startup optimization: script vs. service

figured out how to satisfy requirements of > both scripts and long running services. We probably need a PEP... > > Christian > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo

[Python-Dev] Investigating time for `import requests`

ke possible to split collection module and strings module. (strings module is used often for constants like strings.ascii_letters, but strings.Template cause import time re.compile()) Regards, -- Inada Naoki <songofaca...@gmail.com> ___ Python-D

Re: [Python-Dev] Memory bitmaps for the Python cyclic garbage collector

Big +1. I love the idea. str (especially, docstring), dict, and tuples are major memory eater in Python. This may reduce tuple memory usage massively. INADA Naoki <songofaca...@gmail.com> On Fri, Sep 8, 2017 at 2:30 AM, Neil Schemenauer <n...@python.ca> wrote: >

Re: [Python-Dev] HTTPS on bugs.python.org

Fixed. Thanks to infra team. http://psf.upfronthosting.co.za/roundup/meta/issue638 INADA Naoki <songofaca...@gmail.com> On Fri, Sep 1, 2017 at 9:57 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > Hi, > > When I go to http://bugs.python.org/ Firefox warns me that t

Re: [Python-Dev] To reduce Python "application" startup time

549: Instance Properties (aka: module properties)") * Optimize enum creation. * Faster namedtuple (There is pull request already) * Faster ABC * Breaking large import tree in stdlib. (PEP 549 may help this too) Regards, INADA Naoki <songofaca...@gmail.com> __

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

OK, I stop worring about thread safety and other implementation detail behavior on edge cases. Thanks, INADA Naoki <songofaca...@gmail.com> On Wed, Sep 6, 2017 at 7:40 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 6 September 2017 at 11:09, Antoine Pitrou <solip...

Re: [Python-Dev] To reduce Python "application" startup time

example is GAE/Python. Anyway, I think researching import tree of popular library is good startline about optimizing startup time. For example, modules like ast and tokenize are imported often than I thought. Jinja2 is one of libraries I often use. I'm checking other libraries like requests. Thank

Re: [Python-Dev] To reduce Python "application" startup time

>> This patch moves a few imports inside functions. I wonder whether that kind >> of change actually helps with real applications—doesn't any real application >> end up importing the socket module anyway at some point? > > I don't know if this particular change is worthwhile, but one place > where

Re: [Python-Dev] To reduce Python "application" startup time

>> With this profile, I tried optimize `python -c 'import asyncio'`, logging >> and http.client. >> >> >> https://gist.github.com/methane/1ab97181e74a33592314c7619bf34233#file-0-optimize-import-patch >> > This patch moves a few imports inside functions. I wonder whether that kind > of change

Re: [Python-Dev] To reduce Python "application" startup time

>> >> I haven't created pull request yet. >> (Can I create without issue, as trivial patch?) > > > Trivial, no-issue PRs are meant for things like typo fixes that need no > discussion or record. > > Moving imports in violation of the PEP 8 rule, "Imports are always put at > the top of the file,

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

urrently, dict ordering is implementation detail of CPython and PyPy. We don't recommend to rely on the behavior. Like that, should we say "atomic & threadsafe __setitem__ for simple key is implementation detail of CPython and PyPy. We recommend using mutex when using OrderedDict from multiple

Re: [Python-Dev] [python-committers] Cherry picker bot deployed in CPython repo

Congrats! INADA Naoki <songofaca...@gmail.com> On Wed, Sep 6, 2017 at 10:10 AM, Mariatta Wijaya <mariatta.wij...@gmail.com> wrote: > Hi, > > The cherry picker bot has just been deployed to CPython repo, codenamed > miss-islington. > > miss-islington made the very

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

First of all, I saw enough -1 so I gave up about removing. Following reply is just a technical topic. On Wed, Sep 6, 2017 at 2:13 AM, Eric Snow wrote: [snip] > > Like Antoine, I consider the pure Python implementation to be > valuable. Furthermore, the pure Python

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

On Tue, Sep 5, 2017 at 8:48 PM, Serhiy Storchaka <storch...@gmail.com> wrote: > 05.09.17 11:38, INADA Naoki пише: >> >> ## Cons >> >> * All Python 3.7 implementations should provide _collections.OrderedDict >>PyPy has it already. But I don't

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

? (just curious). But in this case, not only for optimize, but also better behavior. Pure Python version is not thread safe even for `od[k] = v`. It's very difficult to write thread safe complex container in Pure Python. Regards, INADA Naoki <songofaca...@gmail.com> _

[Python-Dev] To reduce Python "application" startup time

e without issue, as trivial patch?) I'm very busy these days, maybe until December. But I hope this report helps people working on optimizing startup time. Regards, INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@p

[Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

, and _OrderedDictValuesView). Three of them inheriting from ABC. So it makes importing collections bit slower. ## Cons * All Python 3.7 implementations should provide _collections.OrderedDict PyPy has it already. But I don't know about micropython. Regards, INADA Naoki <songof

Re: [Python-Dev] HTTPS on bugs.python.org

://bugs.python.org/' instead of 'https://bugs.python.org/' INADA Naoki <songofaca...@gmail.com> On Fri, Sep 1, 2017 at 10:29 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Fri, 1 Sep 2017 22:15:29 +0900 > INADA Naoki <songofaca...@gmail.com> wrote: >> FYI, there i

Re: [Python-Dev] HTTPS on bugs.python.org

FYI, there is issue report for it. http://psf.upfronthosting.co.za/roundup/meta/issue463 INADA Naoki <songofaca...@gmail.com> On Fri, Sep 1, 2017 at 9:57 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > Hi, > > When I go to http://bugs.python.org/ Firefox w

Re: [Python-Dev] PEP 442 undocumented C API functions

y (like `__del__`), I agree with you. But I'm not good English writer. Contribution is welcome. Regards, INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/pyt

[Python-Dev] Could someone review GH-2974 which add missing PyObject_GC_UnTrack()?

unsafe tp_dealloc. Even "extending and embedding" document missed untracking. Regards, INADA Naoki <songofaca...@gmail.com> ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Uns

Re: [Python-Dev] Python startup time

On Fri, Jul 21, 2017 at 4:12 PM, David Mertz wrote: > How implausible is it to write out the actual memory image of a loaded > Python process? I.e. on a specific machine, OS, Python version, etc? This > can only be overhead initially, of course, but on subsequent runs it's just >

Re: [Python-Dev] Python startup time

Hi, Ivan. First of all, Yes, please do it! On Thu, Jul 20, 2017 at 8:24 PM, Ivan Levkivskyi wrote: > I agree the start-up time is important. There is something that is related. > ABCMeta is currently implemented in Python. > This makes it slow, creation of an ABC is 2x

Re: [Python-Dev] Impact of Namedtuple on startup time

al pattern in CPython. But namedtuple is very widely used. It's loved enough to get optimized for not only CPython. So I prefer Jelle's approach to adding code cache machinery in this case. Regards, INADA Naoki <songofaca...@gmail.com> ___ Python-

Re: [Python-Dev] deque implementation question

use of realloc(), * resulting in more predictable performance. Regards, INADA Naoki <songofaca...@gmail.com> On Sat, Jul 15, 2017 at 4:01 PM, Max Moroz <maxmo...@gmail.com> wrote: > What would be the disadvantage of implementing collections.deque as a > circular array (ra

Re: [Python-Dev] Pure pickle bechmark.

I said about pure Python implementation (unpickle_pure_python), because mail title is "Pure pickle bechmark". INADA Naoki <songofaca...@gmail.com> On Mon, Jul 10, 2017 at 8:36 AM, Victor Stinner <victor.stin...@gmail.com> wrote: > Wait. Are we talking about the C accel

Re: [Python-Dev] Pure pickle bechmark.

ead directly instead of _Unframer.read. Regards, INADA Naoki <songofaca...@gmail.com> On Sun, Jul 9, 2017 at 11:08 PM, Bhavishya <bhavishyagop...@gmail.com> wrote: > Hello, > > 1).I was going through the code of python pickle to search any optimization > possibility.But the onl

Re: [Python-Dev] PEP 538 warning at startup: please remove it

>> -1 for disable coercion by default: It's too unhelpful for beginners. > > Are you proposing to reject the PEP that you approved? Now I'm confused. > No, I just wanted to clarify your propose. You said "I'm able to render my hello world with the wrong locale :-)". So I want to clarify you

Re: [Python-Dev] PEP 538 warning at startup: please remove it

On Mon, Jun 12, 2017 at 6:46 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > 2017-06-12 11:35 GMT+02:00 INADA Naoki <songofaca...@gmail.com>: >> I think "Good practice" is set `LC_CTYPE=C.UTF-8` environment variable, >> as warning says. > > I

Re: [Python-Dev] PEP 538 warning at startup: please remove it

On Mon, Jun 12, 2017 at 5:56 PM, Victor Stinner wrote: > Hi, > > Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step > forward to UTF-8 everywhere ;-) > > I would prefer to not be annoyed by warning messages about encodings > at startup if possible: >

Re: [Python-Dev] PEP 538 (review round 2): Coercing the legacy C locale to a UTF-8 based locale

> On 12/06/2017, Nick Coghlan wrote: >> >> `PYTHONIOENCODING=:strict` remains the preferred way of forcing strict >> encoding checks on the standard streams, regardless of locale. > > Then the user of my script has to care that it's written in Python and > set that

Re: [Python-Dev] The untuned tunable parameter ARENA_SIZE

> I would be curious of another test: use pymalloc for objects larger > than 512 bytes. For example, allocate up to 4 KB? Since current pool size is 4KB and there is pool_header in pool, we can't allocate 4KB block from pool. And if support 1KB block, only 3KB of 4KB can be actually used. I think

<    1   2   3   4   5   6   >