I am using python v.2.7.1 for my research work in software testing. I have
already downloaded the source codes and found the built-in testsuites for
running on the build. However, i was wondering if by any chance are there
any testsuites which exist that are primarily meant for* developers* of the
source code which can be used before releasing a build, for instance smoke
testsuite/regression testsuites, besides the one already distributed with
If such developer testsuite exist i would request to share them.
Thanking in advance for the information.
MS Computer Science and Engineering
In article <20150615003717.2599.82804(a)psf.io>,
senthil.kumaran <python-checkins(a)python.org> wrote:
> changeset: 96605:9a0c5ffe7420
> parent: 96603:47a566d6ee2a
> parent: 96604:3ded282f9615
> user: Senthil Kumaran <senthil(a)uthcode.com>
> date: Sun Jun 14 17:37:09 2015 -0700
> null merge with 3.4
> Back porting changeset db302b88fdb6 to 3.4 branch, which fixed multiple
> documentation typos.
> Related Issues:
There is now an active 3.5 branch, so the correct current order of
3.4 -> 3.5
3.5 -> default
I've checked in a couple of null merges to try to fix things.
Apologies in advance; I'm not a regular, and this may have been
handled already (but I couldn't find it when searching).
I've been using the new async/await functionality (congrats again to
Yury on getting that through!), and I'd like to get a stack trace
between the place at which blocking occurs and the outer co-routine.
For example, consider this code:
async def a():
async def b():
coro_a = a()
At this point I'd really like to be able to somehow get a stack trace
Using the gi_frame attribute of coro_a, I can get the line number of
the outer frame (e.g.: line 2), but from there there is no way to
descend the stack to reach the actual yield point.
I thought that perhaps the switch() co-routine could yield the frame
object returned from inspect.currentframe(), however once that
function yields that frame object has f_back changed to None.
A hypothetical approach would be to work the way down form the
outer-frame, but that requires getting access to the co-routine object
that the outer-frame is currently await-ing. Some hypothetical code
if dis.opname[coro.gi_code.co_code[coro.gi_frame.f_lasti + 1]] ==
This relies on the fact that an await-ing co-routine will be executing
a YIELD_FROM instruction. The above code uses a completely
hypothetical 'f_stack' property of frame objects to pull the
co-routine object which a co-routine is currently await-ing from the
stack. I've implemented a proof-of-concept f_stack property in the
frameobject.c just to test out the above code, and it seems to work.
With all that, some questions:
1) Does anyone else see value in trying to get the stack-trace down to
the actual yield point?
2) Is there a different way of doing it that doesn't require changes
to Python internals?
3) Assuming no to #2 is there a better way of getting the information
compared to the pretty hacking byte-code/stack inspection?
Quote from: http://worrydream.com/dbx/
Reactions to SOAP and Fortran
Richard Hamming -- The Art of Doing Science and Engineering, p25 (pdf
In the beginning we programmed in absolute binary... Finally, a
Symbolic Assembly Program was devised -- after more years than you are apt
to believe during which most programmers continued their heroic absolute
binary programming. At the time [the assembler] first appeared I would
guess about 1% of the older programmers were interested in it -- using
[assembly] was "sissy stuff", and a real programmer would not stoop to
wasting machine capacity to do the assembly.
Yes! Programmers wanted no part of it, though when pressed they had to
admit their old methods used more machine time in locating and fixing up
errors than the [assembler] ever used. One of the main complaints was when
using a symbolic system you do not know where anything was in storage --
though in the early days we supplied a mapping of symbolic to actual
storage, and believe it or not they later lovingly pored over such sheets
rather than realize they did not need to know that information if they
stuck to operating within the system -- no! When correcting errors they
preferred to do it in absolute binary.
FORTRAN was proposed by Backus and friends, and again was opposed by
almost all programmers. First, it was said it could not be done. Second, if
it could be done, it would be too wasteful of machine time and capacity.
Third, even if it did work, no respectable programmer would use it -- it
was only for sissies!
John von Neumann's reaction to assembly language and Fortran
John A.N. Lee, Virginia Polytechnical Institute
John von Neumann, when he first heard about FORTRAN in 1954, was
unimpressed and asked "why would you want more than machine language?" One
of von Neumann's students at Princeton recalled that graduate students were
being used to hand assemble programs into binary for their early machine.
This student took time out to build an assembler, but when von Neumann
found out about it he was very angry, saying that it was a waste of a
valuable scientific computing instrument to use it to do clerical work.
Because 1% of the older programmers that did not accept to use Assembly
changed their minds about the Assembly?
Because the older programmers think that using [assembly] was "sissy
stuff", and a real programmer would not stoop to wasting machine capacity
to do the assembly?
What were all the complaints of binary code programmers that did not accept
to use Assembly?
John Von Neumann changed his mind about the Assembly and Fortran?
As part of a bit of hacking on CPython, I'm looking at playing with
the grammar. In the source tree, Grammar/Grammar, there's a note
advising me to follow the steps in PEP 306, but PEP 306 says it's been
moved to the dev guide. Should the source comment be changed to point
to https://docs.python.org/devguide/grammar.html ? Or is there a
better canonical location for the dev guide?
Gmail dumps patch review email in my junk box. The problem seems to be
the spoofed From: header.
Received: from psf.upfronthosting.co.za ([2a01:4f8:131:2480::3])
by mx.google.com with ESMTP id
Tue, 12 May 2015 00:20:38 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning
storchaka(a)gmail.com does not designate 2a01:4f8:131:2480::3 as permitted
Tracker reviews are the only false positives in my junk list. Otherwise,
I might stop reviewing. Verizon does not even deliver mail that fails
its junk test, so I would not be surprised if there are people who
simply do not get emailed reviews.
Tracker posts are sent from Person Name <report(a)bugs.python.org>
Perhaps reviews could come 'from' Person Name <review(a)bugs.python.org>
Even direct tracker posts just get a neutral score.
Received-SPF: neutral (google.com: 2a01:4f8:131:2480::3 is neither
permitted nor denied by best guess record for domain of
SPF is Sender Policy Framework
Checkins mail, for instance, gets an SPF 'pass' because python.org
designates mail.python.org as a permitted sender.
Terry Jan Reedy
There are issues with the doctype() method of XMLParser.
1. Using subclass of XMLParser emits a deprecation warning .
2. There is behavior difference between Python and C implementations if
implement doctype() .
This method was deprecated for long time, and the simplest solution is
to completely remove it. The questions are:
1. Can doctype() be removed or there is significant risk to break
2. If fix doctype() instead of removing it (in any case should be done
in maintained releases), what behavior should be preserved? Should
target's doctype() be called instead of XMLParser.doctype() (Python
implementation) or be called in addition to XMLParser.doctype() (C
Eli suggested to ask on Python-Dev.