Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?

[Nathaniel Smith]

On Tue, Feb 28, 2017 at 9:42 PM, Nick Coghlan  wrote:
> Short version:
>
> - there are some reasonable requests for async variants of contextlib APIs
> for 3.7
> - prompted by Raymond, I'm thinking it actually makes more sense to add
> these in a new `asyncio.contextlib` module than it does to add them directly
> to the existing module
> - would anyone object strongly to my asking authors of the affected PRs to
> take their changes in that direction?

IMHO this is a good idea *iff* the new APIs really are bound to
asyncio, rather than being generic across all uses of async/await.

It sounds like that's not the case, though? There are definitely use
cases for acontextmanager in programs that don't use asyncio at all
(but rather use twisted, curio, ...). Guido's even suggested that he'd
like to see a PEP for an "asyncio2" within the 3.7/3.8 timeframe:
https://mail.python.org/pipermail/async-sig/2016-November/000175.html

asyncio is an important use case for async/await, but it's definitely
not the only one. In cases where it's possible to write generic
machinery in terms of async/await semantics, without assuming any
particular coroutine runner's semantics, then I strongly urge you to
do so.

> Longer version:
>
> There are a couple of open issues requesting async variants of some
> contextlib APIs (asynccontextmanager and AsyncExitStack). I'm inclined to
> accept both of them, but Raymond raised a good question regarding our
> general design philosophy for these kinds of additions: would it make more
> sense to put these in an "asyncio.contextlib" module than it would to add
> them directly to contextlib itself?
>
> The main advantage I see to the idea is that if someone proposed adding an
> "asyncio" dependency to contextlib, I'd say no. For the existing
> asynccontextmanager PR, I even said no to adding that dependency to the
> standard contextlib test suite, and instead asked that the new tests be
> moved out to a separate file, so the existing tests could continue to run
> even if asyncio was unavailable for some reason.

asyncio is a stable, non-provisional part of the standard library;
it's not going anywhere. Personally I wouldn't be bothered about
depending on it for tests. (My async_generator library is in a similar
position: it isn't tied to any particular framework, and I don't even
use asyncio myself, but the test suite depends on asyncio because hey,
whatever, everyone already has it and it plays the role of generic
coroutine runner as well as anything else does.)

OTOH if you don't need to do any I/O then it's actually pretty easy to
write a trivial coroutine runner. I think something like this should
be sufficient to write any test you might want:

@types.coroutine
def send_me(value):
return yield ("value", value)

@types.coroutine
def throw_me(exc):
yield ("error", exc)

async def yield_briefly():
await send_me(None)

def run(async_fn, *args, **kwargs):
coro = async_fn(*args, **kwargs)
next_msg = ("value", None)
try:
while True:
if next_msg[0] == "value":
next_msg = coro.send(next_msg[1])
else:
next_msg = coro.throw(next_msg[1])
except StopIteration as exc:
return exc.value

> While rejecting the idea of an asyncio dependency isn't a problem for
> asyncontextmanager specifically (it's low level enough for it not to
> matter), it's likely to be more of a concern for the AsyncExitStack API,
> where the "asyncio.iscoroutinefunction" introspection API is likely to be
> quite helpful, as are other APIs like `asyncio.ensure_future()`.

FYI FWIW, every time I've tried to use iscoroutinefunction so far I've
ended up regretting it and ripping it out again :-). The problem is
that people will do things like apply a decorator to a coroutine
function, and get a wrapped function that returns a coroutine object
and which is interchangeable with a real coroutine function in every
way except that iscoroutinefunction returns False. And there's no
collections.abc.CoroutineFunction (not sure how that would even work).
Better to just call the thing and then do an isinstance(...,
collections.abc.Coroutine) on the return value.

I haven't had a reason to try porting ExitStack to handle async
context managers yet, so I can't speak to it beyond that :-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.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

Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?

[Ethan Furman]

On 02/28/2017 09:42 PM, Nick Coghlan wrote:


So would folks be OK with my asking the author of the PR for 
https://bugs.python.org/issue29679 (adding
asynccontextmanager) to rewrite the patch to add it as 
asyncio.contextlib.asyncontextmanager (with a cross-reference
from the synchronous contextlib docs), rather than the current approach of 
adding it directly to contextlib?


I like the idea of keep the asyncio stuff in one general location.

