Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations
Impressive stats! I didn’t know this command, thanks! On Fri, 3 Nov 2017 at 20:47, Barry Warsaw wrote: > On Nov 2, 2017, at 23:22, Nick Coghlan wrote: > > Another point worth noting is that merely importing the typing module > > is expensive: > > > > $ python -m perf timeit -s "from importlib import reload; import > > typing" "reload(typing)" > > . > > Mean +- std dev: 10.6 ms +- 0.6 ms > > > > 10 ms is a *big* chunk out of a CLI application's startup time budget. > > Far and away so, except for the re module. > > % ./python.exe -X importtime -c "import typing" > import time: self [us] | cumulative | imported package > import time:72 | 72 | _codecs > import time: 625 |696 | codecs > import time: 354 |354 | encodings.aliases > import time: 713 | 1762 | encodings > import time: 198 |198 | encodings.utf_8 > import time:98 | 98 | _signal > import time: 233 |233 | encodings.latin_1 > import time: 353 |353 | _weakrefset > import time: 264 |617 | abc > import time: 402 | 1018 | io > import time: 136 |136 | _stat > import time: 197 |333 | stat > import time: 227 |227 | genericpath > import time: 377 |604 | posixpath > import time: 2812 | 2812 | _collections_abc > import time: 787 | 4534 | os > import time: 315 |315 | _sitebuiltins > import time: 336 |336 | sitecustomize > import time: 114 |114 | usercustomize > import time: 1064 | 6361 | site > import time: 160 |160 | _operator > import time: 1412 | 1571 | operator > import time: 371 |371 | keyword > import time: 817 |817 | _heapq > import time: 762 | 1579 | heapq > import time: 272 |272 | itertools > import time: 635 |635 | reprlib > import time:99 | 99 | _collections > import time: 3580 | 8104 | collections > import time: 112 |112 | _functools > import time: 781 |892 | functools > import time: 1774 | 2666 | contextlib > import time: 272 |272 | types > import time: 861 | 1132 | enum > import time:76 | 76 | _sre > import time: 426 |426 | sre_constants > import time: 446 |872 | sre_parse > import time: 414 | 1361 | sre_compile > import time:79 | 79 | _locale > import time: 190 |190 | copyreg > import time: 17200 | 19961 | re > import time: 374 |374 | collections.abc > import time: 15124 | 46226 | typing > > -Barry > > ___ > 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/luca.sbardella%40gmail.com > -- http://lucasbardella.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] 2.x vs 3.x survey results
On 4 January 2014 19:21, Scott Dial wrote: > On 2014-01-02 17:54, Dan Stromberg wrote: > > I put it at https://wiki.python.org/moin/2.x-vs-3.x-survey > > It would've been nice to see some crosstabs. Pretty much any question > after Q3 is incomprehensible without splitting the respondents into > sub-groups first. > > Of the 2.49% of people who said they've never written Python 2.x, how > many of those people also said they have never written Python 3.x too? > (There really is 4 categories of developers being surveyed here.) Of the > 22.91% of people who said Python 3.x was a mistake, how many of them > also said they have never written any Python 3.x? Of the 40% of people > who said they have never written Python 3.x, how many of them also said > they had dependencies keeping them on Python 2.x? Etc. > > -- > Scott Dial > sc...@scottdial.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/luca.sbardella%40gmail.com > Hi guys, you are my heroes but this survey is quite useless, can you include more people? I wasn't aware of it so many thousands of python users. And after that, you are well aware that Python 3 or 2 is becoming a liability, just stick with one, anyone (3) at this point. I don't want to go and learn a new language, please. Sorry for the rant ___ 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] PEP 469: Restoring the iterkeys/values/items() methods
Hi Guys, please don't do it! We don't need this legacy really. On 21 April 2014 08:41, Armin Rigo wrote: > Hi Nick, > > On 21 April 2014 07:39, Nick Coghlan wrote: > > Notably, I recommend that hybrid code avoid calling mapping iteration > > methods directly, and instead rely on builtin functions where possible, > > and some additional helper functions for cases that would be a simple > > combination of a builtin and a mapping method in pure Python 3 code, but > > need to be handled slightly differently to get the exact same semantics > in > > Python 2. > > How about explicitly noting that in Python 2, a large fraction of > usages of the iterkeys(), itervalues() and iteritems() methods (that's > more than 99% in my experience, but I might be biased) should just be > written as keys(), values() and items() in the first place, with no > measurable difference of performance or memory usage? I would > recommend to anyone with a large Python 2 code base to simply do a > textual search-and-replace and see if any test breaks. If not, > problem solved. > > Couldn't agree more with Armin. -- http://lucasbardella.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
[Python-Dev] wsgi validator with asynchronous handlers/servers
Hi, I have an asynchronous wsgi application handler which yields empty bytes before it is ready to yield the response body and, importantly, to call start_response. Something like this: def wsgi_handler(environ, start_response): body = generate_body(environ) body = maybe_async(body) while is_async(body): yield b'' start_response(...) ... I started using wsgiref.validator recently, nice little gem in the standard lib, and I discovered that the above handler does not validate! Disaster. Reading pep "the application *must* invoke the start_response() callable before the iterable yields its first body bytestring, so that the server can send the headers before any body content. However, this invocation *may* be performed by the iterable's first iteration, so servers *must not* assume that start_response() has been called before they begin iterating over the iterable." The pseudocode above does yields bytes before start_response, but they are not *body* bytes, they are empty bytes so that the asynchronous wsgi server releases the eventloop and call back at the next eventloop iteration. I'm I misinterpreting the pep, or the wsgi validator should be fixed accordingly? Regards, Luca ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
