[Python-Dev] CRLF problems in repo
Hello folks Along with a few students we were preparing to poke around inside the CPython sources. Of course it would be neat if we submitted useful patches... but since I dont expect to get there so fast I thought I'd start by setting up with git which I am more familiar with than mercurial. That resulted in some adventures... including CRLF issues. Some suggestions on both python mentors list and the general user list did not seem to think these completely irrelevant so reporting here. Can submit a bug-report if it looks ok - Mixed file -- both LF and CRLF (line 29 LF rest CRLF) Lib/venv/scripts/nt/Activate.ps1 Lib/test/decimaltestdata is a directory with mixed up files -- ie some CRLF some LF files PCbuild/readme.txt: CRLF (explicit) This is fine. Many of the following should (ideally/IMHO) be likewise CRLF (not BIN) *.sln: CRLF but marked as BIN in hgeol PC/example_nt/example.vcproj Emacs shows as Dos file; But not picked up by file; maybe other such Missing BIN pattern from .hgeol *.pdf Note that Doc/library/turtle-star.pdf exists This is most likely a bug Existent file-types with non-existent files in hgeol; Probably harmless *.vsprops *.mk *.dsp *.dsw These seem straightforward CRLF files to me; why BIN in hgeol? Lib/test/test_email/data/msg_26.txt Lib/test/coding20731.py Regards, Rusi ___ 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] Importance of "async" keyword
Hi everybody, recently, I stumbled over the new 3.5 release and in doing so over PEP 0492. After careful consideration and after reading many blog posts of various coders, I first would like to thank Yury Selivanov and everybody else who brought PEP 0492 to its final state. I therefore considered usage within our projects, however, still find hazy items in PEP 0492. So, I would like to contribute my thoughts on this in order to either increase my understanding or even improve Python's async capability. In order to do this, I need a clarification regarding the rationale behind the async keyword. The PEP rationalizes its introduction with: "If useful() [...] would become a regular python function, [...] important() would be broken." What bothers me is, why should important() be broken in that case? Regards, Sven R. Kunze ___ 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] Importance of "async" keyword
Hi Sven, On 2015-06-24 2:14 PM, Sven R. Kunze wrote: Hi everybody, recently, I stumbled over the new 3.5 release and in doing so over PEP 0492. After careful consideration and after reading many blog posts of various coders, I first would like to thank Yury Selivanov and everybody else who brought PEP 0492 to its final state. I therefore considered usage within our projects, however, still find hazy items in PEP 0492. So, I would like to contribute my thoughts on this in order to either increase my understanding or even improve Python's async capability. In order to do this, I need a clarification regarding the rationale behind the async keyword. The PEP rationalizes its introduction with: "If useful() [...] would become a regular python function, [...] important() would be broken." What bothers me is, why should important() be broken in that case? Let me first quote the PEP to make the question more obvious. The section at question is: [1]; it explains why "async" keyword is needed for function declarations. Here's a code example from the PEP: def useful(): ... await log(...) ... def important(): await useful() Sven, if we don't have 'async def', and instead say that "a function is a *coroutine function* when it has at least one 'await' expression", then when you refactor "useful()" by removing the "await" from it, it stops being a *coroutine function*, which means that it won't return an *awaitable* anymore. Hence the "await useful()" call in the "important()" function will be broken. 'async def' guarantees that function always return a "coroutine"; it eliminates the need of using @asyncio.coroutine decorator (or similar), which besides making code easier to read, also improves the performance. Not to mention new 'async for' and 'async with' statements. This is also covered in the rationale section of the PEP [2] [1] https://www.python.org/dev/peps/pep-0492/#importance-of-async-keyword [2] https://www.python.org/dev/peps/pep-0492/#rationale-and-goals Thanks, Yury P.S. This and many other things were discussed at length on the mailing lists, I suggest you to browse through the archives. ___ 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] speed.python.org (was: 2.7 is here until 2020, please don't call it a waste.)
> On Jun 22, 2015, at 6:58 PM, Zachary Ware > wrote: > > On Thu, Jun 4, 2015 at 10:51 AM, Maciej Fijalkowski wrote: >> On Thu, Jun 4, 2015 at 4:32 PM, R. David Murray >> wrote: >>> OK, so what you are saying is that speed.python.org will run a buildbot >>> slave so that when a change is committed to cPython, a speed run will be >>> triggered? Is "the runner" a normal buildbot slave, or something >>> custom? In the normal case the master controls what the slave >>> runs...but regardless, you'll need to let us know how the slave >>> invocation needs to be configured on the master. >> >> Ideally nightly (benchmarks take a while). The setup for pypy looks like >> this: >> >> >> https://bitbucket.org/pypy/buildbot/src/5fa1f1a4990f842dfbee416c4c2e2f6f75d451c4/bot2/pypybuildbot/builds.py?at=default#cl-734 >> >> so fairly easy. This already generates a json file that you can plot. >> We can setup an upload automatically too. > > I've been looking at what it will take to set up the buildmaster for > this, and it looks like it's just a matter of checking out the > benchmarks, building Python, testing it, and running the benchmarks. > There is the question of which benchmark repo to use: > https://bitbucket.org/pypy/benchmarks or > https://hg.python.org/benchmarks; ideally, we should use > hg.python.org/benchmarks for CPython benchmarks, but it looks like > pypy/benchmarks has the necessary runner, so I suppose we'll be using > it for now. Is there interest from both sides to merge those > repositories? PyPy’s is a more extensive suite but it does not fully support Python 3 yet. It makes sense to merge them. -- Philip Jenvey ___ 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] Importance of "async" keyword
Thanks, Yury, for you quick response. On 24.06.2015 22:16, Yury Selivanov wrote: Sven, if we don't have 'async def', and instead say that "a function is a *coroutine function* when it has at least one 'await' expression", then when you refactor "useful()" by removing the "await" from it, it stops being a *coroutine function*, which means that it won't return an *awaitable* anymore. Hence the "await useful()" call in the "important()" function will be broken. I feared you would say that. Your reasoning assumes that *await* needs an *explicitly declared awaitable*. Let us assume for a moment, we had no async keyword. So, any awaitable needs to have at least 1 await in it. Why can we not have awaitables with 0 awaits in them? 'async def' guarantees that function always return a "coroutine"; it eliminates the need of using @asyncio.coroutine decorator (or similar), which besides making code easier to read, also improves the performance. Not to mention new 'async for' and 'async with' statements. Recently, I read Guido's blog about the history of Python and how he eliminated special cases from Python step by step. As I see it, the same could be done here. What is the difference of a function (no awaits) or an awaitable (> 1 awaits) from an end-user's perspective (i.e. the programmer)? My answer would be: none. When used the same way, they should behave in the same manner. As long as, we get our nice tracebacks when something went wrong, everything seems find to me. Please, correct me if I am wrong. This is also covered in the rationale section of the PEP [2] [1] https://www.python.org/dev/peps/pep-0492/#importance-of-async-keyword [2] https://www.python.org/dev/peps/pep-0492/#rationale-and-goals Thanks, Yury P.S. This and many other things were discussed at length on the mailing lists, I suggest you to browse through the archives. I can imagine that. As said I went through of some of them, but it could be that I missed some of them as well. Is there a way to search them through (by not using Google)? Regard, Sven ___ 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] CRLF problems in repo
Rustom Mody writes: > Can submit a bug-report if it looks ok Thanks for the post. IMO this should have gone directly to the tracker because (1) you have some support for the idea that at least some of these are unintentional, and therefore candidates for alignment with the rest of the code, (2) the nature of the issue is that it's a mixed bag that is going to need to be addressed line by line, and the tracker is much better at doing that (you can piece each file out to a separate issue, and have a "master issue" that blocks on each individual issue), and (3) these are "easy bugs", so that new contributors (eg, your students) could do the actual patches while discussion of the need is ongoing. YMMV, of course, but (2) and (3) are generic criteria for deciding whether to post or to use the tracker, so I decided to mention them. ___ 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] Importance of "async" keyword
On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote: > Thanks, Yury, for you quick response. > > On 24.06.2015 22:16, Yury Selivanov wrote: > >Sven, if we don't have 'async def', and instead say that "a function > >is a *coroutine function* when it has at least one 'await' > >expression", then when you refactor "useful()" by removing the "await" > >from it, it stops being a *coroutine function*, which means that it > >won't return an *awaitable* anymore. Hence the "await useful()" call > >in the "important()" function will be broken. > > I feared you would say that. Your reasoning assumes that *await* needs > an *explicitly declared awaitable*. > > Let us assume for a moment, we had no async keyword. So, any awaitable > needs to have at least 1 await in it. Why can we not have awaitables > with 0 awaits in them? I haven't been following the async discussion in detail, but I would expect that the answer is for the same reason that you cannot have a generator function with 0 yields in it. > >'async def' guarantees that function always return a "coroutine"; it > >eliminates the need of using @asyncio.coroutine decorator (or > >similar), which besides making code easier to read, also improves the > >performance. Not to mention new 'async for' and 'async with' statements. > > Recently, I read Guido's blog about the history of Python and how he > eliminated special cases from Python step by step. As I see it, the same > could be done here. > > What is the difference of a function (no awaits) or an awaitable (> 1 > awaits) from an end-user's perspective (i.e. the programmer)? The first is syncronous, the second is asyncronous. > My answer would be: none. When used the same way, they should behave in > the same manner. As long as, we get our nice tracebacks when something > went wrong, everything seems find to me. How is that possible? def func(): # Simulate a time consuming calculation. time.sleep(1) return 42 # Call func syncronously, blocking until the calculation is done: x = func() # Call func asyncronously, without blocking: y = func() I think that one of us is missing something here. As I said, I haven't followed the whole discussion, so it might be me. But on face value, I don't think what you say is reasonable. > >P.S. This and many other things were discussed at length on the > >mailing lists, I suggest you to browse through the archives. > > I can imagine that. As said I went through of some of them, but it could > be that I missed some of them as well. > > Is there a way to search them through (by not using Google)? You can download the mailing list archive for the relevant months, and use your mail client to search them. -- Steve ___ 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] Adding c-api async protocol support
A type slot for tp_as_async has already been added (which is good!) but we do not currently seem to have protocol functions for awaitable types. I would expect to find an Awaitable Protocol listed under Abstract Objects Layer, with functions like PyAwait_Check, PyAwaitIter_Check, and PyAwaitIter_Next, etc. Specifically its currently difficult to test whether an object is awaitable or an awaitable iterable, or use said objects from the c-api without relying on method testing/calling mechanisms. ___ 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] CRLF problems in repo
On Thu, Jun 25, 2015 at 6:45 AM, Stephen J. Turnbull wrote: > > Rustom Mody writes: > > > Can submit a bug-report if it looks ok > > Thanks for the post. IMO this should have gone directly to the > tracker Done http://bugs.python.org/issue24507#msg245793 > because (1) you have some support for the idea that at least > some of these are unintentional, and therefore candidates for > alignment with the rest of the code, (2) the nature of the issue is > that it's a mixed bag that is going to need to be addressed line by > line, and the tracker is much better at doing that (you can piece each > file out to a separate issue, and have a "master issue" that blocks on > each individual issue), I guess you meant generic-you here? > and (3) these are "easy bugs", so that new > contributors (eg, your students) could do the actual patches while > discussion of the need is ongoing. I thought of that but if this meant a rather obese patch with really minor real-contents I assumed this would be premature [for me :-) ] > > YMMV, of course, but (2) and (3) are generic criteria for deciding > whether to post or to use the tracker, so I decided to mention them. Thanks for explaining Regards Rusi ___ 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] Adding c-api async protocol support
Arc Riley schrieb am 25.06.2015 um 04:36: > A type slot for tp_as_async has already been added (which is good!) but we > do not currently seem to have protocol functions for awaitable types. > > I would expect to find an Awaitable Protocol listed under Abstract Objects > Layer, with functions like PyAwait_Check, PyAwaitIter_Check, and > PyAwaitIter_Next, etc. > > Specifically its currently difficult to test whether an object is awaitable > or an awaitable iterable, or use said objects from the c-api without > relying on method testing/calling mechanisms. FYI, Cython's latest master branch already implements PEP 492 (in Python 2.6+, using slots in Py3.2+). So you can just write "await x" and "async for ..." and get the expected slot calling code for it, or method calling fallback code in Python 2.x. That being said, I guess you're right that CPython would eventually want to extend the C-API here in order to cover the new protocols also for manually written C code. I'd wait with that a bit, though, until after Py3.5 is finally released and the actual needs for C code that want to use the new features become clearer. Stefan ___ 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] Backporting the 3.5+ Windows build project files to 2.7
On Jun 23, 2015, at 06:27, Christian Tismer wrote: > On 23.06.15 06:42, Zachary Ware wrote: >> Christian, what say you? Would having the project files from 3.5 >> backported to 2.7 (but still using MSVC 9) be positive, negative, or >> indifferent for Stackless? > > I am very positive about your efforts. > > We wanted to create a Stackless 2.8 version end of 2013 > with support for newer compilers, to begin with. After a while, > we stopped this, and I left the branch in a private, unmaintained > repository. > https://bitbucket.org/stackless-dev/stackless-private/branch/2.8-slp Thanks, Chris! Since there has been no violent opposition (and some positive support), I’ve cleaned up the patch and posted it: https://bugs.python.org/issue24508 Reviews (and review-by-testing) welcome! -- Zach ___ 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
