In article <20150615003717.2599.82804(a)psf.io>,
senthil.kumaran <python-checkins(a)python.org> wrote:
> https://hg.python.org/cpython/rev/9a0c5ffe7420
> 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
> summary:
> null merge with 3.4
>
> Back porting changeset db302b88fdb6 to 3.4 branch, which fixed multiple
> documentation typos.
>
> Related Issues:
> #issue21528
> #issue24453
>
> files:
Senthil,
There is now an active 3.5 branch, so the correct current order of
merging is:
3.4 -> 3.5
3.5 -> default
I've checked in a couple of null merges to try to fix things.
--
Ned Deily,
nad(a)acm.org
Hi all,
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():
await b()
async def b():
await switch()
@types.coroutine
def switch():
yield
coro_a = a()
coro_a.send(None)
"""
At this point I'd really like to be able to somehow get a stack trace
similar to:
test.py:2
test.py:4
test.py:9
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
could be:
"""
def show(coro):
print("{}:{}".format(coro.gi_frame.f_code.co_filename,
coro.gi_frame.f_lineno))
if dis.opname[coro.gi_code.co_code[coro.gi_frame.f_lasti + 1]] ==
'YIELD_FROM':
show(coro.gi_frame.f_stack[0])
"""
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?
Thanks,
Ben
Quote from: http://worrydream.com/dbx/
<http://www.google.com/url?q=http%3A%2F%2Fworrydream.com%2Fdbx%2F&sa=D&sntz=…>
Reactions to SOAP and Fortran
Richard Hamming -- The Art of Doing Science and Engineering, p25 (pdf
book)
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?
ChrisA
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
m1si26039166wjy.52.2015.05.12.00.20.38
for <tjreedy(a)udel.edu>;
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
sender) client-ip=2a01:4f8:131:2480::3;
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
roundup-admin(a)psf.upfronthosting.co.za) client-ip=2a01:4f8:131:2480::3;
SPF is Sender Policy Framework
https://en.wikipedia.org/wiki/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 [1].
2. There is behavior difference between Python and C implementations if
implement doctype() [2].
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
someone's code?
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
implementation)?
Eli suggested to ask on Python-Dev.
[1] http://bugs.python.org/issue19176
[2] http://bugs.python.org/issue19176#msg238783
As the subject says, I've been unable to build the regex module against
Python 3.5b1 for 32-bit. MingGW says:
skipping incompatible .../libpython35.a when searching for -lpython35
It builds without a problem against Python 3.5 for 64-bit.
Any ideas? Should I just wait until beta 2?