Re: [Python-Dev] "make test" routinely fails to terminate
On Sat, 19 May 2018 17:41:18 -0500 Skip Montanaro wrote: > On the 3.7 branch, "make test" routinely fails to terminate. (Pretty > vanilla Ubuntu 17.10 running on a Dell Laptop. Nothing esoteric at all) > Lately, it's been one of the multiprocessing tests. After a long while > (~2000 seconds), I kill it, then it complains many times about lack of a > valid_signals attribute in the signal module: Can you try to rebuild Python? Use "make distclean" if that helps. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: 576 Title: Rationalize Built-in function classes
On 2018-05-19 11:15, mark wrote: PEP 576 aims to fulfill the same goals as PEP 575 (this is a copy of my comments on GitHub before this PEP was official) **Performance** Most importantly, changing bound methods of extension types from builtin_function_or_method to bound_method will yield a performance loss. It might be possible to mitigate this somewhat by adding specific optimizations for calling bound_method. However, that would add extra complexity and it will probably still be slower than the existing code. And I would also like to know whether it will be possible for custom built-in function subclasses to implement __get__ to change a function into a method (like Python functions) and whether/how the LOAD_METHOD opcode will work in that case. **Introspection** When I want "introspection support", that goes beyond the call signature. Also inspect.getfile should be supported. Currently, that simply raises an exception for built-in functions. I think it's important to specify the semantics of inspect.isfunction. Given that you don't mention it, I assume that inspect.isfunction will continue to return True only for Python functions. But that way, these new function classes won't behave like Python functions. fully backwards compatible. I wonder why you think it is "fully backwards compatible". Just like PEP 575, you are changing the classes of certain objects. I think it's fairer to say that both PEP 575 and PEP 576 might cause minor backwards compatibility issues. I certainly don't think that PEP 576 is significantly more backwards compatible than PEP 575. PS: in your PEP, you write "bound_method" but I guess you mean "method". PEP 575 proposes to rename "method" to "bound_method". Jeroen. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
On 2018-05-19 15:29, Nick Coghlan wrote: That's not how code reviews work, as their complexity is governed by the number of lines changed (added/removed/modified), not just the number of lines that are left at the end. Of course, you are right. I didn't mean literally that only the end result matters. But it should certainly be considered. If you only do small incremental changes, complexity tends to build up because choices which are locally optimal are not always globally optimal. Sometimes you need to do some refactoring to revisit some of that complexity. This is part of what PEP 575 does. That said, "deletes more lines than it adds" is typically a point strongly in favour of a particular change. This certainly won't be true for my patch, because there is a lot of code that I need to support for backwards compatibility (all the old code for method_descriptor in particular). Going back to the review of PEP 575, I see the following possible outcomes: (A) Accept it as is (possibly with minor changes). (B) Accept the general idea but split the details up in several PEPs which can still be discussed individually. (C) Accept a minimal variant of PEP 575, only changing existing classes but not changing the class hierarchy. (D) Accept some yet-to-be-written variant of PEP 575. (E) Don't fix the use case that PEP 575 wants to address. Petr Viktorin suggests (C). I am personally quite hesitant because that only adds complexity and it wouldn't be the best choice for the future maintainability of CPython. I also fear that this hypothetical PEP variant would be rejected because of that reason. Of course, if there is some general agreement that (C) is the way to go, then that is fine for me. If people feel that PEP 575 is currently too complex, I think that (B) is a very good compromise. The end result would be the same as what PEP 575 proposes. Instead of changing many things at once, we could handle each class in a separate PEP. But the motivation of those mini-PEPs will still be PEP 575. So, in order for this to make sense, the general idea of PEP 575 needs to be accepted: adding a base_function base class and making various existing classes subclasses of that. Jeroen. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 3.7.0rc1 deadline extended two days to 2018-05-23 AOE [Re: FINAL WEEK FOR 3.7.0 CHANGES!]
We are going to extend for 48 hours the deadline for 3.7.0rc1, that is, until 2018-05-23 23:59 AOE. While we have made tremendous progress towards the release candidate over the past week especially with the huge efforts at the PyCon US Sprints, we still have some important issues to resolve. A stumbling block has been the increased instability in the test suite, primarily in test_asyncio, which has caused delays in merging PRs due to intermittent failures in CI test runs and which has caused widespread buildbot failures. Another factor is that this weekend and Monday are public holidays in many countries, something I did not take into account when drawing up the schedule. (Note that next weekend is a major public holiday in the USA.) So let's plan on using the extra two days to work through the remaining release blockers. Thanks again! --Ned On May 15, 2018, at 07:51, Ned Deily wrote: > This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your > feature fixes, bug fixes, and documentation updates in before > 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days > from now. We will then tag and produce the 3.7.0 release candidate. > Our goal continues been to be to have no changes between the release > candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 > BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are > no critical problems outstanding and that documentation for new > features in 3.7 is complete (including NEWS and What's New items), and > that 3.7 is getting exposure and tested with our various platorms and > third-party distributions and applications. Those of us who are > participating in the development sprints at PyCon US 2018 here in > Cleveland can feel the excitement building as we work through the > remaining issues, including completing the "What's New in 3.7" > document and final feature documentation. (We wish you could all be > here.) > > As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You > should now be treating the 3.7 branch as if it were already released > and in maintenance mode. That means you should only push the kinds of > changes that are appropriate for a maintenance release: > non-ABI-changing bug and feature fixes and documentation updates. If > you find a problem that requires an ABI-altering or other significant > user-facing change (for example, something likely to introduce an > incompatibility with existing users' code or require rebuilding of > user extension modules), please make sure to set the b.p.o issue to > "release blocker" priority and describe there why you feel the change > is necessary. If you are reviewing PRs for 3.7 (and please do!), be on > the lookout for and flag potential incompatibilities (we've all made > them). > > Thanks again for all of your hard work towards making 3.7.0 yet > another great release - coming to a website near you on 06-15! > > Release Managerly Yours, > --Ned > > https://www.python.org/dev/peps/pep-0537/ -- Ned Deily [email protected] -- [] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
