(I prefer to start a new thread, the previous one is too long for me :-))
I'm still trying to understand how the PEP 3152 would impact asyncio.
Guido suggests to replace "yield from fut" with "cocall fut()" (add
parenthesis) and so add a __cocall__() method to asyncio.Future.
Problem: PEP 3152 says "A cofunction (...) does not contain any yield
or yield from expressions". Currently, Future.__iter__() is
implemented using yield:
if not self.done():
self._blocking = True
yield self # This tells Task to wait for completion.
assert self.done(), "yield from wasn't used with future"
return self.result() # May raise too.
>From my understanding, the PEP 3151 simply does not support
asyncio.Future. Am I right?
How is it possible to suspend a cofunction if it's not possible to use yield?
If waiting for a future in a cofunction is not supported, the PEP 3151
is useless for asyncio, since asyncio completly relies on futures.
My name is Leonid. I'm very interested in Python programming language.
I'm sending this letter to the python-dev mailing list in order to get
any task, that I could perform.
I want to help my community and improve my skills.
If anybody has not very complicated task, please email me at
It's not the first time someone is confused by the server example of
where the receiving side is not making a loop over recv.
Moreover the documentation contains a misleading description of what really
"The difference is that the readline() call in the second handler will call
recv() multiple times until it encounters a newline character, while the
single recv() call in the first handler will just return what has been sent
from the client in one sendall() call."
Unless I'm missing something there's no way to know client side when all
data sent by "sendall" has been received (TCP stream protocol doesn't have
message boundaries) and the `recv` based code doesn't handle neither
fragmentation nor clients that send more than 1024 bytes.
Am I missing something or that is indeed an example of how NOT to write a
I just commited a simple improvement to HTTPError repr, and checking
in the source code page , I see that my commit has a small
"default" besides it; and other commits don't have that, but have 2.7,
or 3.4, etc...
So, question: Did I commit in the correct branch? Should I have done
On behalf of the Python development community and the Python 3.5 release
team, I'm thrilled to announce the availability of Python 3.5.0a4.
Python 3.5.0a4 is the fourth and alpha release of Python 3.5, which will
be the next major release of Python. Python 3.5 is still under
development, and is not yet complete.
This is a preview release, and its use is not recommended for production
The next release of Python 3.5 will be 3.5.0b1, the first beta release.
Python 3.5 will enter "feature freeze" at this time; no new features
will be added to 3.5 after this point. Python 3.5.0b1 is scheduled to
be released May 22, 2015.
Three important notes for Windows users about Python 3.5.0a4:
* If you have previously installed Python 3.5.0a1, you may need to
manually uninstall it before installing Python 3.5.0a4 (issue23612).
* If installing Python 3.5.0a4 as a non-privileged user, you may need
to escalate to administrator privileges to install an update to your
C runtime libraries.
* There is now a third type of Windows installer for Python 3.5. In
addition to the conventional installer and the web-based installer,
Python 3.5 now has an embeddable installer designed to be run as
part of a larger application's installer for apps using or extending
You can find Python 3.5.0a4 here:
On Wed, Apr 22, 2015 at 11:30 AM, Skip Montanaro <skip.montanaro(a)gmail.com>
> On Wed, Apr 22, 2015 at 11:26 AM, Ian Cordasco <graffatcolmingov(a)gmail.com
> > wrote:
>> On a separate thread Cory provided an example of what the hints would
>> look like for *part* of one function in the requests public functional API.
> Thanks. That encouraged me to look around for recent posts from Cory.
You're welcome! And yeah. That union that Cory posted was for *one*
parameter if I remember correctly. I won't speak for Cory, but I'm not
against the type hints in 484 but they will be difficult for us as a
project. They'll be marginally less difficult for me in a different project
I also wonder about importing type definitions from other packages. The
Requests-Toolbelt adds a few features that are enhanced versions of what's
already in Requests. I can think of a few type hints that we might create
to represent certain parameters, but I don't want to have to copy those for
the features in the Requests-Toolbelt. I would expect this to "Just Work",
but I wonder if anyone else has considered the possibility of this being a
Just thought I'd share this since it shows how what people are using to
download things from PyPI have changed over the past year. Of particular
interest to most people will be the final graphs showing what percentage of
downloads from PyPI are for Python 3.x or 2.x.
As always it's good to keep in mind, "Lies, Damn Lies, and Statistics". I've
tried not to bias the results too much, but some bias is unavoidable. Of
particular note is that a lot of these numbers come from pip, and as of version
6.0 of pip, pip will cache downloads by default. This would mean that older
versions of pip are more likely to "inflate" the downloads than newer versions
since they don't cache by default. In addition if a project has a file which
is used for both 2.x and 3.x and they do a ``pip install`` on the 2.x version
first then it will show up as counted under 2.x but not 3.x due to caching (and
of course the inverse is true, if they install on 3.x first it won't show up
Here's the link: https://caremad.io/2015/04/a-year-of-pypi-downloads/
Anyways, I'll have access to the data set for another day or two before I
shut down the (expensive) server that I have to use to crunch the numbers so if
there's anything anyone else wants to see before I shut it down, speak up soon.
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
I am sitting net to Christie Wilson (bobcatfish) who is trying to register
a user account for our issue tracker. However it doesn't seem to work --
the promised email never arrives. Who can help with this?
--Guido van Rossum (python.org/~guido)