--
~Ethan~

___
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] API design: where to add async variants of existing stdlib APIs?

[Nick Coghlan]

Short version:

- there are some reasonable requests for async variants of contextlib APIs
for 3.7
- prompted by Raymond, I'm thinking it actually makes more sense to add
these in a new `asyncio.contextlib` module than it does to add them
directly to the existing module
- would anyone object strongly to my asking authors of the affected PRs to
take their changes in that direction?

Longer version:

There are a couple of open issues requesting async variants of some
contextlib APIs (asynccontextmanager and AsyncExitStack). I'm inclined to
accept both of them, but Raymond raised a good question regarding our
general design philosophy for these kinds of additions: would it make more
sense to put these in an "asyncio.contextlib" module than it would to add
them directly to contextlib itself?

The main advantage I see to the idea is that if someone proposed adding an
"asyncio" dependency to contextlib, I'd say no. For the existing
asynccontextmanager PR, I even said no to adding that dependency to the
standard contextlib test suite, and instead asked that the new tests be
moved out to a separate file, so the existing tests could continue to run
even if asyncio was unavailable for some reason.

While rejecting the idea of an asyncio dependency isn't a problem for
asyncontextmanager specifically (it's low level enough for it not to
matter), it's likely to be more of a concern for the AsyncExitStack API,
where the "asyncio.iscoroutinefunction" introspection API is likely to be
quite helpful, as are other APIs like `asyncio.ensure_future()`.

So would folks be OK with my asking the author of the PR for
https://bugs.python.org/issue29679 (adding asynccontextmanager) to rewrite
the patch to add it as asyncio.contextlib.asyncontextmanager (with a
cross-reference from the synchronous contextlib docs), rather than the
current approach of adding it directly to contextlib?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] PyQt - DLL load failed

[Terry Reedy]

On 2/28/2017 9:56 AM, Edouard ROYER wrote:

Hi,

I'm pretty new in Python but as I was looking for some new programmer's
tool, it seemed to me that Python should be the right language for my
needs.

However, trying to run PyQt on my computer I have an issue that I didn't
manage yet : trying to import objects from PyQt library leads to the
following message :  "ImportError : DLL load failed : Impossibile
trovare la procedura specificata". Either with PyCharm or launching
Jupyter QtConsole.


Pydev is for developing future versions of Python and CPython. Questions 
about using current versions should be directed to pythohn-list or other 
forums.


--
Terry Jan Reedy

___
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] GDB macros in Misc/gdbinit are broken

[Victor Stinner]

2017-02-28 20:38 GMT+01:00 Alexander Belopolsky
:
> First, I had to rename python-gdb.py to python3.6-gdb.py to make it load.

There is nothing specific to Python here, the file command of gdb (or
gdb file) tries to load "file-gdb.py". So if your program is called
python3.6, gdb looks for python3.6-gdb.py, yeah.

> Then running backtrace gave me a bunch of error messages:
> (...)
> except gdb.error:
> AttributeError: 'module' object has no attribute 'error'

Oh, I never tried python-gdb.py on RHEL. Sadly, I know that the Python
binding of gdb changes depending on the gdb version, but I also
suspect that it changes depending on the OS! I'm quite sure that
Fedora backports gdb changes for its Python API.

I'm only using python-gdb.py on Fedora, usually even the latest Fedora
version. Fedora always has bleeding edge versions of development
tools!

It shouldn't be hard to catch this "except gdb.error:" line. We should
find the right exception and patch libpython.py.


> It looks like there is a mismatch between python-gdb.py  and the gdb module
> that I assume comes with gdb.

python-gdb.py (libpython.py) should work on any gdb version. It
shouldn't be hard to support multiple gdb versions in same code base,
we already support Python 2 and Python 3 in the same code base!
(Depending on the OS and OS version, gdb may use Python 2 or Python 3
to run python-gdb.py, this script is run by gdb, not by test debugged
Python binary! ;-))

Victor
___
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] GDB macros in Misc/gdbinit are broken

[Victor Stinner]

Ok, it seems like very few people know how to use python-gdb.py :-/
Sorry, I expect that everybody was using it!

python-gdb.py was written by Dave Malcolm, it includes:

