Re: [Python-Dev] Articles on my contributions to CPython during 2017 Q1 and Q2
Hi Victor, On 07/13/2017 05:33 PM, Victor Stinner wrote: > Hi, > > I wrote a serie of new articles on my contributions to CPython during > 2017 Q1 and Q2. > > "My contributions to CPython during 2017 Q1" > https://haypo.github.io/contrib-cpython-2017q1.html > > "New Python test.bisect tool" > https://haypo.github.io/python-test-bisect.html would it make sense too add a test that passes if the tool doesn't find anything ? if it fails so should the reason be already there (?) (Or to add a test step after running the test suite if some error happened (?)) Thanks ! -- francis ___ 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] Articles on my contributions to CPython during 2017 Q1 and Q2
I'm not sure that I understood your suggestion. Basically, if a test file fails, you would like to automatically re-run the failing test with test.bisect to identify the failing *methods*? Yeah, it's doable, but I didn't write it :-) It's very easy to run bisect: just replace "-m test" with "-m test.bisect" in your command line, and you are done. Victor 2017-07-16 17:30 GMT+02:00 francismb : > Hi Victor, > > On 07/13/2017 05:33 PM, Victor Stinner wrote: >> Hi, >> >> I wrote a serie of new articles on my contributions to CPython during >> 2017 Q1 and Q2. >> >> "My contributions to CPython during 2017 Q1" >> https://haypo.github.io/contrib-cpython-2017q1.html >> >> "New Python test.bisect tool" >> https://haypo.github.io/python-test-bisect.html > would it make sense too add a test that passes if the tool doesn't find > anything ? if it fails so should the reason be already there (?) > (Or to add a test step after running the test suite if some error > happened (?)) > > Thanks ! > -- francis > ___ > 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/victor.stinner%40gmail.com ___ 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] deque implementation question
I found the answer in _collectionsmodule.c /* Data for deque objects is stored in a doubly-linked list of fixed * length blocks. This assures that appends or pops never move any * other data elements besides the one being appended or popped. * * Another advantage is that it completely avoids use of realloc(), * resulting in more predictable performance. Regards, INADA Naoki On Sat, Jul 15, 2017 at 4:01 PM, Max Moroz wrote: > What would be the disadvantage of implementing collections.deque as a > circular array (rather than a doubly linked list of blocks)? My naive > thinking was that a circular array would maintain the current O(1) > append/pop from either side, and would improve index lookup in the middle > from O(n) to O(1). What am I missing? > > The insertion/removal of an arbitrary item specified by a pointer would > increase from constant time to linear, but since we don't have pointers this > is a moot point. > > Of course when the circular array is full, it will need to be reallocated, > but the amortized cost of that is still O(1). (Moreover, for a bounded > deque, there's even an option of preallocation, which would completely > eliminate reallocations.) > > Thanks > > Max > > ___ > 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/songofacandy%40gmail.com > ___ 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] Python 3.3.7 release schedule and end-of-life
A quick thanks from me, Ned, for stepping forward to help 3.3 pine for the fjords. On Sat, Jul 15, 2017, 14:51 Ned Deily, wrote: > Python 3.3 is fast approaching its end-of-life date, 2017-09-29. Per our > release policy, that date is five years after the initial release of 3.3, > 3.3.0 final on 2012-09-29. Note that 3.3 has been in security-fix only > mode since the 2014-03-08 release of 3.3.5. It has been a while since we > produced a 3.3.x security-fix release and, due to his commitments > elsewhere, Georg has agreed for me to lead 3.3 to its well-deserved > retirement. > > To that end, I would like to schedule its next, and hopefully final, > security-fix release to coincide with the already announced 3.4.7 > security-fix release. In particular, we'll plan to tag and release 3.3.7rc1 > on Monday 2017-07-24 (UTC) and tag and release 3.3.7 final on Monday > 2017-08-07. In the coming days, I'll be reviewing the outstanding 3.3 > security issues and merging appropriate 3.3 PRs. Some of them have been > sitting as patches for a long time so, if you have any such security issues > that you think belong in 3.3, it would be very helpful if you would review > such patches and turn them into 3.3 PRs. > > As a reminder, here are the guidelines from the devguide as to what is > appropriate for a security-fix only branch: > > "The only changes made to a security branch are those fixing issues > exploitable by attackers such as crashes, privilege escalation and, > optionally, other issues such as denial of service attacks. Any other > changes are not considered a security risk and thus not backported to a > security branch. You should also consider fixing hard-failing tests in open > security branches since it is important to be able to run the tests > successfully before releasing." > > Note that documentation changes, other than any that might be related to a > security fix, are also out of scope. > > Assuming no new security issues arise prior to the EOL date, 3.3.7 will > likely be the final release of 3.3. And you really shouldn't be using 3.3 > at all at this point; while downstream distributors are, of course, free to > provide support of 3.3 to their customers, in a little over two months when > EOL is reached python-dev will no longer accept any issues or make any > changes available for 3.3. If you are still using 3.3, you really owe it > to your applications, to your users, and to yourself to upgrade to a more > recent release of Python 3, preferably 3.6! Many, many fixes, new > features, and substantial performance improvements await you. > > https://www.python.org/dev/peps/pep-0398/ > https://devguide.python.org/devcycle/#security-branches > > -- > Ned Deily > n...@python.org -- [] > > ___ > python-committers mailing list > python-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ 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] deque implementation question
[Max Moroz ] > What would be the disadvantage of implementing collections.deque as a > circular array (rather than a doubly linked list of blocks)? ... You answered it yourself ;-) > ... > Of course when the circular array is full, it will need to be reallocated, > but the amortized cost of that is still O(1). Bingo. The primary point of a deque is to make popping and pushing at both ends efficient. That's what the current implementation does: worst-case constant time per push or pop regardless of how many items are in the deque. That beats "amortized O(1)" in the small and in the large. That's why it was done this way. Some other deque methods are consequently slower than they are for lists, but who cares? For example, the only indices I've ever used with a deque are 0 and -1 (to peek at one end or the other of a deque), and the implementation makes accessing those specific indices constant-time too. ___ 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] curses: error handling and the lower right margin of the screen
Hello everyone, My name is Aleksejs, and this is my first time posting here. I'm working on a Python project (a client for Zephyr, MIT's instant messaging system) that uses curses, and I believe I've found either a bug in the Python curses bindings or a deficiency in their documentation. The problem has to do with ncurses' cursor advancing behavior. The manpage addch(3x) says: If the advance is at the right margin: · The cursor automatically wraps to the beginning of the next line. · At the bottom of the current scrolling region, and if scrollok is enabled, the scrolling region is scrolled up one line. · If scrollok is not enabled, writing a character at the lower right margin succeeds. However, an error is returned because it is not possible to wrap to a new line Python's window.addch(y, x, ch[, attr]) function seems to be internally calling addch or one of the related functions, and so, if scrollok is off and (y, x) is the lower right corner of the screen, addch returns an error, which window.addch then detects and turns into an exception. I'd like to argue that this is not expected behavior, and does not follow from the documentation. The documentation for window.addch makes no mention of the fact that the cursor is advanced at all, so there's no reason that a user should expect window.addch(height - 1, width - 1, ch) to fail (and the exception raised, "_curses.error: add_wch() returned ERR", is not very helpful in understanding what the deal is). Because the documentation doesn't say anything about the cursor, this is not even an error in any meaningful way, as the character is successfully written to the screen, and wrapping the code in a "try: ... except curses.error: pass" block "fixes" the error. The same problem affects window.addstr() if the end of the string being painted ends up in the lower right corner. This behavior is so unintuitive that it is not even accounted for elsewhere in the curses bindings: the implementation of curses.panel.rectangle contains a line [1] win.addch(lry, lrx, curses.ACS_LRCORNER) which raises an exception when trying to draw a rectangle spanning an entire window (or in fact any rectangle touching the lower right corner). I also wrote a little example script [2] demonstrating the problem. I believe that this is a problem, but I am not sure how it could be resolved. It seems that there's no way to distinguish this "error" from a legitimate ncurses error. Perhaps the documentation ought to at least mention this behavior, and the implementation of curses.panel.rectangle should check for the case where the rectangle touches the lower right corner and use a try-catch block there. Best regards, Aleksejs Popovs [1] https://github.com/python/cpython/blob/3.6/Lib/curses/textpad.py#L16 [2] https://gist.github.com/popoffka/e21299967f5739d18c4fa393fa5cf20b ___ 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] [RELEASE] Python 3.6.2 is now available
On behalf of the Python development community and the Python 3.6 release team, I am happy to announce the availability of Python 3.6.2, the second maintenance release of Python 3.6. 3.6.0 was released on 2016-12-22 to great interest and we are now providing the second set of bugfixes and documentation updates for it; the first maintenance release, 3.6.1, was released on 2017-03-31. Detailed information about the changes made in 3.6.2 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-2 Please see "What’s New In Python 3.6" for more information about the new features in Python 3.6: https://docs.python.org/3.6/whatsnew/3.6.html You can download Python 3.6.2 here: https://www.python.org/downloads/release/python-362/ The next maintenance release of Python 3.6 is expected to follow in about 3 months, around the end of 2017-09. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ Enjoy! P.S. If you need to download the documentation set for 3.6.2 immediately, you can always find the release version here: https://docs.python.org/release/3.6.2/download.html The most current updated versions will appear here: https://docs.python.org/3.6/ -- Ned Deily n...@python.org -- [] ___ 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
