Re: [Python-Dev] PySlice_GetIndicesEx annd stable ABI: bikeshedding
Hi Serhiy, On 21 December 2016 at 15:51, Serhiy Storchaka wrote: > The code > > if (PySlice_GetIndicesEx(item, length, > &start, &stop, &step, &slicelength) < 0) > return -1; > > should be replaced with > > if (foo(item, &start, &stop, &step) < 0) > return -1; > slicelength = bar(&start, &stop, step, length); As far as I can tell, as written, this change would not fix anything. Shouldn't it be along the following lines instead? if (foo(item, &start, &stop, &step) < 0) return -1; length = PyList_GET_SIZE(mylist); /* <= after foo() */ slicelength = bar(&start, &stop, &step, length); A bientôt, Armin. ___ 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] PySlice_GetIndicesEx annd stable ABI: bikeshedding
On 22.12.16 12:16, Armin Rigo wrote: On 21 December 2016 at 15:51, Serhiy Storchaka wrote: The code if (PySlice_GetIndicesEx(item, length, &start, &stop, &step, &slicelength) < 0) return -1; should be replaced with if (foo(item, &start, &stop, &step) < 0) return -1; slicelength = bar(&start, &stop, step, length); As far as I can tell, as written, this change would not fix anything. Shouldn't it be along the following lines instead? if (foo(item, &start, &stop, &step) < 0) return -1; length = PyList_GET_SIZE(mylist); /* <= after foo() */ slicelength = bar(&start, &stop, &step, length); Yes, the point is that length is not a constant, but a result of an expression and should be evaluated after calling foo(). step is not changed by bar() and can be passed by value to it. ___ 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] [python-committers] Should I delay 3.5.3 and 3.4.6 by two weeks?
100% of votes cast were for "don't slip", so we won't slip. Retreat! Full steam behind! //arry/ On 12/20/2016 02:25 AM, Matthias Klose wrote: On 19.12.2016 06:26, Larry Hastings wrote: 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. I would appreciate a 3.5.3 release which doesn't slip, or which only slips by a week, to be available before the Debian freeze. Neither Debian nor Ubuntu ship the 3.4 branch anymore, so for 3.4 I'm fine with any solution. Matthias ___ 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] Asking for feedback about fixing `ftplib' (issue25458)
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. -- Regards, Ivan ___ 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] Asking for feedback about fixing `ftplib' (issue25458)
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. -- Regards, Ivan ___ 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] Python related issue
Hi All, Please see below issue. Please reply on bug http://bugs.python.org/issue28968 [ 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. log snippet, File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose 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 response.begin() 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. Python 2.6.6 glibc-2.12-1.149.7 [ Possible Reasons for it ] 1) The machine is connected to the network, and the network is not responsive. 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 GIL, Please refer this link, http://stackoverflow.com/questions/383738/104-connection-reset-by-peer-socket-error-or-when-does-closing-a-socket-resu 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.c...@gmail.com > < contact no. - 9899886538, 9651540577 > ___ 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