* a pretty printer for many builtin Python types: str, tuple, list,
dict, frame, etc. It means that a regular gdb "print obj" command
displays the Python object content instead of a raw pointer. This
feature is super useful, it avoids to call _PyObject_Dump(obj) which
is likely to crash!
* commands to navigate between Python frames: py-up, py-down
* command to dump the Python traceback: py-bt, py-bt-full (also
include C frames)
* a few more commands

For me, these commands are really amazing! It's impressive to be able
to that in a debugger which doesn't know Python internals at all! It's
cool to be able to "program" (extend) a debugger!

I never tried to install it, I always use it with a ./python binary
compiled in the source code tree:
---
$ make
$ gdb ./python
# load ./python-gdb.py
...
---

Note: ./python-gdb.py is simply a copy of Tools/gdb/libpython.py,
copied by Makefile.

On Fedora, gdb doesn't load python-gdb.py because it doesn't trust my
$HOME/prog directory (root of all my development directories). I had
to trust it using this ~/.gdbinit config:
---
add-auto-load-safe-path ~/prog/
---

More generally, when gdb loads a "program", it tries to load
"program-gdb.py" in the same directory. Maybe it can load
"program-gdb.py" from other directories, but I never understood this
part, and hopefully I never had to understand it :-D

Maybe the debug package of Python on Debian and Fedora installs
pythonX.Y-gdb.py in the right directory, I didn't check, but I always
debug using a freshly compiled Python, so I never tried to understand
how these things work.

Example:

haypo@selma$ gdb ./python
(gdb) b _PyEval_EvalFrameDefault
(gdb) run

Breakpoint 1, _PyEval_EvalFrameDefault (
f=Frame 0x77f22058, for file ,
line 25, in  (), throwflag=0) at Python/ceval.c:678
678PyObject *retval = NULL;/* Return value */

=> gdb displays the content of the frame "f", you can see immediately
the filename and the line number (well, this frame is a little bit
special, it's the frozen module importlib)

(gdb) py-bt
Traceback (most recent call first):
  File "", line 25, in 
---

Example of Python traceback:

haypo@selma$ gdb -args ./python -m test -r
(gdb) run
...
^C
(gdb) py-bt
Traceback (most recent call first):
  File "/home/haypo/prog/python/master/Lib/test/test_long.py", line
947, in test_bit_length
self.assertEqual(k, len(bin(x).lstrip('-0b')))
  File "/home/haypo/prog/python/master/Lib/unittest/case.py", line 601, in run
testMethod()
  File "/home/haypo/prog/python/master/Lib/unittest/case.py", line
649, in __call__
return self.run(*args, **kwds)
  File "/home/haypo/prog/python/master/Lib/unittest/suite.py", line 122, in run
test(result)
  File "/home/haypo/prog/python/master/Lib/unittest/suite.py", line
84, in __call__
return self.run(*args, **kwds)
  ...

=> you get filename, line number, function name and even the Python
line! It seems obvious to get such information, but remind that you
are in gdb, not in Python

(gdb) py-list
 942def test_bit_length(self):
 943tiny = 1e-10
 944for x in range(-65000, 65000):
 945k = x.bit_length()
 946# Check equivalence with Python version
>947self.assertEqual(k, len(bin(x).lstrip('-0b')))
 948# Behaviour as specified in the docs
 949if x != 0:
 950self.assertTrue(2**(k-1) <= abs(x) < 2**k)
 951else:
 952self.assertEqual(k, 0)

# move to the parent Python frame (= skip mutiple C frames until the
next Python frame)
(gdb) py-up
(...)

(gdb) py-list
 596with outcome.testPartExecutor(self):
 597self.setUp()
 598if outcome.success:
 599outcome.expecting_failure = expecting_failure
 600with outcome.testPartExecutor(self, isTest=True):
>601testMethod()
 602outcome.expecting_failure = False
 603with outcome.testPartExecutor(self):
 604self.tearDown()
 605
 606self.doCleanups()

(gdb) py-locals
self =  dump all variables of the current Python frame!


Victor
___
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] GDB macros in Misc/gdbinit are broken

[Skip Montanaro]

> First, I had to rename python-gdb.py ...

Okay, I found a copy of python-gdb.py at the top level in a 2.7.13
snapshot I have at-hand. I have no idea where it came from. A file
search on GitHub in the python/cpython repo on both master and 2.7
branches yielded nothing.

