Mailman 3 March 2011 - Python-Dev

Are these PEP complete?: 389, 391, 3108, 3135
by Nick Coghlan March 26, 2011

March 26, 2011

As the subject line asks, is there anything preventing the following PEPs from being marked Final? SA 389 argparse - New Command Line Parsing Module Bethard SA 391 Dictionary-Based Configuration For Logging Sajip SA 3108 Standard Library Reorganization Cannon SA 3121 Extension Module Initialization and Finalization von Löwis SA 3135 New Super Spealman, Delaney, Ryan (I deliberately left 3118 off the list, since there are … [View More]

4 5

Python Core Mentorship program
by Jesse Noller March 26, 2011

March 26, 2011

Hello everyone: I wanted to take a moment to outline another idea which came out of PyCon 2011 this year from numerous sources - a Python Core Mentorship Program predicated on the idea that Python-Core, and Python as a whole would be served by further lowering the barrier to entry of contribution, and to provide a program to connect new programmers, students, women, and others to experienced Python-Core developers (Mentors). Brett's revamp of the Dev guide was part one of "secret plan to get … [View More]more people involved in python-core" - this is another part, but I'm not sure of the numbering scheme. The mission of the Python Core Mentor Program is to provide an open and welcoming place to connect students, programmers - and anyone interested in contributing to the Python-Core development. This project is based on the idea that the best way to welcome new people into any project is a venue which connects them to mentors who can assist in guiding them through the contribution process, including discussions on lists such as python-dev, and python-ideas, the bug tracker, mercurial, code reviews, etc. Additionally, mentors will assist in something incredibly critical to maintain contributor interest: getting patches through the process and actually *committed*. We all know - not everyone who is mentor will have all the answers, so mentors also act as conduits to others who will have the answer. The project itself will (hopefully) be low in time-spent, and largely self-managing. We will start simple with a mailing list (core-mentorship(a)python.org) where mentors, and those who wish to be mentored or ask questions may do so. This mailing list will have a code of conduct which will help prevent flame wars, or other counterproductive discussions - a code of conduct also makes it clear to mentors what they''re agreeing to when they decide to participate. The new list will also have a closed, members-only archive. After consulting with other core developers, we believe it's easier to ask questions when you don't have to worry about Google picking up your words from a public archive. We want to make this list a resource for people to be able to get started, ask "silly" questions, and so on - our goal is to turn anyone who wishes to be into an active, sustainable committer to Python. Mentors will be asked to answer questions - but also assist people in need of help with discussions on the mailing lists and bug tracker (conversations on which could have become contentious or stressful) and generally to be advocates for the people being mentored. For example - if a person submits a patch to the tracker, the mentor list may help them through initial code reviews, or discussions with other core developers. The job is to act as an experienced proxy for them. The first step to this project is to ask for volunteer mentors - people who are willing to help answer questions on the list, and generally guide people as needed being as friendly and courteous and welcoming as possible. If you are interested in being a mentor - or have feedback about this plan in general, please feel free to reach out to me (jnoller(a)gmail.com) directly. My goal, once this is setup, is to have the project largely self-managing, with the PSF helping to market it to the community as a whole. Jesse [View Less]

15 26

Let's get PEP 380 into Python 3.3
by Guido van Rossum March 26, 2011

March 26, 2011

Now that the language moratorium is lifted, let's make sure to get PEP 380 implemented for Python 3.3. I think there are some minor issues to be resolved, but I don't think that should stop someone from doing a first pass of the implementation (especially since a version for 2.6 already exists). (OTOH I am not much enamored with cofunctions, PEP 3152.) -- --Guido van Rossum (python.org/~guido)

6 14

Re: [Python-Dev] Python Core Mentorship program
by Laura Creighton March 26, 2011

March 26, 2011

In a message of Fri, 25 Mar 2011 18:14:02 -0400, Jesse Noller writes: >Ben, > >In principle I agree with you - I would like open archives for the >specific reasons you cite, but I value the ability for people who may >not be comfortable with coming out and openly discussing things on a >list if they know it's open to the magical powers of google and public >archives. Heck, having open archives makes it *easier to find out* >about the list itself, serving the purpose even … [View More]more. > >But - weighed in favor of the target audience (those that may not yet >be comfortable with "full disclosure", or discussing personality >clashes on the tracker, or those worried about future employers >digging up stuff) - I want to error on the side of the closed list >archives for now. In several months, we all might realize it was a >monumental mistake. At that time, we can fix the problem. I would have thought that the set of people who were more comfortable with the closed list was prettry close to zero. Because the problem with saying something stupid in public is really not one of perfect strangers using google to find out that I said something stupid once, but rather that current members of the target group, in this case the subscribers to python-dev or python-dev-mentors will find out that I think stupid thoughts _now_, and think less of me for it, and maybe say some nasty things about me. Python-dev historically has been rather special. The forbidding message "Do not post general Python questions to this list. For help with Python please see the Python help page." in a red boarded box is fairly effective at getting the message "do not waste the valuable time of these people" across. For a while, I remember, we lied and said that subscriptions to python-dev needed to be approved, even when they didn't. That seemed to deter some people from even trying to join, which was probably either a good thing, or a bad thing on the whole (but, of course, we have no way to measure). And the other thing that makes python-dev unusual is that it is casually read by a large number of people who never say a word. All open mailing lists have lurkers, especially those who read them without a subscription, through some other means, but python-dev is unsual in the number of people who try to read it 'just in case something important happens', and 'just to feel like they know what is going on in the python community'. All of these factors add to the 'don't waste people's time' factor. Thus there is a lot to be said about having a separate group, where python-dev contributors answer questions that they have made time for, even if others might consider them a waste of time. Because those others are not forced to subscribe and read them. But I don't see such a compelling reason for a closed group. It's not as if we expect that mentoring to be a source of deeply personal stories and anecdotes. Or that people want the safety to discuss heretical approaches to changing CPython not expected to go down well with python-dev. It all seems to boil down to 'some people would be more comfortable this way'. I'd like to get some metrics on how many of those people there are. And I'd like to measure them against a different group, people like me who won't contribute to a closed group, in part because the whole closed-ness of it makes me undomfortable. My experience with closed-groups vs open groups has been almost entirely negative, which would be reason enough for me to hesitate to join one, but especially when it comes to a _mentoring_ list. The single most important reason why I would post something I think might be really stupid is because 'if I don't understand this, then there are probably others out there like me in the same boat'. So I ask such things with the hope that the exchange will be googled _a whole lot_ in the future. And again, when I answer a question fully and completely, I do so thinking 'I'll bet a lot of people, and not this one soul, will be interested in this'. If the answer will only be seen by the comparatively few people in a closed mailing list, I am comparatively unmotivated to write anything, or write anything substantial. I've seen a whole lot of very bad behaviour on the part of self-styled leaders of closed mailing lists. They determine the party-line of the group and then, because it is private, blast those souls who do not conform with impunity. Having been on the receiving end of a number of such exchanges, my conclusion has been that having the whole thing open is often the only defence one has. Firstly, most people are more restrained when what they say can be seen by the world at large, so some of these incidents would not happen. But secondly, the ability to share the mail with others greatly empowers the people on the receiving end. But if you cannot get an outside opinion because doing so would violate the group's closed-ness, then you are more vulnerable. The point of bringing this up is not because I think that python-dev-mentors is likely to run into these sorts of problems, but to let you know that there is a substantial number of people out there who are not emotionally comfortable with closed groups as opposed to open ones. And I don't see why the emotional comfort of those who like closed groups should have precedence over the emotional comfort of those of us who find closed groups threatening. The argument 'we'll try it closed, and then we will see about opening it up, later' doesn't work for me, because every time I have been involved in such an effort, except once, the end result has been that later _never_ happens. The people who like the group closed _always_ successfully resist such change. It is too much easier for people like me who only got involved in the first place because of the expectation of the group's eventual opening to drop out and quit the group than to spend the amount of energy necessary to open the group up. And for me, at any rate, my reluctance to spend the energy is in large part because of the closed-ness of the group. I'd care a lot more about the group, if the group was open. I don't think that people like me are that rare -- hmm, I should rephrase that -- I don't think that people with this attitude towards closed groups are that rare. And it is hard to find out about us, because we're the people who don't join such things. So no matter how well a given closed group works, according to those who are members of such a thing, it is impossible to say whether the group would have been _so_ _much_ _better_ if it were open -- or whether being closed was essential to its success. So 'In several months we might all realize that this was a momentual mistake and then fix the problem' never works. No matter what you do, there will always be some people who like it, so you will never get the 'all'. But what might be possible to measure is the number of people who won't be joining a closed list, but who would join an open one, versus those who will join the closed list but wouldn't join the open one, by having some sort of vote. Of course, a vote could only measure people's intentions, which are often different from what they really do, but it would at least allow some sort of measurement of what isn't happening, which is otherwise close to impossible to see. I for one would feel a lot better about what I was missing out on in python-dev-mentors if I knew that there were some actual human beings benefitting from it who would not have joined an open group. Without some sort of metric, I will always worry that it was done 'in case there might be people like that out there' or 'to test the theory that the reason we don't have enough python-dev contributers is because python-dev is an open group' without any actual use-cases at all. > >"The perfect is the enemy of the good." :) > "If you can not measure it, you can not improve it." Lord Kelvin: (Sir William Thomson) Laura >jesse [View Less]

4 4

Re: [Python-Dev] Python Core Mentorship program
by Laura Creighton March 26, 2011

March 26, 2011

In a message of Sat, 26 Mar 2011 10:46:27 +1100, Ben Finney writes: > The audience of the proposed forum (AFAICT) is people who want to learn > enough to contribute to the Python core. So, no, they're different > roles. The other side of the proposed forum is people who want to teach such people. Many of them (and no doubt many of the learners) don't read python-list due to its high volume. Laura

2 1

Re: [Python-Dev] Mentorship list
by Tommy March 26, 2011

March 26, 2011

I was kinda hoping that a private list would have much less noise, and would serve the actual mentoring better. Maybe a mailing list isnt't the ideal tool?

2 1

hg diff
by "Martin v. Löwis" March 25, 2011

March 25, 2011

It seems that the dev guide recommends to use the --git option in hg diff. I'm working on the Rietveld integration, and found that this option makes things worse: the regular diff includes the base revision of the patch; hg diff --git doesn't. So I would rather like people not to use the --git option. Regards, Martin

12 38

Submitting changes through Mercurial
by "Martin v. Löwis" March 25, 2011

March 25, 2011

I've added a feature in the bug tracker where submitters can post Mercurial repository URLs, and then repeatedly create patches. Roundup will extract the current patch (cpython-default:submitter-default), and attach the patch to the issue (which then allows Rietveld review of the patch). Regards, Martin

9 26

Unload a module written in C
by Victor Stinner March 25, 2011

March 25, 2011

Hi, I am trying to understand why I am unable to unload my faulthandler module (implemented in C). Antoine pointed me _PyImport_FixupExtensionObject() comment which gave me a first clue: Modules which do support multiple initialization set their m_size field to a non-negative number (indicating the size of the module-specific state). They are still recorded in the extensions dictionary, to avoid loading shared libraries twice. Ok, so I changed the size from -1 to 0, and so the … [View More]

4 9

Summary of Python tracker Issues
by Python tracker March 25, 2011

March 25, 2011

ACTIVITY SUMMARY (2011-03-18 - 2011-03-25) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2735 (+12) closed 20718 (+63) total 23453 (+75) Open issues with patches: 1165 Issues opened (57) ================== #7391: Re-title the "Using Backslash to Continue Statements" anti-idi http://bugs.python.org/issue7391 reopened by pitrou #11597: Can't get … [View More]

1 0