Mailman 3 March 2017 - Python-Dev

API design: where to add async variants of existing stdlib APIs?
by Nick Coghlan March 10, 2017

March 10, 2017

Short version: - there are some reasonable requests for async variants of contextlib APIs for 3.7 - prompted by Raymond, I'm thinking it actually makes more sense to add these in a new `asyncio.contextlib` module than it does to add them directly to the existing module - would anyone object strongly to my asking authors of the affected PRs to take their changes in that direction? Longer version: There are a couple of open issues requesting async variants of some contextlib APIs (asynccontextmanager and AsyncExitStack). I'm inclined to accept both of them, but Raymond raised a good question regarding our general design philosophy for these kinds of additions: would it make more sense to put these in an "asyncio.contextlib" module than it would to add them directly to contextlib itself? The main advantage I see to the idea is that if someone proposed adding an "asyncio" dependency to contextlib, I'd say no. For the existing asynccontextmanager PR, I even said no to adding that dependency to the standard contextlib test suite, and instead asked that the new tests be moved out to a separate file, so the existing tests could continue to run even if asyncio was unavailable for some reason. While rejecting the idea of an asyncio dependency isn't a problem for asyncontextmanager specifically (it's low level enough for it not to matter), it's likely to be more of a concern for the AsyncExitStack API, where the "asyncio.iscoroutinefunction" introspection API is likely to be quite helpful, as are other APIs like `asyncio.ensure_future()`. So would folks be OK with my asking the author of the PR for https://bugs.python.org/issue29679 (adding asynccontextmanager) to rewrite the patch to add it as asyncio.contextlib.asyncontextmanager (with a cross-reference from the synchronous contextlib docs), rather than the current approach of adding it directly to contextlib? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

15 19

Sharing our python articles with python community
by Yaroslav Lehenchuk March 10, 2017

March 10, 2017

Hi! My name is Yaroslav, I am a member of geeks team - Django Stars. We just released 2 good posts and I'd like to propose you to share them with your digest readers. 1. I hope that two articles is not too much for one digest. In case that is — we can separate those between two digests. 2. I hope that you are ok with me marking urls with utm-tags — it's pretty important for us to monitor the website's incoming traffic and understand the visitors` behavior. 1. Docker. http://djangostars.com/blog/heres-how-you-start-using- docker?utm_source=dbader&utm_campaign=Pythondigest&utm_medium=post 2. django-classifier http://djangostars.com/blog/django-classifier-or-what- have-i-done?utm_source=dbader&utm_campaign=Pythondigest&utm_medium=post 2.1 Library https://github.com/django-stars/django-classifier 2.2 Two examples how to use it https://github.com/django-stars/django-classifier-profile https://github.com/django-stars/django-classifier-shop Thanks in advance and have a nice day! -- Best Regards, Yaroslav Lehenchuk Marketer at Django Stars Cell: +380730903748 Skype: yaroslav_le Email: yaroslav.lehenchuk(a)djangostars.com <http://djangostars.com>

1 0

Can I revoke PEP 103 (info about git)?
by Oleg Broytman March 9, 2017

March 9, 2017

Hello! When I was writing PEP 103 I wanted to help to start using git. There were a few proponents and a few opponents: people expressed concerns that the PEP is too generic and isn't really related to Python development so I promised to revoke the PEP after the switch to git and Github. Now I think is the time. I hope revocation of the PEP wouldn't cause any problem? I'm gonna publish it at wiki.p.o. Oleg. -- Oleg Broytman http://phdru.name/ phd(a)phdru.name Programmers don't die, they just GOSUB without RETURN.

5 9

Impoverished compare ...
by Erik March 9, 2017

March 9, 2017

Hi. I'm looking at stuff proposed over on Python-Ideas, and I'd appreciate some pointers as to the basics of how C-level objects are generally compared in Python 3. The issue is related to the performance of PyObject_RichCompare. I got to the point where I was trying to work out what was the _alternative_ to RichCompare. If a comparison is not "rich", then what is it? There's a tp_richcompare slot in the type structure, but I haven't noticed anything else obvious for simple comparison (In 2.x days - which I have more experience with - __cmp__ was a thing which now seems to be gone. I understand the Python-level changes with sort(..., key=foo) but I've not looked at the underlying C implementation until now). Anyway, I followed things as far as Objects/typeobject.c and then I got bitten by a macro dialect that I don't immediately grok, so anything that spells it out a bit more plainly would be nice (I can follow the code if I need to - but a shortcut from those who know this off the top of their head would be helpful). Thanks, E.

2 1

iscoroutinefunction vs. coroutines
by Matthias Urlichs March 9, 2017

March 9, 2017

Hi, Is this pattern def foo(): return bar() async def bar(): await <whatever> async def async_main(): await foo() considered to be valid? The reason I'm asking is that some code out there likes to accept a might-be-a-coroutine-function argument, using def run_callback(fn): if iscoroutinefunction(fn): res = await fn() else: res = fn() instead of def run_callback(fn): res = fn() if iscoroutine(res): res = await res() The former obviously breaks when somebody combines these idioms and calls run_callback(foo) but I can't help but wonder whether the latter use might be deprecated, or even warned about, in the future and/or with non-CPython implementations. -- -- Matthias Urlichs

2 1

Python Design issue with print() function
by ravi y March 8, 2017

March 8, 2017

Hi Python Developers, print() function has a slight design issue, when user gives start and end positions of character array.Issue: >>> str_ary="abcdef" >>> print(str_ary[1]) b >>> print(str_ary[4]) e >>> print(str_ary[1:4]) bcd >>> In the above scenario, user is expecting that output of print function will be bcde (not bcd). Analysis: I kind of figured out what could be the issue. To get the string slice, "between" (or equivalent) was used. i.e. str_ary array position >=1 and < 4 Solution: User experience will be better if the code is updated to get last character. i.e str_ary array position >=1 and <= 4 Note: To keep the code as backward compatibility, you may come up with different name like printf() ThanksRavi Yarlagadda

2 1

3.6.1 release status and plans
by Ned Deily March 8, 2017

March 8, 2017

An update on the 3.6.1 release: As you probably noticed, 3.6.1 release candidate 1 was made available (finally!) two days ago. Thank you for your patience as we worked though the details of producing a release using our new GitHub-based development workflow. As we've noted, it's really important for all segments of the community to try using 3.6.1rc1 to help make sure something didn't break along the way. Please report any potential problems via the bugs.python.org tracker and mark them as "release blocker". Because rc1 was delayed a week, I've moved the planned release date for 3.6.1 final back a week as well, now 2017-03-20. That gives two weeks of exposure for rc1. The plan is to, if at all possible, not ship any additional changes in the final beyond what is already in rc1 unless we discover any release-blocking critical problems in rc1. The 3.6 branch remains open for new cherry-pick PRs etc but you should expect that any PRs that are merged into the 3.6 branch since the v3.6.1rc1 tag will first be released in 3.6.2, expected before the end of June (about 3 months). Again, if something critical comes up that you feel needs to be in 3.6.1, you need to make sure the issue is marked as a "release blocker" and you should make sure I am aware of it. If any such release blockers do arise, we will discuss them and decide whether they should go into 3.6.1 and whether a second release candidate is needed. Thanks for your support! --Ned -- Ned Deily nad(a)python.org -- []

2 1

Reports on my CPython contributions
by Victor Stinner March 5, 2017

March 5, 2017

Hi, Recently, I wrote reports of my CPython contributions since 1 year 1/2. Some people on this list might be interested, so here is the list. I was also asked for more documentation about my work on FASTCALL and its effect on performance. You can expect more article on FASTCALL later, especially on its API and its implementaiton. == CPython contrib 2016 == My contributions to CPython during 2016 Q1: https://haypo.github.io/contrib-cpython-2016q1.html My contributions to CPython during 2016 Q2: https://haypo.github.io/contrib-cpython-2016q2.html PEP 524: os.urandom() now blocks on Linux in Python 3.6: https://haypo.github.io/pep-524-os-urandom-blocking.html CPython sprint, september 2016: https://haypo.github.io/cpython-sprint-2016.html My contributions to CPython during 2016 Q3: https://haypo.github.io/contrib-cpython-2016q3.html My contributions to CPython during 2016 Q4: https://haypo.github.io/contrib-cpython-2016q4.html == FASTCALL project == The start of the FASTCALL project: https://haypo.github.io/start-fastcall-project.html FASTCALL microbenchmarks: https://haypo.github.io/fastcall-microbenchmarks.html FASTCALL issues: https://haypo.github.io/fastcall-issues.html == CPython contrib 2015 == My contributions to CPython during 2015 Q3: https://haypo.github.io/contrib-cpython-2015q3.html My contributions to CPython during 2015 Q4: https://haypo.github.io/contrib-cpython-2015q4.html Victor

3 3

[RELEASE] Python 3.6.1rc1 is now available
by Ned Deily March 5, 2017

March 5, 2017

On behalf of the Python development community and the Python 3.6 release team, I would like to announce the availability of Python 3.6.1rc1. 3.6.1rc1 is the first release candidate for Python 3.6.1, the first maintenance release of Python 3.6. 3.6.0 was released on 2017-12-22 to great interest and now, three months later, we are providing the first set of bugfixes and documentation updates for it. While 3.6.1rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). Although it should be transparent to users of Python, 3.6.1 is the first release after some major changes to our development process so we ask users who build Python from source to be on the lookout for any unexpected differences. 3.6.1 is planned for final release on 2017-03-20 with the next maintenance release expected to follow in about 3 months. Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.1rc1 here: https://www.python.org/downloads/release/python-361rc1/ More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

3 3

Type annotations and metaclasses
by Thomas Hauk March 3, 2017

March 3, 2017

I've read through PEPs 483, 484, and 526, but I don't see any discussion of how type hints should work when the type of a class member differs from the type of an instance member, like when metaclasses are used to create instances. e.g.: >>> from django.db import models >>> class MyModel(models.Model): ... name = models.CharField() ... class Meta: ... app_label = "myapp" ... >>> type(MyModel.name) <class 'django.db.models.query_utils.DeferredAttribute'> >>> m = MyModel() >>> type(m.name) <class 'str'> In this case, I would like to be able to specify an instance type of str for MyModel.name. Can someone point me to any existing relevant discussion? Or if not, where should a new discussion start? T

2 1