It does seem to be working for me on a debug build of Python 2.7.13 (I
ran strings over my GDB executable first to see if it knew anything
about Python, and it did).

Thx,

Skip
___
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] GDB macros in Misc/gdbinit are broken

[Alexander Belopolsky]

On Tue, Feb 28, 2017 at 3:33 AM, Victor Stinner 
wrote:

>
> Alexander, Skip: Oh, which kind of issues do you have with
> python-gdb.py? It doesn't work? You are unable to dump some data?


First, I had to rename python-gdb.py to python3.6-gdb.py to make it load.
Then running backtrace gave me a bunch of error messages:


(gdb) bt
#0  builtin_hex (module=, number=0) at
Python/bltinmodule.c:1436
#1  0x77a9304c in _PyCFunction_FastCallDict (func_obj=, args=0x662cf8,
nargs=1, kwargs=0x0)
at Objects/methodobject.c:209
#2  0x77a9344b in _PyCFunction_FastCallKeywords (func=, stack=0x662cf8,
nargs=1, kwnames=0x0)
at Objects/methodobject.c:295
#3  0x77bac6d9 in call_function (pp_stack=0x7fffb6d8, oparg=1,
kwnames=0x0) at Python/ceval.c:4788
#4  0x77ba3e6c in _PyEval_EvalFrameDefault (f=Frame 0x662b68, for
file r.py, line 2, in  (), throwflag=0) at Python/ceval.c:3275
#5  0x77b8cc67 in PyEval_EvalFrameEx (f=Frame 0x662b68, for file
r.py, line 2, in  (), throwflag=0) at Python/ceval.c:718
#6  0x77ba9745 in _PyEval_EvalCodeWithName (_co=, globals=Traceback (most recent call last):
  File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 1358, in
to_string
return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
  File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 243, in
get_truncated_repr
self.write_repr(out, set())
  File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 702, in
write_repr
for pyop_key, pyop_value in self.iteritems():
  File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 669, in
iteritems
entries, nentries = self._get_entries(keys)
  File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 717, in
_get_entries
except gdb.error:
AttributeError: 'module' object has no attribute 'error'
...

It looks like there is a mismatch between python-gdb.py  and the gdb module
that I assume comes with gdb.

$ gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
..
___
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] Python 2.7.13 unmodified will not build from source on Mac OS El Capitan (10.11)

[Bryan Dunphy]

I have Xcode installed and other large projects build just fine. I ran 
“./configure && make” in the “Python-2.7.13” directory and “make” generated two 
errors both referring to the same thing missing. The exact error messages are 
copied and pasted below.

dyld: lazy symbol binding failed: Symbol not found: _getentropy
  Referenced from: /Users/bryandunphy/Downloads/Python-2.7.13/./python.exe
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _getentropy
  Referenced from: /Users/bryandunphy/Downloads/Python-2.7.13/./python.exe
  Expected in: /usr/lib/libSystem.B.dylib

/bin/sh: line 1: 14105 Trace/BPT trap: 5   CC='gcc' LDSHARED='gcc -bundle 
-undefined dynamic_lookup -L/usr/local/lib' OPT='-DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python.exe -E 
./setup.py $quiet build
make: *** [sharedmods] Error 133

That was the final output from make.

Any ideas on how to fix these errors and allow a build?
___
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] PyQt - DLL load failed

[Edouard ROYER]

Hi,

I'm pretty new in Python but as I was looking for some new programmer's 
tool, it seemed to me that Python should be the right language for my needs.


However, trying to run PyQt on my computer I have an issue that I didn't 
manage yet : trying to import objects from PyQt library leads to the 
following message :  "ImportError : DLL load failed : Impossibile 
trovare la procedura specificata". Either with PyCharm or launching 
Jupyter QtConsole.


I already read a lot of posts talking about similar issues nut none of 
them gave me a valid solution.


Did i miss something ? Could it be a version problem (even if I'm pretty 
sure to have install in 32 bits compatibility) ?


Many thanks.

Edouard

--
Edouard ROYER
BLUEFARM s.r.l.
Via delle Industrie 15
30175 Venezia Marghera (IT)
Tel. +39 327 1989840


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus

___
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] Translated Python documentation

[Xiang Zhang]

I support having an official translated doc.

