[Python-Dev] Python3 C extension how to support dir()
I first ask this on python users. But I think the only people that can answer are the core developers. I have a python3 C++ extension that works written using the PyCXX C++ interface. But dir(obj) does not return the list of member variables. With the python2 version supporting the __members__ variable was all that was needed. But __members__ been removed from python3. How should I support dir() from the C API? I cannot use tp_members, not appropiate to the code I'm writing. If I provide __dir__ I then hit the problem I need the C API version of: all_attr = super( mytype, obj ).__dir__(); all_attr.extend( mytype_variable_names ); return all_attr I'm not getting inspiration from the python 3.6 sources for this problem. I did find the object_dir function in typeobject.c, but that has not helped get me move forward. What is the the patten that I should implement? Barry PyCXX ___ 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] Proposed BDFL Delegate update for PEPs 538 & 540 (assuming UTF-8 for *nix system boundaries)
Hi folks (mainly Guido), Due to constraints on his available time, Barry has decided to step down as BDFL-Delegate for PEP 538 (my proposal to default to coercing the legacy C locale to newer UTF-8 based locales when the latter are available). After discussion with Barry and Inada-san, Victor and I are now proposing to invite Naoki Inada to take on the task of being BDFL-Delegate for both PEP 538 and Victor's related PEP 540, with the following rationale: - the two PEPs are sufficiently closely related that Barry, Victor and I think the same person should be the final decision maker for both of them - with the initial delegation of PEP 538 to Barry, Guido indicated he'd prefer to delegate the task rather than having to come fully up to speed on the vagaries of modern *nix locale handling and the current state of the affected system boundaries in CPython - Inada-san has already been active in reviewing and commenting on both proposals - being based in Japan and working with Japanese text and interfaces, Inada-san regularly encounters the developer experience problems that these proposals are intended to help address Assuming Guido's OK with that proposed delegation, I'll update the headers on both PEPs accordingly. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed BDFL Delegate update for PEPs 538 & 540 (assuming UTF-8 for *nix system boundaries)
+1. I have full confidence that Inada-san will be a trustworthy delegate for these PEPs. --Guido On Sun, Apr 23, 2017 at 9:00 PM, Nick Coghlan wrote: > Hi folks (mainly Guido), > > Due to constraints on his available time, Barry has decided to step > down as BDFL-Delegate for PEP 538 (my proposal to default to coercing > the legacy C locale to newer UTF-8 based locales when the latter are > available). > > After discussion with Barry and Inada-san, Victor and I are now > proposing to invite Naoki Inada to take on the task of being > BDFL-Delegate for both PEP 538 and Victor's related PEP 540, with the > following rationale: > > - the two PEPs are sufficiently closely related that Barry, Victor and > I think the same person should be the final decision maker for both of > them > - with the initial delegation of PEP 538 to Barry, Guido indicated > he'd prefer to delegate the task rather than having to come fully up > to speed on the vagaries of modern *nix locale handling and the > current state of the affected system boundaries in CPython > - Inada-san has already been active in reviewing and commenting on > both proposals > - being based in Japan and working with Japanese text and interfaces, > Inada-san regularly encounters the developer experience problems that > these proposals are intended to help address > > Assuming Guido's OK with that proposed delegation, I'll update the > headers on both PEPs accordingly. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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] API for bugs.python.org or some statistic about lib/module merge rate?
On 21 April 2017 at 06:04, Wes Turner wrote: > Roundup has an xmlrpc API: > > - https://sourceforge.net/p/roundup/code/ci/default/tree/roundup/xmlrpc.py > - https://sourceforge.net/p/roundup/code/ci/default/tree/test/test_xmlrpc.py There's also a pending patch to add a HTTPS+JSON REST API to our Roundup instance: http://psf.upfronthosting.co.za/roundup/meta/issue581 Definite +1 for the general idea of collecting and publishing these kinds of statistics, though - I can see them being quite useful to a variety of audiences. Cheers, Nick. P.S. The upstream Roundup project is also interested in offering that capability by default: http://issues.roundup-tracker.org/issue2550734 -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Request review of cProfile/profile series issue
On 23 April 2017 at 13:21, Louie Lu wrote: > Hi all, > > I'm now looking for cProfile/profile lib's issue, and have solve a series of > dependent problem, here is the list: > > #9285 - Add a profile decorator to profile and cProfile > #30113 - Allow helper functions to wrap sys.setprofile > #18971 - Use argparse in the profile/cProfile modules > #30118 - Add unittest for cProfile/profile command line interface > > It can divide into two categories, first is the context manager problem, and > the second is optparse to argparse problem. > > 1. context manager problem: > > Relative issue: #9285, #30113 > Relative PR: #287, #1212, #1253 > > This is an issue since 2010, and stop at profile can't simply add a > __enter__ and __exit__ to make it a context manager. The main problem is, > sys.setprofile() will hit the return and get bad return in profile > dispatch_return function. The solution is to insert a simulate call in the > helper function, to provide the context between helper frame and where the > profile is defined. I'd like to second Louie's call for additional review here. I've been reviewing them so far, and they look sensible to me, but I don't personally know the profile code base at all, so there's a strong chance I'll miss subtle details. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
