Re: [Python-Dev] PEP 548: More Flexible Loop Control

On Wed, Sep 6, 2017 at 10:11 AM, R. David Murray wrote: > I've written a PEP proposing a small enhancement to the Python loop > control statements. Short version: here's what feels to me like a > Pythonic way to spell "repeat until": > > while: > >

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

On Wed, Sep 6, 2017 at 2:30 PM, INADA Naoki wrote: >>> 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?

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,

[Python-Dev] Looking for review on small argparse patch

As argparse seems to not have a current maintainer, I'm hoping a volunteer could review this small patch to the argparse module. I posted the PR nearly a month ago and have not received any feedback yet: https://github.com/python/cpython/pull/3027 bpo link: https://bugs.python.org/issue26510

Re: [Python-Dev] PEP 553: Built-in debug()

Yeah, I like the idea, but I don't like the debug() name -- IIRC there's a helper named debug() in some codebase I know of that prints its arguments under certain circumstances. On Tue, Sep 5, 2017 at 7:58 PM, Nathaniel Smith wrote: > On Tue, Sep 5, 2017 at 6:14 PM, Barry Warsaw

Re: [Python-Dev] PEP 553: Built-in debug()

On Tue, Sep 5, 2017, at 19:57, Steven D'Aprano wrote: > Sorry, are we to interpret this as you asking that the PEP be rejected? > I can't tell whether you are being poetic and actually think the PEP is > a good idea, or whether you have written it to have it rejected and > prevent anyone else

Re: [Python-Dev] PEP 553: Built-in debug()

On Tue, Sep 05, 2017 at 06:14:12PM -0700, Barry Warsaw wrote: > I’ve written a PEP proposing the addition of a new built-in function > called debug(). Adding this to your code would invoke a debugger > through the hook function sys.debughook(). [...] > P.S. This came to me in a nightmare on

Re: [Python-Dev] PEP 553: Built-in debug()

On Tue, Sep 5, 2017 at 6:14 PM, Barry Warsaw wrote: > I’ve written a PEP proposing the addition of a new built-in function called > debug(). Adding this to your code would invoke a debugger through the hook > function sys.debughook(). The 'import pdb; pdb.set_trace()' dance

Re: [Python-Dev] PEP 553: Built-in debug()

> It's a lot to type (27 characters). True. Personally I have a shortcut in my IDE (Sublime) so I when I type "pdb" -> TAB it auto completes it. > Python linters (e.g. flake8 [1]) complain about this line because it contains two statements. Breaking the idiom up into two lines further

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

> >> For example, when one thread do `od[k1] = v1` and another thread do >> `od[k2] = v2`, >> result should be equivalent to one of `od[k1] = v1; od[k2] = v2;` or >> `od[k2] = v2; od[k1] = v1`. And internal data structure should be >> consistent. > > I agree the pure Python OrderedDict is not

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

Congrats! INADA Naoki On Wed, Sep 6, 2017 at 10:10 AM, Mariatta Wijaya wrote: > Hi, > > The cherry picker bot has just been deployed to CPython repo, codenamed > miss-islington. > > miss-islington made the very first backport PR for CPython

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

This is a great UX win for our development process. Thanks for making this happen! Alex On Tue, Sep 5, 2017 at 9:10 PM, Mariatta Wijaya wrote: > Hi, > > The cherry picker bot has just been deployed to CPython repo, codenamed > miss-islington. > > miss-islington made

[Python-Dev] PEP 553: Built-in debug()

I’ve written a PEP proposing the addition of a new built-in function called debug(). Adding this to your code would invoke a debugger through the hook function sys.debughook(). Like the existing sys.displayhook() and sys.excepthook(), you can change sys.debughook() to point to the debugger of

[Python-Dev] Cherry picker bot deployed in CPython repo

Hi, The cherry picker bot has just been deployed to CPython repo, codenamed miss-islington. miss-islington made the very first backport PR for CPython and became a first time GitHub contributor: https://github.com/python/cpython/pull/3369 GitHub repo: https://github.com/python/miss-islington

Re: [Python-Dev] PEP 550 v4

On Tue, Sep 5, 2017 at 4:59 PM, Greg Ewing wrote: > Yury Selivanov wrote: >> >> Question: how to write a context manager with contextvar.new? >> >> var = new_context_var() >> >>class CM: >> >> def __enter__(self): >> var.new(42) >> >>

[Python-Dev] PEP 548: More Flexible Loop Control

I've written a PEP proposing a small enhancement to the Python loop control statements. Short version: here's what feels to me like a Pythonic way to spell "repeat until": while: break if The PEP goes into some detail on why this feels like a readability improvement in the

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: Question: how to write a context manager with contextvar.new? var = new_context_var() class CM: def __enter__(self): var.new(42) with CM(): print(var.get() or 'None') My understanding that the above code will print "None", because

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On Tue, Sep 5, 2017 at 3:03 PM, Larry Hastings wrote: > > I've written a PEP proposing a language change: > > https://www.python.org/dev/peps/pep-0549/ > > The TL;DR summary: add support for property objects to modules. I've > already posted a prototype. Interesting idea!

[Python-Dev] PEP 549: Instance Properties (aka: module properties)

I've written a PEP proposing a language change: https://www.python.org/dev/peps/pep-0549/ The TL;DR summary: add support for property objects to modules. I've already posted a prototype. How's that sound? //arry/ ___ Python-Dev mailing list

[Python-Dev] Workflow change reminder: The Blurb Has Landed