I have seen several groups trying to translate part of our official doc.
But their efforts are disperse and quickly become lost because they
are not organized to work towards a single common result and their
results are hold anywhere on the Web and hard to find. An official one
could help ease the pain.

But I agree we may need more details on the workflow.






At 2017-02-27 19:04:21, "Victor Stinner"  wrote:
>2017-02-24 16:10 GMT+01:00 Steven D'Aprano :
>>> …And then you need another one to
>>> check what was written.  These are practical problems.  There are
>>> extant services to support this, they are expensive in either money or
>>> time, and the docs produced usually lag behind English quite a bit.
>>
>> Is this a good use for some PSF funding? Would companies be willing to
>> invest money in translating Python documentation?
>>
>> Just because we're Open Source, doesn't mean that everything we do has
>> to be purely volunteer.
>
>IHMO translating the *whole* Python documentation at once by a
>professional translator can be very expensive, no somthing that the
>PSF would affort. Which language would you pick? Depending on what?
>
>We already have motivated translators for free who only ask us for the
>permission to make tiny changes to make their life simpler and make
>the doc more visible. I'm in favor of allowing them to translate and
>make the translated doc official ;-)
>
>IMHO a better usage of the PSF funding would be to organize some local
>sprints to translate the Python documentation. Such sprints are fun,
>cheap, and can be a nice opportunity to recruit free and motivated
>translators. We are looking for people involved to translate the doc
>the doc is updated, not only translate the doc once and go away.
>Right?
>
>Victor
>
___
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] GDB macros in Misc/gdbinit are broken

[Barry Warsaw]

On Feb 28, 2017, at 09:09 AM, Skip Montanaro wrote:

>I haven't tried using Python support in gdb in a long time. I don't
>know what python-gdb.py is. How is that different than
>Tools/gdb/libpython.py? Is it distributed with Python? (I'm kind of
>blind at work without a source distribution I can grep through, and
>didn't see it in Tools/gdb or Misc.)
>
>I'm a simple man. I need the kind of stuff Misc/gdbinit provides
>(smart stack traces and variable printing), but I most frequently use
>the pyo user-defined command to print the contents of PyObject
>pointers. When they are working () pystack and pyframe are also
>useful.

I think I'm largely in the same boat as Skip although it's been a while since
I stepped through the C code.  I also had trouble (ages ago) getting the gdb
integration working, so I relied on the simple stuff in gdbinit.  I think
there's still utility in that if we can keep it working.

-Barry
___
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] GDB macros in Misc/gdbinit are broken

[Skip Montanaro]

I haven't tried using Python support in gdb in a long time. I don't
know what python-gdb.py is. How is that different than
Tools/gdb/libpython.py? Is it distributed with Python? (I'm kind of
blind at work without a source distribution I can grep through, and
didn't see it in Tools/gdb or Misc.)

I'm a simple man. I need the kind of stuff Misc/gdbinit provides
(smart stack traces and variable printing), but I most frequently use
the pyo user-defined command to print the contents of PyObject
pointers. When they are working () pystack and pyframe are also
useful.

Skip

On Tue, Feb 28, 2017 at 2:33 AM, Victor Stinner
 wrote:
> 2017-02-28 3:00 GMT+01:00 Skip Montanaro :
>> Alexander> I find them useful.  I've never had success with python-gdb.py.
>
> Alexander, Skip: Oh, which kind of issues do you have with
> python-gdb.py? It doesn't work? You are unable to dump some data?
>
> python-gdb.py doesn't run code to analyze memory, it prevents crashes
> when analysing a running process, and it works on core dumps. It has
> many features, it works well. I never had major issues with it, and I
> enhance it regulary. Recently, I added support for "method-wrapper".
>
> Victor
___
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] GDB macros in Misc/gdbinit are broken

[Victor Stinner]

2017-02-28 3:00 GMT+01:00 Skip Montanaro :
> Alexander> I find them useful.  I've never had success with python-gdb.py.

Alexander, Skip: Oh, which kind of issues do you have with
python-gdb.py? It doesn't work? You are unable to dump some data?

python-gdb.py doesn't run code to analyze memory, it prevents crashes
when analysing a running process, and it works on core dumps. It has
many features, it works well. I never had major issues with it, and I
enhance it regulary. Recently, I added support for "method-wrapper".

Victor
___
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