On Wed, 28 Aug 2013 20:05:25 -0400
Terry Reedy <tjreedy(a)udel.edu> wrote:
> On 8/28/2013 5:51 PM, antoine.pitrou wrote:
> > +Does the test suite still pass?
> There are several assumptions packed in that question.
> 0. The test suite is relevant to the patch.
> Not true for doc patches, some idlelib patches, and probably some others.
That was implicit in the formulation: "You must :ref:`run the whole
test suite <runtests>` to ensure that it passes before pushing any
*code changes*" (not doc changes, spelling corrections, etc.).
The only reason to know that the test suite isn't relevant to a code
change is to... *run the test suite*. Don't assume that you are
omniscient and know that your change won't break something. Developers
not being omniscient is why we have a test suite in the first place.
(btw, if idlelib isn't tested, it should!)
> 1. The test suite runs to completion.
> For at least a couple of years, that was not true on Windows desktops.
> The popup Runtime Error boxes from now are now gone, but a month ago, a
> crashing test froze Command Prompt.
But was the test corrected? Did you open an issue at the time?
Did you try to debug the error?
We are collectively responsible for Python's quality. This is not
some third-party software you have no control on.
> 2. The test suite runs without error.
> I have hardly ever seen this on Windows, ever (with sporadic runs over
> several years). Today, test_email and test_sax failed in successive
> 3. If there is a new failure, it is due to the patch.
> There have been at least one, but I think more, intermittent failures of
> Windows tests in the last few months
Same answer as above.
> 4. The gain of answering that question is worth the cost.
Accepting responsibility for one's own changes is part of why we trust
each others as committers. The cost of *you* running the test suite is
smaller than the cost of other developers trying to investigate a
sudden buildbot failure, where it comes from etc.
Having you run the test suite encourages you to be conscious of its
existence, of its imperfections, and to feel responsible in making it
better. Shrugging it off because it sometimes doesn't work isn't
helpful. We are *striving* to make it better (both in coverage and in
> I worry that further emphasizing an overly broad, time-consuming, and
> sometimes impractical rule will only discourage more participation.
IMO, this is a calculated risk that is worthwhile to take. Times have
changed, and being rigorous with testing is central in most successful
I just noticed that tests using @requires_freebsd_version and
@requires_linux_version decorator from test.support are never run
since this commit (almost 2 years ago):
user: Charles-François Natali <neologix(a)free.fr>
date: Mon Oct 03 19:40:37 2011 +0200
Introduce support.requires_freebsd_version decorator.
- "Linux kernel %s or higher required, not %s"
- % (min_version_txt, version_txt))
- return func(*args, **kw)
- wrapper.min_version = min_version
+ "%s version %s or higher required, not %s"
+ % (sysname, min_version_txt, version_txt))
I don't want to blame Charles-François, nobody saw the issue during 2 years!
No, my question is: how can we detect that a test is never run? Do we
need test covertage on the test suite? Or inject faults in the code to
test the test suite? Any other idea?
I fixed the decorators in Python 3.3 (84debb4abd50) and 3.4 (f98fd5712b0e).
On Wed, 28 Aug 2013 01:20:56 +0200 (CEST)
victor.stinner <python-checkins(a)python.org> wrote:
> changeset: 85420:ef889c3d5dc6
> user: Victor Stinner <victor.stinner(a)gmail.com>
> date: Wed Aug 28 00:53:59 2013 +0200
> Issue #18571: Implementation of the PEP 446: file descriptors and file handles
> are now created non-inheritable; add functions os.get/set_inheritable(),
> os.get/set_handle_inheritable() and socket.socket.get/set_inheritable().
I don't want to sound too demanding, but was this patch actually
reviewed? I can't find a single review comment in
Congratulations Victor, PEP 446 is accepted!
Thanks for your tiresome work and the last-minute changes. I will update
the PEP's status to "Accepted" right away. You can change it to "Final"
after all the changes have been committed to the default branch for
inclusion into the next 3.4 alpha.
--Guido van Rossum (python.org/~guido)
ticket 17741 has introduced a new feature in the xml.etree.ElementTree
module that was added without any major review.
I only recently learned about this addition and after taking a couple of
closer looks, I found that it represents a rather seriously degradation of
the ET module API. Since I am not a core developer, it is rather easy for
the original committer to close the ticket and to sit and wait for the next
releases to come in order to get the implementation out. So I'm sorry for
having to ask publicly on this list for the code to be removed, before it
does any harm in the wild.
Let me explain why the addition is such a disaster. I'm personally involved
in this because I will eventually have to implement features that occur in
ElementTree also in the external lxml.etree package. And this is not an API
that I can implement with a clear conscience.
There are two parts to parsing in the ET API. The first is the parser, and
the second is the target object (similar to a SAX handler). The parser has
an incremental parsing API consisting of the functions .feed() and
.close(). When it receives data through the .feed() method, it parses it
and passes events on to the target. The target is commonly a TreeBuilder
that builds an in-memory tree, but is not limited to that. Calling the
.close() method tells the parser that the parsing is done and that it
should finish it up.
The class that was now added is called "IncrementalParser". It has two
methods for passing data in: "data_received()" and "eof_received()". So the
first thing to note is that this addition is only a copy of the existing
API and functionality, but under different names. It is hard to understand
for me how anyone could consider this a consistent design.
Then, the purpose of this addition was to provide a way to collect parse
events. That is the obvious role of the target object. In the new
implementation, the target object is being instantiated, but not actually
meant to collect the events. Instead, it's the parser collecting the
events, based on what the target object returns (which it doesn't currently
have to do at all). This is totally backwards. Instead, it should be up to
the target object to decide which events to collect, how to process them
and how to present them to the user. This is clearly how the API was
Also, the IncrementalParser doesn't directly collect the events itself but
gets them through a sort of backdoor in the underlying parser. That parser
object is actually being passed into the IncrementalParser as a parameter,
which means that user provided parser objects will also have to implement
that backdoor now, even though they may not actually be able to provide
My proposal for fixing these obvious design problems is to let each part of
the parsing chain do what it's there for. Use the existing XMLParser (or an
HTMLParser, as in lxml.etree) to feed in data incrementally, and let the
target object process and collect the events. So, instead of replacing the
parser interface with a new one, there should be a dedicated target object
(or maybe just a wrapper for a TreeBuilder) that collects the parse events
in this specific way.
Since the time is running in favour of the already added implementation,
I'm asking to back it out for the time being. I specifically do not want to
rush in a replacement. Once there is an implementation that matches the
established API, I'm all in favour of adding it, because the feature itself
is a good idea. But keeping a wrong design in, just because "it's there",
even before anyone has actually started using it, is just asking for future
deprecation hassle. It's not too late for removal now, but it will be in a
couple of weeks if it is not done now.
I'm trying to checkout a pristine clone from
ssh://firstname.lastname@example.org/cpython, and it's taking forever:
07:45:35.605941 IP 192.168.0.23.43098 >
virt-7yvsjn.psf.osuosl.org.ssh: Flags [.], ack 22081460, win 14225,
options [nop,nop,TS val 368519 ecr 2401783356], length 0
07:45:38.558348 IP virt-7yvsjn.psf.osuosl.org.ssh >
192.168.0.23.43098: Flags [.], seq 22081460:22082908, ack 53985, win
501, options [nop,nop,TS val 2401784064 ecr 368519], length 1448
07:45:38.558404 IP 192.168.0.23.43098 >
virt-7yvsjn.psf.osuosl.org.ssh: Flags [.], ack 22082908, win 14225,
options [nop,nop,TS val 369257 ecr 2401784064], length 0
07:45:39.649995 IP virt-7yvsjn.psf.osuosl.org.ssh >
192.168.0.23.43098: Flags [.], seq 22082908:22084356, ack 53985, win
501, options [nop,nop,TS val 2401784367 ecr 369257], length 1448
See the time to just get an ACK?
Am I the only one experiencing this?
> hg branches
3.3 85274:7ab07f15d78c (inactive)
2.6 82288:936621d33c38 (inactive)
3.1 80967:087ce7bbac9f (inactive)
Is it expected that 3.2 is active? Looks like it's been that way a
couple months. The branch head:
> hg log -r 3.2
user: Antoine Pitrou <solipsis(a)pitrou.net>
date: Sat May 18 17:56:42 2013 +0200
summary: Issue #17980: Fix possible abuse of ssl.match_hostname()
for denial of service using certificates with many wildcards
Besides that one, there are only two other changesets that would be
involved in a merge of 3.2 into default, both having to do with making
the 3.2.5 release.
As I understand the development docs (and I may be wrong), the intent
is that only the default and 2.7 branches should be active at this
time. Educate me :-)