Yesterday I "blurbified" the 2.7, 3.6, and master branches in CPython. It's finally official: all* branches have now been "blurbified". This means that Misc/NEWS is no longer present in any of CPython's active branches. Instead, Misc/NEWS has been broken up into a zillion little files in

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

On 9/5/2017 2:20 PM, INADA Naoki wrote: On Wed, Sep 6, 2017 at 2:13 AM, Eric Snow wrote: Like Antoine, I consider the pure Python implementation to be valuable. Furthermore, the pure Python implementation is the reference, so its behavior is idiomatic. To this

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

On Tue, Sep 5, 2017 at 11:13 AM, Jelle Zijlstra wrote: > > > 2017-09-05 6:02 GMT-07:00 INADA Naoki : >> With this profile, I tried optimize `python -c 'import asyncio'`, logging >> and http.client. >> >> >>

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

On Wed, 6 Sep 2017 03:20:43 +0900 INADA Naoki wrote: > What is *idiomatic*? For example, in this test case: > > https://github.com/python/cpython/blob/564a2c68add64ebf2e558a54f5697513b19293cb/Lib/test/test_ordered_dict.py#L575-L582 > > def test_dict_delitem(self): >

[Python-Dev] Version and Last-Modified headers are no longer required in PEPs.

The Version and Last-Modified headers required by PEP1 used to be maintained by the version control system, but this is not true now that we've switched to git. We are therefore deprecating these headers and have removed them from PEP1. The PEP generation script now considers them to be

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] To reduce Python "application" startup time

2017-09-05 6:02 GMT-07:00 INADA Naoki : > Hi, > > While I can't attend to sprint, I saw etherpad and I found > Neil Schemenauer and Eric Snow will work on startup time. > > I want to share my current knowledge about startup time. > > For bare (e.g. `python -c pass`)

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

On 9/5/2017 10:40 AM, Guido van Rossum wrote: On Tue, Sep 5, 2017 at 5:58 AM, Simon Cross > wrote: I thought the decision a few years ago was that all modules that have a C library for performance reasons should also

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

On 9/5/2017 9:02 AM, INADA Naoki wrote: But application startup time is more important. And we can improve them with optimize importing common stdlib. Current `python -v` is not useful to optimize import. So I use this patch to profile import time.

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

On Tue, Sep 5, 2017 at 12:13 PM, Eric Snow wrote: > On Tue, Sep 5, 2017 at 1:38 AM, INADA Naoki wrote: >> Like that, how about removing OrderedDict Pure Python implementation >> from stdlib and require it to implementation? > > -1 > > Like

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

On Tue, Sep 5, 2017 at 1:38 AM, INADA Naoki wrote: > Like that, how about removing OrderedDict Pure Python implementation > from stdlib and require it to implementation? -1 Like Antoine, I consider the pure Python implementation to be valuable. Furthermore, the pure

Re: [Python-Dev] Compiling without multithreading support -- still useful?

On 2017-09-05 09:42, Victor Stinner wrote: > I proposed to drop the --without-threads option multiple times. I > worked on tiny and cheap embedded devices and we used Python *with* > threads for concurrency. Many Python features require threads, like > asyncio and multiprocessing. Also

Re: [Python-Dev] Compiling without multithreading support -- still useful?

I proposed to drop the --without-threads option multiple times. I worked on tiny and cheap embedded devices and we used Python *with* threads for concurrency. Many Python features require threads, like asyncio and multiprocessing. Also subprocess.communicate() on Windows, no? I'm strongly in

[Python-Dev] Compiling without multithreading support -- still useful?

Hello, It's 2017 and we are still allowing people to compile CPython without threads support. It adds some complication in several places (including delicate parts of our internal C code) without a clear benefit. Do people still need this? Regards Antoine.

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

On 5 September 2017 at 15:02, INADA Naoki wrote: > Hi, > > [...] > > For bare (e.g. `python -c pass`) startup time, I'm waiting C > implementation of ABC. > Hi, I am not sure I will be able to finish it this week, also this depends on fixing interactions with ABC

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

On Tue, Sep 5, 2017 at 5:58 AM, Simon Cross wrote: > I thought the decision a few years ago was that all modules that have a C > library for performance reasons should also have a Python version? Did this > decision change at some point? (just curious). > It was

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

On Tue, 5 Sep 2017 17:38:06 +0900 INADA Naoki wrote: > > Like that, how about removing OrderedDict Pure Python implementation > from stdlib and require it to implementation? I don't like this. The C version of OrderedDict is probably very hard to read, while the Python

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

On Tue, Sep 5, 2017 at 8:48 PM, Serhiy Storchaka 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 know about micropython. > > > Current C

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

On Tue, Sep 5, 2017 at 9:58 PM, Simon Cross wrote: > I thought the decision a few years ago was that all modules that have a C > library for performance reasons should also have a Python version? Did this > decision change at some point? (just curious). But in this

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

Hi, While I can't attend to sprint, I saw etherpad and I found Neil Schemenauer and Eric Snow will work on startup time. I want to share my current knowledge about startup time. For bare (e.g. `python -c pass`) startup time, I'm waiting C implementation of ABC. But application startup time is

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

I thought the decision a few years ago was that all modules that have a C library for performance reasons should also have a Python version? Did this decision change at some point? (just curious). ___ Python-Dev mailing list Python-Dev@python.org

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

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 know about micropython. Current C implementation of OrderedDict is not safe regarding using mutating dict methods (or dict C API) like

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

Hi, all. Currently, deque and defaultdict have only C implementation. Python implementations should provide _collections.deque and _collections.defaultdict. Like that, how about removing OrderedDict Pure Python implementation from stdlib and require it to implementation? ## Pros ### Thread