I'm currently working on http://bugs.python.org/issue25458 .
There are a few options there, and each one has drawbacks.
So, I'd like to get some feedback on which way is prefereable before
working towards any of them and/or other ideas should they arise.
The problem and the options are summarized in
http://bugs.python.org/issue25458#msg283073 and the message after that one.
Apart from the options, I'd like to know if I must solve the 2nd problem
(error handling), too, or it can be handled in a separate ticket.
So today I tried to install pywin32 on my new Python 3.6.0 and got the
Python version 3.6-32 required, which was not found in the registry.
Seems like pywin32, although built for 3.6, doesn't understand or
conform to the PEP 514? So the installer doesn't work? I suspect maybe
the code would still work, if it would install. I also noted that pip
cannot find a compatible pywin32, and PyPI only reports compatibility
through Python 3.3.
1. Where should this be reported? SourceForge?
2. Anyone know a workaround?
Experience is that marvelous thing that enables you to recognize a
mistake when you make it again. -- Franklin Jones
I didn't see an announcement that 3.6.0 had actually been released, but
I have been longing for the ability to actually write UTF-8 strings to
the console without using "ascii" or "json.dumps" to avoid the cp437
codec, and be able to write characters from other the whole Unicode
repertoire. I was sitting here wishing I could better read some such
The schedule was 23 December 2016. I decided to see if it had been released.
It seems to be there on Python.org!
I installed it today, which is, as far as I am concerned, still
Christmas until I go to bed, which will be soon, and it is really still
Christmas in Hawaii as I type this. So Merry Christmas to me, and to
Python users everywhere.
And I changed one of my many programs that want to print UTF-8 to the
console, and it worked. I am happy.
Many, many thanks to Steve Dower, who actually pushed the PEPs into the
release, as well as all the other people that have been involved in
incremental reports, workarounds, and ideas throughout the course of
And congratulations to everyone on a successful release.
Three months ago we discussed about an issue with PySlice_GetIndicesEx().
The problem was that PySlice_GetIndicesEx() takes the size of the
sequence, but the size of the sequence can be changed when call custom
__index__() methods inside PySlice_GetIndicesEx().
The solution is to split PySlice_GetIndicesEx() into two functions: one
function convert Python objects to C integers by calling __index__()
methods, other function takes the size of the sequence and adjusts
indices, it is atomic from Python view.
if (PySlice_GetIndicesEx(item, length,
&start, &stop, &step, &slicelength) < 0)
should be replaced with
if (foo(item, &start, &stop, &step) < 0)
slicelength = bar(&start, &stop, step, length);
PySlice_GetIndicesEx() can be converted to a macro calling these two
functions. It would be enough just recompile an extension to make it
invulnerable to the original bug.
But there is a problem. New functions should be added to stable ABI.
This means that we should design names and signatures of these functions
even if don't make them a part of public API.
Let's start bikeshedding. What are your ideas about names and the order
of arguments of two following functions?
1. Takes a slice object, returns it's start, stop and step as Py_ssize_t
values. Can fail.
2. Takes slice's start, stop, step, and the length of the sequence (all
are Py_ssize_t), returns adjusted start, stop, and the length of sliced
subsequence (as Py_ssize_t). Always success.
Please see below issue. Please reply on bug
[ Issue ]
I have used xml rpc library with transport as http. My client and server
are running on same host.
Some xml rpc requests fail with connection reset by peer error number. I
have used xmlrpclib.ServerProxy() to call remote method on xml rpc server
running on an ephemeral port.
This issue has happen many times.
File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
File "/usr/lib64/python2.6/xmlrpclib.py", line 1237, in request
errcode, errmsg, headers = h.getreply()
File "/usr/lib64/python2.6/httplib.py", line 1064, in getreply
response = self._conn.getresponse()
File "/usr/lib64/python2.6/httplib.py", line 990, in getresponse
File "/usr/lib64/python2.6/httplib.py", line 391, in begin
version, status, reason = self._read_status()
File "/usr/lib64/python2.6/httplib.py", line 349, in _read_status
line = self.fp.readline()
File "/usr/lib64/python2.6/socket.py", line 433, in readline
data = recv(1)
error: [Errno 104] Connection reset by peer
[ Test Environment ]
RHEL 6 with linux kernel 2.6.32-504.16.2.el6.
[ Possible Reasons for it ]
1) The machine is connected to the network, and the network is not
2) The other side of the connection is not running normally.
3) There are not enough system resources available. Free up system
resources if they are running low.
Possibility for 1 and 2 are not applicable as it is loop back
communication(Client and Server running on same machine).
For Possibility 3, I have already checked system resource and there are
enough resources(80% RAM used, 20% cpu usage, around 10 GB RAM free).
I checked for other reasons and i found that this issue may be related with
Please refer this link,
1> Can you please let me know, is it really a issue realted with GIL?
2> If yes, How to resolve this issue?
3> If no, what other reason may exists for such failure. [Note: Those rpc
requests fail which return python's dictionary data to client]
Er. Manish Singh
Engineer at NEC Technologies India Limited
Computer Science & Engineering
M.Tech ( MNNIT CS Allahabad )
B. Tech ( Calcutta Institute Of Engg. & Mgmt., Kolkata )
< email : manish.ciem(a)gmail.com >
< contact no. - 9899886538, 9651540577 >
On behalf of the Python development community and the Python 3.6 release
team, I am pleased to announce the availability of Python 3.6.0. Python
3.6.0 is the newest major release of the Python language, and it contains
many new features and optimizations. See the "What’s New In Python 3.6"
document for more information:
You can download Python 3.6.0 here:
Also, most third-party distributors of Python should be making 3.6.0
packages available soon.
Maintenance releases for the 3.6 series will follow at regular intervals
starting in the first quarter of 2017.
We hope you enjoy Python 3.6.0!
P.S. As a volunteer-staffed open source project, we could not bring
Python releases to you without the enormous contributions of many,
many people. Thank you to all who have contributed and reviewed code
and documentation changes, documented and investigated bugs, tested
Python and third-party packages, and provided and supported the
infrastructure needed to support Python development and testing.
Please consider supporting the work of the Python Software Foundation.
nad(a)python.org -- 
Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and
3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle"
around the release. I expect a flood of adoption of 3.6, and people
switching will find bugs, and maybe those bugs are in 3.5 or 3.4. So it
just seemed sensible.
3.6 just slipped by two weeks. So now there's less than two weeks
between 3.6.0 final shipping and tagging the release canddiates for
3.5.3 and 3.4.6. This isn't as much time as I'd like.
If I had total freedom to do as I liked, I'd slip my releases by two
weeks to match 3.6. But there might be people planning around 3.5.3 and
3.4.6--like Guido was waiting for 3.5.3 for something iirc.
So, if you have an opinion, please vote for one of these three options:
* Don't slip 3.5.3. and 3.4.6.
* Slip 3.5.3 and 3.4.6 by two weeks to match 3.6.0.
* Slip 3.5.3 and 3.4.6 by a whole month, to give 3.6.0 the ability to
slip again without us having to change the release.
Your faithful servant,
For those who aren't aware, the stable API (PEP 384) is broken on
Windows because the exports from python3.dll have not been kept up to date.
Over at http://bugs.python.org/issue23903 we're trying to address this
by automatically generating the DLL based on the headers. This has shown
that many more functions and data items are in the stable ABI than expected.
If it's left entirely to me, I'm planning to add all the public APIs
into python3.dll, which will commit them to the stable API for good, and
remove the _private APIs that have been added since we last updated the DLL.
However, if you've added an API recently that you didn't mean to be in
the stable API, here is your chance to remove it. The full list of APIs
that have never been available on Windows in the stable ABI but are in
the headers are below. If it should not be considered long-term stable,
then it needs "#ifndef Py_LIMITED_API" around it.
Note that anything NOT on this list has already been released, and so it
cannot be removed from the stable API at this time. I want to resolve
this for 3.5.3 (that is, release all of these as stable and then it
cannot be undone), which is coming up very soon, so if any of the public
APIs should NOT be stable, please fix them, and if any of the private
APIs SHOULD be stable, they'll probably need version-specific guards
Full list of APIs to be added to python3.dll: