Re: [Python-Dev] sprints and pushes

[Stephen J. Turnbull]

Tres Seaver writes:

 > That was precisely my proposal:

Sorry about that.  I live in a disaster area, and was limited to
GMail until two days ago, and lost a fair amount of context in the
switch back.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Zak Stone]

Hello everyone,

I'm new to this list, but I have been an informal mentor for computer
science students at Harvard for several years, and I'd like to share
some observations that may be relevant. In my experience, students are
willing to ask many technical questions in person that they simply
won't ask privately over email, and very few students seem willing to
ask questions on public mailing lists at all.

My impression from these personal observations is that many students
benefit greatly from informal, ephemeral communication with technical
mentors. It may not be easy to analyze _why_ things work this way, but
I believe part of the answer is that the student-mentor relationship
is not primarily about the information exchanged; it is about trust.
The student knows that in a moment of deep frustration, he or she can
privately turn to someone with the patience and experience to help
without being humiliated, which is tremendously reassuring.

At Harvard, we are currently witnessing a huge increase in student
interest in computer science in general and Python in particular,
which I hope is representative of a broader trend. Excellent
mentorship is rare, and I believe strong mentors from the Python
community could be a potent draw for new contributors in this
atmosphere of enthusiasm. One way or another, I hope you can
facilitate informal, ephemeral communication between these newcomers
and their mentors to maximize the newcomers' chances of success.

Many thanks,
Zak
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Nick Coghlan]

On Sat, Mar 26, 2011 at 3:20 PM, Ethan Furman  wrote:
>
> I disagree.  The goal of mentorship is to help someone learn -- a subtle,
> yet distinct, difference.  I think a closed list will suit that purpose
> better.
>
> Keep in mind also that the list is *closed*, not *locked* -- anyone can
> join, and anyone who has joined has full access to current goings-on and to
> the archives.

The other thing to remember is that part of the purpose of the new
list is to fulfil roles that python-dev doesn't (and shouldn't really
be expected to) handle.

These are things like:
- keeping in touch with new contributors that participate in core sprints
- asking for clarifications of points that may not be clear in the devguide
- how to respond to negative feedback on the public lists and on the tracker
- advice on "who's who" on the public mailing lists

Anyone that is themselves comfortable with the rough-and-tumble of
typical open source development may see the list as unnecessary, and
that's fine. python-dev does see new contributors arriving without an
active mentorship program, and that's great.

However, there are still an *awful* lot of modules on
http://docs.python.org/devguide/experts that don't have names against
them. The tracker still has a huge backlog of issues, some of which
are there because they're genuinely difficult, but others are there
just because none of the current core devs have the interest and/or
expertise to make the necessary calls as to what changes are needed
and how they should be made.

If we can broaden our developer base by giving people a specific place
to ease into things without having to dive straight into the deep end
of python-dev, then I think it's an experiment worth trying.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Ethan Furman]

On 3/25/2011 2:55 PM, Ben Finney wrote:

Guido van Rossum  writes:

On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney  wrote:

Surely a forum specifically for mentorship will be more useful if
outsiders can be directed to existing discussions, without needing to
join the private club.


This argument comes up repeatedly. Some people object on principle to
all closed lists.


No, I'm pointing out that a closed forum *for mentorship specifically*
is undermining the goal of mentorship: to efficiently share valuable
knowledge and help newbies learn from existing discussions with experts
and other newbies.


I disagree.  The goal of mentorship is to help someone learn -- a 
subtle, yet distinct, difference.  I think a closed list will suit that 
purpose better.


Keep in mind also that the list is *closed*, not *locked* -- anyone can 
join, and anyone who has joined has full access to current goings-on and 
to the archives.


~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Ethan Furman]

On 3/25/2011 8:23 PM, Nick Coghlan wrote:

On Sat, Mar 26, 2011 at 7:55 AM, Ben Finney  wrote:

One of the great things about a discussion forum open view for the
public is that, when a topic comes up again in a *different* forum, I
can easily point anyone to the existing discussion without requiring
that they join some private group. That's invaluable for spreading
knowledge freely.

If the goal of spreading knowledge isn't primary for the forum, I think
it's a bit misleading to call it mentorship. Sure, mentorship can still
be private; but it's pretty inefficient – and counter to the goal of
spreading knowledge – if only a private group gets to benefit from the
discussions.


And that's why I made sure to point out that any more widely
applicable information *will be incorporated into the devguide*.

So rather than pointing people to a potentially meandering discussion,
we'll be able to point them to a straightforward coherent answer,
without all the false starts and clarifications that happen in a real
mailing list conversation.


You mean like this one?  ;)

~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Let's get PEP 380 into Python 3.3

[Nick Coghlan]

On Sat, Mar 26, 2011 at 6:25 AM, rndblnch  wrote:
> The raw path is visible there:
> 
> and I have documented how to use it on the wiki:
> 
>
> I will stop spamming python-dev now...
> It was just an attempt to help getting pep380 in python3.3 :)

Thanks for your efforts - I created tracker issue #11682 and linked it
to your bitbucket repo to help keep track of this updated version.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Nick Coghlan]

On Sat, Mar 26, 2011 at 7:55 AM, Ben Finney  wrote:
> One of the great things about a discussion forum open view for the
> public is that, when a topic comes up again in a *different* forum, I
> can easily point anyone to the existing discussion without requiring
> that they join some private group. That's invaluable for spreading
> knowledge freely.
>
> If the goal of spreading knowledge isn't primary for the forum, I think
> it's a bit misleading to call it mentorship. Sure, mentorship can still
> be private; but it's pretty inefficient – and counter to the goal of
> spreading knowledge – if only a private group gets to benefit from the
> discussions.

And that's why I made sure to point out that any more widely
applicable information *will be incorporated into the devguide*.

So rather than pointing people to a potentially meandering discussion,
we'll be able to point them to a straightforward coherent answer,
without all the false starts and clarifications that happen in a real
mailing list conversation.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Benjamin Peterson]

2011/3/25 Glenn Linderman :
> So... start two mentoring groups, one open, one closed, and see which one
> survives.

This is all tangential to the actual point of this discussion: To help
people get involved! It's not a social experiment about mailing lists.

In fact, I think this thread can die about now. Honestly, if we spent
half the energy we spend worrying about mailing list details on actual
work



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Jesse Noller]

On Fri, Mar 25, 2011 at 9:59 PM, Glenn Linderman  wrote:
> So... start two mentoring groups, one open, one closed, and see which one
> survives.

I'd rather not. I'd rather walk away from the idea entirely. In fact,
this entire thread is quickly becoming an example of why people
*don't* want to bring issues to this list.

Jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Glenn Linderman]

So... start two mentoring groups, one open, one closed, and see which 
one survives.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Glenn Linderman]

On 3/25/2011 5:44 PM, Laura Creighton wrote:

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.


Indeed.  I see 76000+ unread messages on Python-list since I subscribed 
2.5 years ago.  I search it when I have a Python question, that is not 
immediately answerable by reading docs... issues of style mostly.  But 
that is mostly about how to use Python, not about how to contribute.  
And I don't have time to read it all.  I wonder if anyone reads it all, 
and gets anything else done in life.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mentorship list

[Jesse Noller]

On Mar 25, 2011, at 8:44 PM, Tommy  wrote:

> 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?
> 
That is a hope I would like to see realized. I don't think we will be changing 
the medium any time soon.

So, closed archives it stands for now. Please feel free to join.

Jesse___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Jesse Noller]

On Mar 25, 2011, at 8:14 PM, Laura Creighton  wrote:

> 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 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 oth

Re: [Python-Dev] Mentorship list

[Tommy]

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?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Laura Creighton]

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

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.3 release schedule posted

[Laurens Van Houtven]

On Thu, Mar 24, 2011 at 12:18 AM, Thomas Wouters  wrote:

> It ended up that Jim Fulton is actually writing the PEP (with input from
> Twisted people and others.)
>
> --
> Thomas Wouters 
>
> Hi! I'm a .signature virus! copy me into your .signature file to help me
> spread!
>
>
Well, if help is still needed I'll gladly chip in. It's not  that I'm not
interested in doing it -- it's just that I don't know who's supposed to or
who's working on it :)

-- 
cheers
lvh
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Laura Creighton]

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

Re: [Python-Dev] Python Core Mentorship program

[Ben Finney]

Eric Snow  writes:

> I see your point, but doesn't python-list already fill the role you
> indicate may be diminished?

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.

-- 
 \“Spam will be a thing of the past in two years' time.” —Bill |
  `\ Gates, 2004-01-24 |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Eric Snow]

I see your point, but doesn't python-list already fill the role you indicate
may be diminished?  Seems like the new list is meant to fill a different
need.  Perhaps one concern would be over-use of the mentoring list when
someone would be fine with python-list.  I just don't see people turning
away from python-list in favor of the mentoring list.

-eric

On Fri, Mar 25, 2011 at 4:47 PM, Ben Finney wrote:

> Jesse Noller  writes:
>
> > In principle I agree with you
> […]
>
> Thanks (truly!) for considering the feedback.
>
> The only further comment I need to make is:
>
> > 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.
>
> By the nature of the problem, I doubt it will be realised, since the
> problem is knowledge *not* getting to the right people. That's hardly
> something that will be observable nor measurable easily, certainly not
> within a few months.
>
> So, while I will be deprived of a clear “I told you so” response, that
> isn't something I'm much interested in anyway; on the other hand, the
> members of a closed forum won't be able to detect the problem easily and
> will likely not see the need to fix it.
>
> Anyway, good hunting in your endeavours. I hope you can encourage more
> people to quickly become confident enough to discuss their Python issues
> in public.
>
> --
>  \   德不孤、必有鄰。 (The virtuous are not abandoned, |
>  `\   they shall surely have neighbours.) |
> _o__) —孔夫子 Confucius, 551 BCE – 479 BCE |
> Ben Finney
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg diff

[Éric Araujo]

On 09.03.2011 06:44, "Martin v. Löwis" wrote:
> IMO, it's "hg diff --git" that's broken, as it doesn't include the base 
> revision (other formats, such as "hg export", do).

I asked about it on #mercurial.  It turns out that not including the
base changeset id in the diff is an oversight, not a choice; diffs made
by the git program actually contains a line of the form “index
694512d..e5fde8a“, so the Mercurial lead dev told me they would consider
accepting a patch making hg diff --git include such a line.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Éric Araujo]

> I see what happened: my revspec couldn't cope with the fact that you
> branched fix5845 off rlcompleter-config.
Ah, I hadn’t thought of that.  (I had to branch because of the former
issue with the hyphen; this is a pathological case.)

> In any case, I have now changed the revspec to use Baptiste's idea,
> which is really smart, which also allows me to drop the sourcebranch
> information.
> 
> Let's see whether it is correct this time.
It is!  (http://bugs.python.org/file21401/c43e264256e4.diff)  Thanks.

> I also added quotes into the branch name, so hyphens should be allowed now.
They are!  I changed the branch name back to the first name with an
hyphen and it successfully produced
http://bugs.python.org/file21402/d1cbf0347eb4.diff

Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Ben Finney]

Jesse Noller  writes:

> In principle I agree with you
[…]

Thanks (truly!) for considering the feedback.

The only further comment I need to make is:

> 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.

By the nature of the problem, I doubt it will be realised, since the
problem is knowledge *not* getting to the right people. That's hardly
something that will be observable nor measurable easily, certainly not
within a few months.

So, while I will be deprived of a clear “I told you so” response, that
isn't something I'm much interested in anyway; on the other hand, the
members of a closed forum won't be able to detect the problem easily and
will likely not see the need to fix it.

Anyway, good hunting in your endeavours. I hope you can encourage more
people to quickly become confident enough to discuss their Python issues
in public.

-- 
 \   德不孤、必有鄰。 (The virtuous are not abandoned, |
  `\   they shall surely have neighbours.) |
_o__) —孔夫子 Confucius, 551 BCE – 479 BCE |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Martin v. Löwis]

> I mean that my linked repo didn’t have all changesets from
> hg.python.org/cpython.  I don’t think it should matter, but I don’t know
> why the diff was empty, so I thought this information might help.
[...]
> See http://bugs.python.org/file21398/c43e264256e4.diff : this
> corresponds to a merge I did from default into my branch,
> http://hg.python.org/sandbox/merwok/rev/c43e264256e4 .  It should have
> been a diff corresponding to my branch - cpython’s main repo default
> branch head IIUC.

I see what happened: my revspec couldn't cope with the fact that you
branched fix5845 off rlcompleter-config. It was looking for the
branchpoint of that branch, and taking that as a potential base.
However, this didn't give a revision from default, but the latest
revision in rlcompleter-config as a candidate base.

It then compared that to the second parent of the latest merge into
fix5845, which was from the default branch, and tried to compute the
maximum. Since these two revisions are not ordered, max() returned
some junk revision (I don't understand what Mercurial does in this
case).

In any case, I have now changed the revspec to use Baptiste's idea,
which is really smart, which also allows me to drop the sourcebranch
information.

Let's see whether it is correct this time.

I also added quotes into the branch name, so hyphens should be allowed now.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Jesse Noller]

On Fri, Mar 25, 2011 at 5:55 PM, Ben Finney  wrote:
> Guido van Rossum  writes:
>
>> On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney  
>> wrote:
>> > Surely a forum specifically for mentorship will be more useful if
>> > outsiders can be directed to existing discussions, without needing to
>> > join the private club.
>>
>> This argument comes up repeatedly. Some people object on principle to
>> all closed lists.
>
> I apologise if anyone mistakes my position as that.
>
> Closed forums are necessary for all kinds of reasons. If my position
> were against all closed forums, people would be correct to regard that
> position as too extreme.
>
> No, I'm pointing out that a closed forum *for mentorship specifically*
> is undermining the goal of mentorship: to efficiently share valuable
> knowledge and help newbies learn from existing discussions with experts
> and other newbies.
>
> One of the great things about a discussion forum open view for the
> public is that, when a topic comes up again in a *different* forum, I
> can easily point anyone to the existing discussion without requiring
> that they join some private group. That's invaluable for spreading
> knowledge freely.

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 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.

"The perfect is the enemy of the good." :)

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Guido van Rossum]

On Fri, Mar 25, 2011 at 2:55 PM, Ben Finney  wrote:
>> I propose to give it a rest. If you want to know what's going on
>> there, just subscribe, nobody will stop you (and if they did there are
>> plenty of public forums to complain).
>
> I thought that's exactly what I was doing; confusingly, in this
> paragraph you seem to simultaneously suggest that I stop complaining
> when I see something wrong and that I should complain when I see
> something wrong.

You misunderstood me. I meant that if for some reason you would be
refused a subscription you should complain publicly.

Apart from that correction of a misunderstanding, I don't think we
need to go back and forth more on this. The folks taking the
initiative on the mentorship list have a certain kind of environment
in mind, they've heard your objection, they are going ahead with the
policy they set. Let's see how the experiment goes. We can always
create a new public list later (though we cannot open the archives of
the original closed list).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Ben Finney]

Guido van Rossum  writes:

> On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney  
> wrote:
> > Surely a forum specifically for mentorship will be more useful if
> > outsiders can be directed to existing discussions, without needing to
> > join the private club.
>
> This argument comes up repeatedly. Some people object on principle to
> all closed lists.

I apologise if anyone mistakes my position as that.

Closed forums are necessary for all kinds of reasons. If my position
were against all closed forums, people would be correct to regard that
position as too extreme.

No, I'm pointing out that a closed forum *for mentorship specifically*
is undermining the goal of mentorship: to efficiently share valuable
knowledge and help newbies learn from existing discussions with experts
and other newbies.

One of the great things about a discussion forum open view for the
public is that, when a topic comes up again in a *different* forum, I
can easily point anyone to the existing discussion without requiring
that they join some private group. That's invaluable for spreading
knowledge freely.

If the goal of spreading knowledge isn't primary for the forum, I think
it's a bit misleading to call it mentorship. Sure, mentorship can still
be private; but it's pretty inefficient – and counter to the goal of
spreading knowledge – if only a private group gets to benefit from the
discussions.

> Other people will not participate in a discussion (or will not speak
> their minds about certain topics) unless they have some sense that the
> list is "closed".

That's unfortunate, in my view, and I've stated the reasoning behind
this view. Others are, of course, entitled to their view, just as I'm
entitled to point out the flaws.

> I propose to give it a rest. If you want to know what's going on
> there, just subscribe, nobody will stop you (and if they did there are
> plenty of public forums to complain).

I thought that's exactly what I was doing; confusingly, in this
paragraph you seem to simultaneously suggest that I stop complaining
when I see something wrong and that I should complain when I see
something wrong.

I'm not requiring anyone change anything, only pointing out what I see
as a mistake.

> You will find soon enough that nothing unsavory is being discussed.

That was never the concern; I hope that's clear now.

-- 
 \“The problem with television is that the people must sit and |
  `\keep their eyes glued on a screen: the average American family |
_o__) hasn't time for it.” —_The New York Times_, 1939 |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg diff

[Éric Araujo]

Le 09/03/2011 03:41, Guido van Rossum a écrit :
> On Tue, Mar 8, 2011 at 9:32 PM, Éric Araujo  wrote:
>> I’m of the opinion that hg diffs should always use the extended git
>> format, given their usefulness.  A tool working with hg diffs that does
>> not support this format is broken IMO.
> 
> Can you please contribute changes to Rietveld to support that format then?

It looks like changes are not needed in Rietveld itself but to a
python.org-specific script:
http://svn.python.org/view/tracker/instances/python-dev/scripts/addpatchsets?view=markup

If you’re saying that stock Rietveld supports Mercurial and rejects diff
--git, I can certainly open a bug report upstream.

I don’t know if I’ll be able to set up a whole Roundup and Rietveld
development environment shortly, but if Martin can’t or doesn’t want to
write the fix, I will try to.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Éric Araujo]

> Make sure to submit issues to the meta tracker, please.

Right, I’ll do that.  Since you have questions in this message, for now
I’ll continue here.

>> - The first patch was empty (note that the repo was not up to date).
> This I don't understand. What repo was not up to date?

I mean that my linked repo didn’t have all changesets from
hg.python.org/cpython.  I don’t think it should matter, but I don’t know
why the diff was empty, so I thought this information might help.

>> - After pulling, merging and pushing, the patch created contained the
>> merge diff, not the useful diff with my changes.
> Again, please elaborate. What is the "merge diff" that it contained?

See http://bugs.python.org/file21398/c43e264256e4.diff : this
corresponds to a merge I did from default into my branch,
http://hg.python.org/sandbox/merwok/rev/c43e264256e4 .  It should have
been a diff corresponding to my branch - cpython’s main repo default
branch head IIUC.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Jesse Noller]

On Fri, Mar 25, 2011 at 5:16 PM, Guido van Rossum  wrote:
> On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney  
> wrote:
>> If you don't want a specific party snooping the site, just block that
>> specific party. Why make a walled garden that *nobody* outside can look
>> into? That undermines the free exchange of information.
>>
>> Surely a forum specifically for mentorship will be more useful if
>> outsiders can be directed to existing discussions, without needing to
>> join the private club.
>
> This argument comes up repeatedly. Some people object on principle to
> all closed lists. Other people will not participate in a discussion
> (or will not speak their minds about certain topics) unless they have
> some sense that the list is "closed". The former group will then argue
> that the closedness of the list is an illusion, that there are many
> ways to snoop on the list regardless. (And there are, technically
> speaking.) The latter group will still feel a different comfort level
> and argue that *socially* it is not the same thing at all.
>
> I propose to give it a rest. If you want to know what's going on
> there, just subscribe, nobody will stop you (and if they did there are
> plenty of public forums to complain). You will find soon enough that
> nothing unsavory is being discussed. There's an understanding that
> only people, not bots/indexers/etc., subscribe to the list, and that
> the members are not to forward/publish what they read outside the list
> without permission. That's enough to give group #2 the feeling of
> comfort (depending, always, on how the attitude of the members turns
> out to be of course) but it doesn't mean it's closed. There are other
> ways to publish information that might be useful for others, e.g.
> blogs, wikis, etc.
>
> --

+1 to what Guido and Jacob said. I know long time members of this list
uncomfortable with the prospect of bringing up anything on this
mailing list for various reasons. Given that, and my desire that we
provide a safe, friendly forum, biased towards the target audience
(newbies) versus those of us who are comfortable with public debate
and calcified attitudes, I'm pretty firm the archives stay "closed" to
only members.

Anyone, can of course, subscribe.

Jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Martin v. Löwis]

> Work has been started on that, thanks!  Roundup should soon support the
> workflow described in the devguide for feature work, which will be awesome.

Make sure to submit issues to the meta tracker, please.

> I’ve tried to use a clone with a named branch for
> http://bugs.python.org/issue5845 and found those bugs:
> - The revset code is not robust against an hyphen in the branch name.

Ok, I'll investigate. Not sure whether the revset syntax even supports
that, though.

> - The first patch was empty (note that the repo was not up to date).

This I don't understand. What repo was not up to date?

> - After pulling, merging and pushing, the patch created contained the
> merge diff, not the useful diff with my changes.

Again, please elaborate. What is the "merge diff" that it contained?

> Another thing to make it rock more: In the repo list, use “#” instead of
> “:” as a separator between repo URI and branch name; it’s standard
> Mercurial form and will allow people to copy-paste the whole thing to
> get a clone of the repo up to that branch.

Ok, committed.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting changes through Mercurial

[Éric Araujo]

Le 22/03/2011 22:47, Nick Coghlan a écrit :
> On Tue, Mar 22, 2011 at 10:53 PM, Éric Araujo  wrote:
>> You have to use one public repo per bug, as roundup will only use the
>> default branch to compute the diff.  Maybe adding support for named
>> branches so that you can have one repo used for many bug reports would
>> be useful.
> Since I run my sandbox that way, I asked Martin about that at Pycon -
> it's on his todo list for the integration.

Work has been started on that, thanks!  Roundup should soon support the
workflow described in the devguide for feature work, which will be awesome.

I’ve tried to use a clone with a named branch for
http://bugs.python.org/issue5845 and found those bugs:
- The revset code is not robust against an hyphen in the branch name.
- The first patch was empty (note that the repo was not up to date).
- After pulling, merging and pushing, the patch created contained the
merge diff, not the useful diff with my changes.

Another thing to make it rock more: In the repo list, use “#” instead of
“:” as a separator between repo URI and branch name; it’s standard
Mercurial form and will allow people to copy-paste the whole thing to
get a clone of the repo up to that branch.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Guido van Rossum]

On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney  wrote:
> If you don't want a specific party snooping the site, just block that
> specific party. Why make a walled garden that *nobody* outside can look
> into? That undermines the free exchange of information.
>
> Surely a forum specifically for mentorship will be more useful if
> outsiders can be directed to existing discussions, without needing to
> join the private club.

This argument comes up repeatedly. Some people object on principle to
all closed lists. Other people will not participate in a discussion
(or will not speak their minds about certain topics) unless they have
some sense that the list is "closed". The former group will then argue
that the closedness of the list is an illusion, that there are many
ways to snoop on the list regardless. (And there are, technically
speaking.) The latter group will still feel a different comfort level
and argue that *socially* it is not the same thing at all.

I propose to give it a rest. If you want to know what's going on
there, just subscribe, nobody will stop you (and if they did there are
plenty of public forums to complain). You will find soon enough that
nothing unsavory is being discussed. There's an understanding that
only people, not bots/indexers/etc., subscribe to the list, and that
the members are not to forward/publish what they read outside the list
without permission. That's enough to give group #2 the feeling of
comfort (depending, always, on how the attitude of the members turns
out to be of course) but it doesn't mean it's closed. There are other
ways to publish information that might be useful for others, e.g.
blogs, wikis, etc.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Jacob Kaplan-Moss]

On Fri, Mar 25, 2011 at 3:57 PM, Ben Finney  wrote:
> If you don't want a specific party snooping the site, just block that
> specific party. Why make a walled garden that *nobody* outside can look
> into? That undermines the free exchange of information.

I think the point is that most people aren't comfortable with their
fits, starts, and general n00bishness being published for the world to
see.

Heck, I've got a fairly thick skin but I'm not comfortable asking
stupid questions about compiling or patching Python here on
python-dev. I have trouble with the thought of my idiocy being part of
the public record. Doing things in private feels a lot more intimate
and comfortable.

But you know what? At the end of the day it doesn't matter. Arguments
about private versus public archives are like arguments about
reply-to: there's never going to be a "correct" answer. If this
proposed lists' archives are public I don't have to participate. If
they're private you don't have to participate. Let's just see where it
goes, eh?

Jacob
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Antoine Pitrou]

On Sat, 26 Mar 2011 07:57:41 +1100
Ben Finney  wrote:
> exar...@twistedmatrix.com writes:
> 
> > On 12:03 pm, jnol...@gmail.com wrote:
> > >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.
> >
> > Boggle.
> 
> Indeed, I share this sentiment.
> 
> If you don't want a specific party snooping the site, just block that
> specific party. Why make a walled garden that *nobody* outside can look
> into? That undermines the free exchange of information.
> 
> Surely a forum specifically for mentorship will be more useful if
> outsiders can be directed to existing discussions, without needing to
> join the private club.

+1


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Ben Finney]

exar...@twistedmatrix.com writes:

> On 12:03 pm, jnol...@gmail.com wrote:
> >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.
>
> Boggle.

Indeed, I share this sentiment.

If you don't want a specific party snooping the site, just block that
specific party. Why make a walled garden that *nobody* outside can look
into? That undermines the free exchange of information.

Surely a forum specifically for mentorship will be more useful if
outsiders can be directed to existing discussions, without needing to
join the private club.

-- 
 \“Odious ideas are not entitled to hide from criticism behind |
  `\  the human shield of their believers' feelings.” —Richard |
_o__) Stallman |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Let's get PEP 380 into Python 3.3

[rndblnch]

rndblnch  gmail.com> writes:
> Now that I have figured out how to use patch queues with bitbucket, I will
> maintain greg's pep380 implementation as a patch on top of cpython here:
> 

snip

> The patch is now visible here:
> 

There is a bug (acknowledged by bitbucket) preventing this page to display the
patch.
The error message is misleading, it states that the patch "pep380 did not apply
cleanly" but the problem is with bitbucket patching mechanism, not with the
patch.

The raw path is visible there:

and I have documented how to use it on the wiki:


I will stop spamming python-dev now...
It was just an attempt to help getting pep380 in python3.3 :)

renaud


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unload a module written in C

[Martin v. Löwis]

Am 25.03.2011 10:24, schrieb Stefan Behnel:
> "Martin v. Löwis", 25.03.2011 07:59:
>>> Is there a bug somewhere, or do I misunderstood something important?
>>
>> Module unloading is simply not implemented, and would be very difficult
>> to implement.
> 
> Are you saying that because objects instantiated from a module do not
> normally keep a reference to it to keep it alive?

No, I'm saying that there is no support whatsoever to unload the shared
library of the extension module when the extension module would no
longer be used.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2to3 status, repositories and HACKING guide

[Benjamin Peterson]

The main cpython repo.

2011/3/25 anatoly techtonik :
> Hi, Benjamin,
>
> Is your repository for 2to3 is still actual?
> http://svn.python.org/view/sandbox/trunk/2to3/
>
> Which should I use to start hacking on 2to3?
>
> --
> anatoly t.
>
>
>
> On Wed, Mar 23, 2011 at 9:01 AM, anatoly techtonik  
> wrote:
>> Hi,
>>
>> Currently 2to3 page at http://wiki.python.org/moin/2to3 lists
>> http://svn.python.org/view/sandbox/trunk/2to3 as a repository for 2to3
>> tool. There is also an outdated repository at http://hg.python.org/
>> and the page says that the code is finally integrated into CPython 2.6
>> - you can see it at
>> http://hg.python.org/cpython/file/default/Lib/lib2to3. So, what
>> version is more up-to-date?
>>
>> In svn repository there is a HACKING guide advising to use
>> find_pattern.py script for writing new fixer. However, there is no
>> find_pattern.py in CPython repository, no HACKING guide, no any
>> documentation about how to write fixers or description of PATTERN
>> format. Did I miss something?
>> --
>> anatoly t.
>>
>



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Reliable Domains]

On 3/25/2011 6:12 AM, s...@pobox.com wrote:

 >>  Boggle.

 Jesse>  I assume that means your in, or you hate that idea?

Or that he just really likes to play Boggle.:-)


I really like to play Boggle.  It is even better with our local rules... 
5x5 grid, 5 letter minimum word size, and 4 minute time limit.


But I like the idea of the mentorship, especially as I'm just looking to 
learn to contribute to Python.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python-Dev Digest, Vol 92, Issue 156

[Nick Efford]

On Fri, 25 Mar 2011, python-dev-requ...@python.org wrote:


Send Python-Dev mailing list submissions to
   python-dev@python.org

To subscribe or unsubscribe via the World Wide Web, visit
   http://mail.python.org/mailman/listinfo/python-dev
or, via email, send a message with subject or body 'help' to
   python-dev-requ...@python.org

You can reach the person managing the list at
   python-dev-ow...@python.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-Dev digest..."


Today's Topics:

  1. Re: sprints and pushes (Nick Coghlan)
  2. Re: Proposal for Python 3.3: dependence injection (Nick Coghlan)
  3. Re: Proposal for Python 3.3: dependence injection (Xavier Morel)
  4. Re: Proposal for Python 3.3: dependence injection (Nick Coghlan)
  5. Re: CRLF line endings (Nick Coghlan)
  6. Re: Unload a module written in C (Nick Coghlan)
  7. Re: Unload a module written in C (Victor Stinner)
  8. Re: [Python-checkins] cpython: Remove test_importable().
 Couldn't see how to make this reliable across all (Nick Coghlan)
  9. Re: Unload a module written in C (Nick Coghlan)
 10. Python Core Mentorship program (Jesse Noller)
 11. Re: CRLF line endings (Stefan Krah)
 12. Re: Python Core Mentorship program (Jesse Noller)


--

Message: 1
Date: Fri, 25 Mar 2011 21:00:25 +1000
From: Nick Coghlan 
To: "Stephen J. Turnbull" 
Cc: Tres Seaver , python-dev@python.org
Subject: Re: [Python-Dev] sprints and pushes
Message-ID:
   
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 25, 2011 at 12:51 PM, Stephen J. Turnbull
 wrote:

Eg, much as I normally respect Barry's intuitions, his proposal (to
remove costly tests, without reference to the possibility of missing
something important) is IMHO absolutely the wrong criterion. ?I don't
really know about Python's test suite, but in XEmacs the time-
expensive tests are mostly the ones that involve timeouts and lots of
system calls because they interact with the OS -- and those are
precisely the finicky areas where a small change can occasion an
unexpected bug. ?For XEmacs, those bugs also are more likely than
average to be showstoppers for dependents, in the sense that until
they're fixed, the dependents can't be tested at all. ?So the cost of
*not* running those tests is relatively high, too.


For Python, our most expensive, slow tests are generally process
related or IO related (over time the threading related ones have been
largely fixed to use Event based signalling rather than relying on
timeouts, so they're significantly faster than they once were).

These slow tests are *also* typically the most platform dependent
tests, so a "green light" from a local test run is generally pretty
inconclusive - you don't really find out whether you borked something
until you get green lights on the buildbots for platforms other than
those the patch was developed on.

So I still see value in having a standard "smoke test" that runs
through the platform independent stuff, to reduce the number of minor
errors that needlessly cause the buildbots to go red.

The idea would be to create a tiered test suite along the following lines:

1. The buildbots: run the entire (-uall) test suite across a variety
of platforms. Performed for every commit pushed to
hg.python.org/cpython.
2. Complete local test: run the entire (-uall) test suite on a local
working copy. Recommended before first committing a fix or change to a
branch.
3. Basic local test: run the test suite with no additional resources
enabled on a local working copy. Current closest equivalent to a
"smoke test"
4. Proposed "smoke test": quick test of platform independent code for
use when merging heads after a push race
5. Specific tests: run specified tests for modules being worked on.
Used during development to check fix validity and feature degree of
completion.

With the volume of platform dependent code we have in CPython and the
standard library, the only way we're ever likely to achieve
consistently green buildbots is to move to a "staging repo" model,
where commits only get made to the central repo after they have
already passed muster on the buildbots at least once. I think that's
actually a good way for us to go in the long run, but I also think
separating out a fast set of platform independent is a decent idea.

Cheers,
Nick.

--
Nick Coghlan?? |?? ncogh...@gmail.com?? |?? Brisbane, Australia


--

Message: 2
Date: Fri, 25 Mar 2011 21:04:17 +1000
From: Nick Coghlan 
To: Simon Cross 
Cc: Jesus Cea , Python DEV 
Subject: Re: [Python-Dev] Proposal for Python 3.3: dependence
   injection
Message-ID:
   
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 25, 2011 at 7:22 PM, Simon Cross
 wrote:

On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan  wrote:

As an example of the last point, perhaps rather than modifying all the
*clients* of the socket module, 

Re: [Python-Dev] Unload a module written in C

[Martin v. Löwis]

Am 25.03.2011 11:14, schrieb Victor Stinner:
> Le vendredi 25 mars 2011 à 07:59 +0100, "Martin v. Löwis" a écrit :
>>> Is there a bug somewhere, or do I misunderstood something important?
>>
>> Module unloading is simply not implemented, and would be very difficult
>> to implement.
> 
> My problem is that if Python is embeded, my module will still be active
> after Py_FinalizeEx(). 

Ah. If that's the case, it's a bug.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Revert the Lib/test/test_bigmem.py changes from commit 17891566a478 (and a

[Antoine Pitrou]

On Fri, 25 Mar 2011 17:44:26 +0100
Éric Araujo  wrote:
> Hi,
> 
> > changeset:   68921:11dc3f270594
> > user:Thomas Wouters 
> > date:Fri Mar 25 11:42:37 2011 +0100
> > summary:
> >   Revert the Lib/test/test_bigmem.py changes from commit 17891566a478 (and a
> > few other assertEqual tests that snuck in), and expand the docstrings and
> > comments explaining why and how these tests are supposed to work.
> 
> Your commit message does not explain why you reverted the changes.  The
> specific assert* methods give more useful messages than assertEqual in
> case of failure.

Because they don't go well with huge inputs?

>>> s = "x" * (2**29)
>>> case.assertEqual(s + "a", s + "b")
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 643,
in assertEqual assertion_func(first, second, msg=msg)
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 984,
in assertMultiLineEqual secondlines = [second + '\n']
MemoryError


(of course, the functions could just be fixed)


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

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:
  open2735 (+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 ConfigParser.write to write unicode strings
http://bugs.python.org/issue11597  opened by the_isz

#11598: missing afxres.h error when building bdist_wininst in Visual S
http://bugs.python.org/issue11598  opened by carljm

#11599: Useless error message when distutils fails compiling
http://bugs.python.org/issue11599  opened by pitrou

#11600: PY_CFLAGS and PY_CPPFLAGS inconsistent
http://bugs.python.org/issue11600  opened by pitrou

#11601: UnixCCompiler always uses compiler_so, not compiler
http://bugs.python.org/issue11601  opened by pitrou

#11602: python-config code should be in sysconfig
http://bugs.python.org/issue11602  opened by pitrou

#11603: Python crashes or hangs when rebinding __repr__ as __str__
http://bugs.python.org/issue11603  opened by aerojockey

#11604: Have type(n,b,d) check for type(b[i]) is module
http://bugs.python.org/issue11604  opened by terry.reedy

#11605: EMail generator.flatten() disintegrates over non-ascii multipa
http://bugs.python.org/issue11605  opened by sdaoden

#11607: Apllication crashes when saving file
http://bugs.python.org/issue11607  opened by roobman26

#11612: xml.dom.minidom fail to parse SVG file.
http://bugs.python.org/issue11612  opened by ideasman42

#11614: import __hello__ is broken in Python 3
http://bugs.python.org/issue11614  opened by haypo

#11617: Sporadic failure in test_httpservers
http://bugs.python.org/issue11617  opened by pitrou

#11618: Locks broken wrt timeouts on Windows
http://bugs.python.org/issue11618  opened by sbt

#11619: On Windows, don't encode filenames in the import machinery
http://bugs.python.org/issue11619  opened by haypo

#11620: winsound.PlaySound() with SND_MEMORY should accept bytes inste
http://bugs.python.org/issue11620  opened by Tom.Felker

#11623: Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
http://bugs.python.org/issue11623  opened by jlindenbaum

#11624: distutils should support a custom list of exported symbols for
http://bugs.python.org/issue11624  opened by dholth

#11626: Py_LIMITED_API on windows: unresolved symbol__imp___PyArg_Par
http://bugs.python.org/issue11626  opened by rjs

#11627: segfault raising an arbitrary object as an exception
http://bugs.python.org/issue11627  opened by michael.foord

#11629: Reference implementation for PEP 397
http://bugs.python.org/issue11629  opened by mhammond

#11631: Python 2.7.1 64bit, Win7 64bit problem to read and write with 
http://bugs.python.org/issue11631  opened by Kristoffer.Nilsson

#11632: difflib.unified_diff loses context
http://bugs.python.org/issue11632  opened by Brice.Videau

#11633: regression: print buffers output when end=''
http://bugs.python.org/issue11633  opened by techtonik

#11635: concurrent.futures uses polling
http://bugs.python.org/issue11635  opened by pitrou

#11637: Add cwd to sys.path for hooks
http://bugs.python.org/issue11637  opened by eric.araujo

#11638: pysetup un sdist crashes with weird trace if version is unicod
http://bugs.python.org/issue11638  opened by RonnyPfannschmidt

#11639: Documentation for *Config functions in logging module should b
http://bugs.python.org/issue11639  opened by santa4nt

#11640: Shelve references globals in its __del__ method
http://bugs.python.org/issue11640  opened by Peter.Davies

#11643: Use |version| instead of X.Y in the doc
http://bugs.python.org/issue11643  opened by eric.araujo

#11644: 2to3 documentation should mention that the sample file require
http://bugs.python.org/issue11644  opened by techtonik

#11645: "Expand 10 after" on rietveld shows a duplicate line
http://bugs.python.org/issue11645  opened by ubershmekel

#11646: 2to3: msvcrt.(get|put)ch -> (get|put)wch
http://bugs.python.org/issue11646  opened by techtonik

#11647: function decorated with a context manager can only be invoked 
http://bugs.python.org/issue11647  opened by pitrou

#11648: openlog()s 'logopt' keyword broken in syslog module
http://bugs.python.org/issue11648  opened by tbielawa

#11649: startElementNS in xml.sax.saxutils.XMLGenerator ignored encodi
http://bugs.python.org/issue11649  opened by gromgull

#11650: Faulty RESTART/EINTR handling in Parser/myreadline.c
http://bugs.python.org/issue11650  opened by sdaoden

#11651: Improve test targets in Makefile
http://bugs.python.org/issue11651  opened by pitrou

#11652: urlib{, 2} returns a pair of integers as the content-length va
http://bugs.python.org/issue11652  opened by Billy.Saelim

#11653: Problems with some tests using -j2
http://bugs.python.org/issue116

Re: [Python-Dev] [Python-checkins] cpython: Revert the Lib/test/test_bigmem.py changes from commit 17891566a478 (and a

[Éric Araujo]

Hi,

> changeset:   68921:11dc3f270594
> user:Thomas Wouters 
> date:Fri Mar 25 11:42:37 2011 +0100
> summary:
>   Revert the Lib/test/test_bigmem.py changes from commit 17891566a478 (and a
> few other assertEqual tests that snuck in), and expand the docstrings and
> comments explaining why and how these tests are supposed to work.

Your commit message does not explain why you reverted the changes.  The
specific assert* methods give more useful messages than assertEqual in
case of failure.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I plan to push faulthandler into Python 3.3 in one week

[Victor Stinner]

Le jeudi 24 mars 2011 à 00:49 +0100, Victor Stinner a écrit :
> If nobody complains, I plan to push my faulthandler module into Python
> 3.3 in one week. It's a module to display the Python backtrace on a
> segfault, on a user signal or after a timeout.

I created a feature repo to prepare the work, features/faulthandler, and
the integration is done. You can try it, or try the last patch attached
to #11393.

I choose to add faulthandler as a builtin module to be able to control
exactly when it is initialized/finalized.

You can enable it at startup using -X faulthandler=1 or
PYTHONFAULTHANDLER=1 env var.

Example:
--
$ ./python -X faulthandler Lib/test/crashers/borrowed_ref_2.py 
hi
Fatal Python error: Segmentation fault

Traceback (most recent call first):
  File "Lib/test/crashers/borrowed_ref_2.py", line 18 in __set__
  File "Lib/test/crashers/borrowed_ref_2.py", line 36 in 
Erreur de segmentation
--

Try Lib/test/crashers/recursive_call.py if you would like to try the
stack overflow feature: faulthandler is able to dump the traceback, even
after a stack overflow. But only if sigaltstack() is available (e.g. not
on Windows, sorry).

faulthandler can also dump the traceback explicitly, after a timeout, or
on a user signal: it is not specific to segmentation faults ;-)

Victor

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A myriad of cross-compile patches (Was: Re: Embedded Python startup is slow)

[Éric Araujo]

> I don't think Roumen is a core developer (is he? I am not trying to
> offend anyone).

My mistake.  Roumen is a user who’s been commenting on a number of the
patches.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dict access with double-dot (syntactic sugar)

[Éric Araujo]

Again, please keep this thread on python-ideas.  If people there agree
that this is a very common use case and find a syntax that is not ugly,
it will be time to come back to python-dev.  Thanks.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A myriad of cross-compile patches (Was: Re: Embedded Python startup is slow)

[Antoine Pitrou]

On Fri, 25 Mar 2011 16:46:51 +0100
Éric Araujo  wrote:
> 
> The most experienced core dev about those matters is Martin von Löwis;
> other core devs who make reviews are Roumen Petrov and Gregory P. Smith
> (who’s recently been removing his name from nosy fields).

I don't think Roumen is a core developer (is he? I am not trying to
offend anyone).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sprints and pushes

[Barry Warsaw]

On Mar 25, 2011, at 09:51 AM, Tres Seaver wrote:

>That was precisely my proposal:  when trying to check in changes to a
>stdlib module, we required that developers ensure that the module's
>tests, *and* those of its dependents, pass.  We would need to add new
>testing infrastructure to support this expectation by computing (and
>saving) the dependency graph of the stdlib.  I originally suggested
>build time for this, but now think that it would better be built during
>an intial full run of the suite.

That does seem to be a more fruitful avenue for improvement.

I'm also doing more investigation into exactly why certain tests are much
slower for me than for other people.  The main culprit appears to be the fact
that my $HOME is on an ecryptfs, so some performance hit is expected.  But 600
to 25000 times slower?  Hmm...

Also, something seems to be not working quite right with regrtest's cd'ing to
/tmp.  When I build and run the tests out of /tmp (i.e. a non-ecryptfs) with
-j100 it completes in under 3 minutes.  Hopefully I can investigate more later
today.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dict access with double-dot (syntactic sugar)

[Jameson Quinn]

I realized that python already has a way to access the string-based members
of a dict without using quotes:

def expect_a_chair(chair, **kw):
  print "Thanks. That chair is %s." % chair
  if kw:
for key, val in kw.iteritems():
  print "I wasn't expecting the (%s) %s!" % (val, key)

d = json.loads('{"chair":"comfy","inquisition":"Spanish"}')
expect_a_chair(**d)
try:
  expect_a_chair({})
except TypeError:
  print "No chair."

The ** operator does this. Notice that nowhere in that python code (not
counting the json) do I have to put "chair" in quotes.

Honestly, this solves my current use case. I can use functions like
expect_a_chair for everything I need right now.

But perhaps, if there were a quote-free way to access string-based dict
items, it should be based on this. The problem is, this ** operator is a
unary operator, and the non-unary ** is already taken.

So, I don't have a perfect name for my proposed quoteless synonym for
'["..."]'. My best option is '*.'. Note that this could also be used for
unpacking, and with defaults:
d*.(x,y,z) #=== (d["x"], d["y"], d['z'])
e=d*.(e=None) #like 'e=d.get("e", None)'.

Does this sound worth-it to anyone?

Jameson
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] A myriad of cross-compile patches (Was: Re: Embedded Python startup is slow)

[Éric Araujo]

Le 25/03/2011 11:48, Victor Stinner a écrit :
> I proposed to integrate Buildroot patches which are 12 patches to
> improve cross-compilation and remove/disable some Python features:
> http://bugs.python.org/issue11365
> 
> Roumen Petrov wrote "All is duplicate on already posted patches . It is
> not work to review limited functionality posted here." But I don't know
> the number of the issues cited by Roumen.

Courtesy of Roundup’s search:

Open issues
===

http://bugs.python.org/issue3754
  cross-compilation support for python build

http://bugs.python.org/issue1006238
  cross compile patch

http://bugs.python.org/issue1597850
  Cross compiling patches for MINGW (superseder of
  http://bugs.python.org/issue1339673, cross compile and mingw support)

http://bugs.python.org/issue3871
  cross and native build of python for mingw32 with distutils

http://bugs.python.org/issue3718
  environment variable MACHDEP and python build system

http://bugs.python.org/issue10782
  Not possible to cross-compile due to poor detection of %lld support
  in printf

Solved issues
=

http://bugs.python.org/issue433537
  better cross-compilation support

http://bugs.python.org/issue2513
  64bit cross compilation on windows

http://bugs.python.org/issue1115
  Minor Change For Better cross compile

Those overlapping bugs encompass 10 to 15 users interested in
cross-compilation, but not always in understanding CPython policy (i.e.
targeting 3.3 and packaging, not distutils in 2.6) or politeness .
 See also http://kegel.com/crosstool/python.html and
http://mail.python.org/pipermail/distutils-sig/2004-October/004209.html
Some patches modify the configure script, other the Windows project
thing files, and the more pervasive make changes in distutils.

The most experienced core dev about those matters is Martin von Löwis;
other core devs who make reviews are Roumen Petrov and Gregory P. Smith
(who’s recently been removing his name from nosy fields).  Mark Hammond,
Thomas Heller and Trent Nelson have knowledge on cross-compilation on
Windows.

Hope this helps.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Buildbots and feature branches

[Antoine Pitrou]

On Fri, 25 Mar 2011 16:11:16 +0100
Éric Araujo  wrote:
> Le 25/03/2011 15:58, Stefan Krah a écrit :
> > Incidentally, I noticed that push messages with an issue number get
> > redirected to bugs.python.org. See the recent commit for #2650 here:
> > 
> > http://hg.python.org/cpython/ 
> > 
> > 
> > Is this really what everyone wants?
> 
> Having issues linked from commit messages on changeset pages (like
> http://hg.python.org/cpython/rev/d52b1faa7b11) is very useful IMO;
> however, having those links disable the usual links to the changeset
> pages on the main log page (http://hg.python.org/cpython/) is a bug.  If
> nobody can fix it quickly, I’ll try to make a patch in a week or two.

See http://mercurial.selenic.com/bts/issue698 for a related issue
(the patch there may be reusable in order to disable these links in the
log view).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Buildbots and feature branches

[Éric Araujo]

Le 25/03/2011 15:58, Stefan Krah a écrit :
> Incidentally, I noticed that push messages with an issue number get
> redirected to bugs.python.org. See the recent commit for #2650 here:
> 
> http://hg.python.org/cpython/ 
> 
> 
> Is this really what everyone wants?

Having issues linked from commit messages on changeset pages (like
http://hg.python.org/cpython/rev/d52b1faa7b11) is very useful IMO;
however, having those links disable the usual links to the changeset
pages on the main log page (http://hg.python.org/cpython/) is a bug.  If
nobody can fix it quickly, I’ll try to make a patch in a week or two.

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Buildbots and feature branches

[Stefan Krah]

Antoine Pitrou  wrote:
> > I'm unable to figure out how to trigger a build of a feature branch, see:
> 
> You cannot do that yet.

Ok, thanks.


Incidentally, I noticed that push messages with an issue number get
redirected to bugs.python.org. See the recent commit for #2650 here:

http://hg.python.org/cpython/ 


Is this really what everyone wants? I think there's way too much
information on the tracker if you just want to see what actually
got committed.



Stefan Krah



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Buildbots and feature branches

[Antoine Pitrou]

On Fri, 25 Mar 2011 15:30:37 +0100
Stefan Krah  wrote:
> Hi,
> 
> I'm unable to figure out how to trigger a build of a feature branch, see:

You cannot do that yet.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Éric Araujo]

Hi,

Sounds like an excellent initiative!  Kudos to the PSF and the
individuals involved.  I don’t have time to take part right now, but I
wish a good start to the program.

Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Buildbots and feature branches

[Stefan Krah]

Hi,

I'm unable to figure out how to trigger a build of a feature branch, see:

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/3424


I saw this:

'Branch to build' is relative to http://svn.python.org/projects/python.



But if I leave out the branch, nothing happens at all.



Stefan Krah


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Tarek Ziadé]

On Fri, Mar 25, 2011 at 2:12 PM,   wrote:
>
>    >> Boggle.
>
>    Jesse> I assume that means your in, or you hate that idea?
>
> Or that he just really likes to play Boggle. :-)
>

Or that he's confused ?
https://secure.wikimedia.org/wiktionary/en/wiki/mindboggling

> S
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>



-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal for Python 3.3: dependence injection

[Nick Coghlan]

On Fri, Mar 25, 2011 at 11:29 PM, Antoine Pitrou  wrote:
>> My model for the suggestion is the context objects in the decimal
>> module. They offer a constrained way to affect the way the entire
>> decimal module goes about its business, and through judicious use of
>> thread local storage and context managers, allow this to be done
>> without distorting the public API of the decimal objects themselves.
>
> Making an API TLS-based means your code breaks mysteriously if you
> start offloading tasks to separate threads (which is quite common with
> network-related tasks).

Ah, true - and, as you say, libraries are far more likely to farm
networking operations out to threads than they are decimal
calculations. Such situations also cause problems for any approaches
based on temporary monkey-patching.

Still, exploring such ideas and their downsides would be one of the
purposes of writing a PEP on this topic. Sprinkling factory function
pixie dust everywhere may turn out to be the right thing to do, but
the various options should be explored before settling specifically on
that one.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Brian Curtin]

On Fri, Mar 25, 2011 at 08:26, Nick Coghlan  wrote:
>
> One other thing I would hope to be able to do with the list is to try
> to stay in touch with new contributors that participate in sprints.
>
> Cheers,
> Nick.


This was exactly my thought. We were there in person to get ~10 PyCon
sprinters through through the initial hurdles, but what can we do moving
forward? This list answers that question.

A lot have suggested that we follow-up with the people who came out, and an
introduction/invite to this mailing-list seems like a good first contact.
I'll keep them in mind.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[exarkun]

On 12:03 pm, jnol...@gmail.com wrote:

Hello everyone:


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.


Boggle.

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Jesse Noller]

On Fri, Mar 25, 2011 at 8:03 AM, Jesse Noller  wrote:
> 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
> 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-mentors...@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
> (jnol...@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
>

And the mailing list is up and running for those of you interested in helping:

http://mail.python.org/mailman/listinfo/core-mentorship

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sprints and pushes

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/24/2011 10:51 PM, Stephen J. Turnbull wrote:

> If you are going to argue
> for running some tests but not others after making changes, shouldn't
> there be a notion of relevance involved?  IMO "the" tests for modules
> with dependents should include the tests for their dependents, for
> example.  Modules that are leaves in the dependency tree presumably
> can be unit tested and leave it at that.

That was precisely my proposal:  when trying to check in changes to a
stdlib module, we required that developers ensure that the module's
tests, *and* those of its dependents, pass.  We would need to add new
testing infrastructure to support this expectation by computing (and
saving) the dependency graph of the stdlib.  I originally suggested
build time for this, but now think that it would better be built during
an intial full run of the suite.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2MncgACgkQ+gerLs4ltQ5WWwCfZVNtfIsPZWx6o5fC08Dh+JHV
EKsAn19jQ//9TGLhMs0yCiY5zDBXNEoD
=VVCq
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] CRLF line endings

[Antoine Pitrou]

On Fri, 25 Mar 2011 09:12:53 -0400
"R. David Murray"  wrote:
> On Fri, 25 Mar 2011 21:12:19 +1000, Nick Coghlan  wrote:
> > Don't disable the commit hook, update .hgeol to flag that file as
> > requiring CRLF line endings.
> 
> Note however that we discovered that the server side hook looks at the
> .hgeol file in the *server's checkout*.  I don't know if Georg or Antoine
> have fixed this or not (it's a standard Mercurial plugin, so probably
> not).

We have "fixed" it by nulling the server's checkout (updating to it to
changeset 00, that is). Unless someone logs in and manually
does "hg up" in that directory, it shouldn't happen again.

(but, yes, it's probably a bug or misfeature in hgeol)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Jesse Noller]

On Fri, Mar 25, 2011 at 9:26 AM, Nick Coghlan  wrote:
> On Fri, Mar 25, 2011 at 11:06 PM, Jesse Noller  wrote:
>> On Fri, Mar 25, 2011 at 9:04 AM,   wrote:
>>> On 12:03 pm, jnol...@gmail.com wrote:

 Hello everyone:


 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.
>>>
>>> Boggle.
>>
>> I assume that means your in, or you hate that idea?
>
> I'll note that one thing the mentors on that list will be doing is
> using the questions received as an indication of areas where the
> devguide and FAQ may need possible tweaks.
>
> One other thing I would hope to be able to do with the list is to try
> to stay in touch with new contributors that participate in sprints.
>
> Cheers,
> Nick.

Violently agreed on both counts.

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal for Python 3.3: dependence injection

[Antoine Pitrou]

On Fri, 25 Mar 2011 21:10:08 +1000
Nick Coghlan  wrote:
> On Fri, Mar 25, 2011 at 12:22 PM, Glenn Linderman  
> wrote:
> > On 3/24/2011 4:25 PM, Nick Coghlan wrote:
> >
> > As an example of the last point, perhaps rather than modifying all the
> > *clients* of the socket module, it may make more sense to have tools
> > in the socket module itself to temporarily customise the socket
> > creation process in the current thread. The advantage of such an
> > approach is that it would then work for 3rd party libraries that
> > create sockets, without requiring any further modification.
> >
> > Would be easier to implement that way, not requiring changes to every client
> > of the socket library, but in some circles that would be called "action at a
> > distance", and harder to understand.
> 
> Oh, it is definitely action at a distance, and quite deliberately so.
> 
> My model for the suggestion is the context objects in the decimal
> module. They offer a constrained way to affect the way the entire
> decimal module goes about its business, and through judicious use of
> thread local storage and context managers, allow this to be done
> without distorting the public API of the decimal objects themselves.

Making an API TLS-based means your code breaks mysteriously if you
start offloading tasks to separate threads (which is quite common with
network-related tasks).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Nick Coghlan]

On Fri, Mar 25, 2011 at 11:06 PM, Jesse Noller  wrote:
> On Fri, Mar 25, 2011 at 9:04 AM,   wrote:
>> On 12:03 pm, jnol...@gmail.com wrote:
>>>
>>> Hello everyone:
>>>
>>>
>>> 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.
>>
>> Boggle.
>
> I assume that means your in, or you hate that idea?

I'll note that one thing the mentors on that list will be doing is
using the questions received as an indication of areas where the
devguide and FAQ may need possible tweaks.

One other thing I would hope to be able to do with the list is to try
to stay in touch with new contributors that participate in sprints.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] CRLF line endings

[Nick Coghlan]

On Fri, Mar 25, 2011 at 11:12 PM, R. David Murray  wrote:
> On Fri, 25 Mar 2011 21:12:19 +1000, Nick Coghlan  wrote:
>> Don't disable the commit hook, update .hgeol to flag that file as
>> requiring CRLF line endings.
>
> Note however that we discovered that the server side hook looks at the
> .hgeol file in the *server's checkout*.  I don't know if Georg or Antoine
> have fixed this or not (it's a standard Mercurial plugin, so probably
> not).

Not that I noticed - to get my sandbox updated after you moved all the
email test files, I just had to one do push to get the .hgeol file
updated, then the second push with all the subsequent changes went
through without any trouble.

The one thing you can't do is push an updated .hgeol *and* files that
depend on the updated ruleset in one operation - the server will
process the whole transaction using the *old* version of the .hgeol
file and it will fail as a result. But "hg log .hgeol" will tell you
which version last changed it, then a "hg push -r " will get the
server's version updated.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] CRLF line endings

[R. David Murray]

On Fri, 25 Mar 2011 21:12:19 +1000, Nick Coghlan  wrote:
> Don't disable the commit hook, update .hgeol to flag that file as
> requiring CRLF line endings.

Note however that we discovered that the server side hook looks at the
.hgeol file in the *server's checkout*.  I don't know if Georg or Antoine
have fixed this or not (it's a standard Mercurial plugin, so probably
not).

So, I think that once you check in the .hgeol, you have to get a server
admin to update the repo checkout on the server.  Maybe we should
set up a cron job.

But, yeah, updating .hgeol is the correct solution, otherwise you'll
just run in to the trouble when you try to merge the branch into default.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[skip]

>> Boggle.

Jesse> I assume that means your in, or you hate that idea?

Or that he just really likes to play Boggle. :-)

S
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Core Mentorship program

[Jesse Noller]

On Fri, Mar 25, 2011 at 9:04 AM,   wrote:
> On 12:03 pm, jnol...@gmail.com wrote:
>>
>> Hello everyone:
>>
>>
>> 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.
>
> Boggle.
>
> Jean-Paul
>

I assume that means your in, or you hate that idea?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] CRLF line endings

[Stefan Krah]

Nick Coghlan  wrote:
> > However, dnloop.patch is correct and must have CRLF line endings. How
> > can I disable the commit hook?
> 
> Don't disable the commit hook, update .hgeol to flag that file as
> requiring CRLF line endings.

Thanks, that works well.


Stefan Krah


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python Core Mentorship program

[Jesse Noller]

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
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-mentors...@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
(jnol...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unload a module written in C

[Nick Coghlan]

On Fri, Mar 25, 2011 at 9:36 PM, Victor Stinner
 wrote:
>> And registering your cleanup function with atexit() isn't enough? Or
>> does that remove the handler too early?
>
> atexit() is too late: when Python is embeded, Py_Finalize() may be
> called a long time before the program does really finish.

I'm talking about the Python "atexit" module - any callbacks
registered there are invoked by Py_Finalize(), not by process
termination.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Remove test_importable(). Couldn't see how to make this reliable across all

[Nick Coghlan]

On Fri, Mar 25, 2011 at 3:51 AM, raymond.hettinger
 wrote:
> http://hg.python.org/cpython/rev/5adddc6be3c1
> changeset:   68902:5adddc6be3c1
> user:        Raymond Hettinger 
> date:        Thu Mar 24 10:51:06 2011 -0700
> summary:
>  Remove test_importable().  Couldn't see how to make this reliable across all 
> platforms.

For this particular use case, a temporary directory added to sys,path,
then some subsequent cleanup of sys.modules, sys.path and
sys.path_importer_cache would likely do the trick.

I've actually never been a fan of using TESTFN in tests - the tempfile
module always struck me as being significantly more useful. It also
makes tidying up the files afterwards really easy - the temporary
directory context manager will blow everything away for you.

Then again, quite a few of the tests I've written involved convoluted
module hierarchies, so I'm likely a little biased by my typical use
cases :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unload a module written in C

[Victor Stinner]

Le vendredi 25 mars 2011 à 21:14 +1000, Nick Coghlan a écrit :
> On Fri, Mar 25, 2011 at 8:14 PM, Victor Stinner
>  wrote:
> > Le vendredi 25 mars 2011 à 07:59 +0100, "Martin v. Löwis" a écrit :
> >> > Is there a bug somewhere, or do I misunderstood something important?
> >>
> >> Module unloading is simply not implemented, and would be very difficult
> >> to implement.
> >
> > My problem is that if Python is embeded, my module will still be active
> > after Py_FinalizeEx(). For example, if it installed an handler for the
> > SIGSEGV signal: a segmentation fault will call the handler which will
> > try to get the interpreter state, but there is no more interpreter. I
> > don't know if it is a problem or not, but I would prefer to cleanup my
> > module on Py_FinalizeEx().
> 
> And registering your cleanup function with atexit() isn't enough? Or
> does that remove the handler too early?

atexit() is too late: when Python is embeded, Py_Finalize() may be
called a long time before the program does really finish.

Well, I never embeded Python in another program, but it looks like some
people do initialize/finalize Python more than once:

http://bugs.python.org/issue11321
"9th import of module _pickle always crashes"

In this issue, Python is initialized/finalized 20 times.

Victor

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unload a module written in C

[Nick Coghlan]

On Fri, Mar 25, 2011 at 8:14 PM, Victor Stinner
 wrote:
> Le vendredi 25 mars 2011 à 07:59 +0100, "Martin v. Löwis" a écrit :
>> > Is there a bug somewhere, or do I misunderstood something important?
>>
>> Module unloading is simply not implemented, and would be very difficult
>> to implement.
>
> My problem is that if Python is embeded, my module will still be active
> after Py_FinalizeEx(). For example, if it installed an handler for the
> SIGSEGV signal: a segmentation fault will call the handler which will
> try to get the interpreter state, but there is no more interpreter. I
> don't know if it is a problem or not, but I would prefer to cleanup my
> module on Py_FinalizeEx().

And registering your cleanup function with atexit() isn't enough? Or
does that remove the handler too early?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] CRLF line endings

[Nick Coghlan]

On Fri, Mar 25, 2011 at 7:36 PM, Stefan Krah  wrote:
> Hi,
>
> A commit hook prevented pushing changes to the cdecimal repository:
>
> pushing to ssh://h...@hg.python.org/features/cdecimal
> searching for changes
> 8 changesets found
> remote: adding changesets
> remote: adding manifests
> remote: adding file changes
> remote: added 8 changesets with 117 changes to 117 files
> remote: error: pretxnchangegroup.eol hook failed: 
> Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not have CRLF line 
> endings
> remote: transaction abort!
> remote: rollback completed
> remote: abort: Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not 
> have CRLF line endings
>
>
> However, dnloop.patch is correct and must have CRLF line endings. How
> can I disable the commit hook?

Don't disable the commit hook, update .hgeol to flag that file as
requiring CRLF line endings.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal for Python 3.3: dependence injection

[Nick Coghlan]

On Fri, Mar 25, 2011 at 12:22 PM, Glenn Linderman  wrote:
> On 3/24/2011 4:25 PM, Nick Coghlan wrote:
>
> As an example of the last point, perhaps rather than modifying all the
> *clients* of the socket module, it may make more sense to have tools
> in the socket module itself to temporarily customise the socket
> creation process in the current thread. The advantage of such an
> approach is that it would then work for 3rd party libraries that
> create sockets, without requiring any further modification.
>
> Would be easier to implement that way, not requiring changes to every client
> of the socket library, but in some circles that would be called "action at a
> distance", and harder to understand.

Oh, it is definitely action at a distance, and quite deliberately so.

My model for the suggestion is the context objects in the decimal
module. They offer a constrained way to affect the way the entire
decimal module goes about its business, and through judicious use of
thread local storage and context managers, allow this to be done
without distorting the public API of the decimal objects themselves.

There's no reason a solution along those lines wouldn't work for the
socket module, or any other API that would similarly benefit from
providing a mechanism for applications to indirectly control library
behaviour without resorting to monkey-patching.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal for Python 3.3: dependence injection

[Xavier Morel]

On 2011-03-25, at 10:22 , Simon Cross wrote:
> On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan  wrote:
>> As an example of the last point, perhaps rather than modifying all the
>> *clients* of the socket module, it may make more sense to have tools
>> in the socket module itself to temporarily customise the socket
>> creation process in the current thread. The advantage of such an
>> approach is that it would then work for 3rd party libraries that
>> create sockets, without requiring any further modification.
> 
> -2.  That wouldn't allow one to use normal sockets in one 3rd party
> library and special sockets in another 3rd party library.
> 
> Schiavo
> Simon

Or even in "first-party" code (in the stdlib) to set different timeouts on 
different APIs (say, an xmlrpclib.ServerProxy and an IMAP4 client).

For instance, currently as far as I can tell setting a socket timeout on an 
xmlrpclib.ServerProxy without setting a global timeout involves:

* subclassing all of xmlrpclib.Serverproxy, xmlrpclib.Transport, httplib.HTTP 
and httplib.HTTPConnection
* overloading __init__ on the ServerProxy subclass (and on Transport if the 
timeout is to be a parameter)
* overloading make_connection on the Transport subclass (in order to use the 
HTTP subclass and propagate the timeout)
* overloading _connection_class on the HTTP subclass
* overloading connect on the HTTPConnection class

This *could* be solved by wrapping a socket-related thread-local context 
manager around each call resulting in the creation of a socket, but these call 
sites may not even be under control.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal for Python 3.3: dependence injection

[Nick Coghlan]

On Fri, Mar 25, 2011 at 7:22 PM, Simon Cross
 wrote:
> On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan  wrote:
>> As an example of the last point, perhaps rather than modifying all the
>> *clients* of the socket module, it may make more sense to have tools
>> in the socket module itself to temporarily customise the socket
>> creation process in the current thread. The advantage of such an
>> approach is that it would then work for 3rd party libraries that
>> create sockets, without requiring any further modification.
>
> -2.  That wouldn't allow one to use normal sockets in one 3rd party
> library and special sockets in another 3rd party library.

Uh, yes it would. One possible implementation is to use exactly the
same techniques that are used to implement contexts in the decimal
module.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sprints and pushes

[Nick Coghlan]

On Fri, Mar 25, 2011 at 12:51 PM, Stephen J. Turnbull
 wrote:
> Eg, much as I normally respect Barry's intuitions, his proposal (to
> remove costly tests, without reference to the possibility of missing
> something important) is IMHO absolutely the wrong criterion.  I don't
> really know about Python's test suite, but in XEmacs the time-
> expensive tests are mostly the ones that involve timeouts and lots of
> system calls because they interact with the OS -- and those are
> precisely the finicky areas where a small change can occasion an
> unexpected bug.  For XEmacs, those bugs also are more likely than
> average to be showstoppers for dependents, in the sense that until
> they're fixed, the dependents can't be tested at all.  So the cost of
> *not* running those tests is relatively high, too.

For Python, our most expensive, slow tests are generally process
related or IO related (over time the threading related ones have been
largely fixed to use Event based signalling rather than relying on
timeouts, so they're significantly faster than they once were).

These slow tests are *also* typically the most platform dependent
tests, so a "green light" from a local test run is generally pretty
inconclusive - you don't really find out whether you borked something
until you get green lights on the buildbots for platforms other than
those the patch was developed on.

So I still see value in having a standard "smoke test" that runs
through the platform independent stuff, to reduce the number of minor
errors that needlessly cause the buildbots to go red.

The idea would be to create a tiered test suite along the following lines:

1. The buildbots: run the entire (-uall) test suite across a variety
of platforms. Performed for every commit pushed to
hg.python.org/cpython.
2. Complete local test: run the entire (-uall) test suite on a local
working copy. Recommended before first committing a fix or change to a
branch.
3. Basic local test: run the test suite with no additional resources
enabled on a local working copy. Current closest equivalent to a
"smoke test"
4. Proposed "smoke test": quick test of platform independent code for
use when merging heads after a push race
5. Specific tests: run specified tests for modules being worked on.
Used during development to check fix validity and feature degree of
completion.

With the volume of platform dependent code we have in CPython and the
standard library, the only way we're ever likely to achieve
consistently green buildbots is to move to a "staging repo" model,
where commits only get made to the central repo after they have
already passed muster on the buildbots at least once. I think that's
actually a good way for us to go in the long run, but I also think
separating out a fast set of platform independent is a decent idea.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Embedded Python startup is slow

[Victor Stinner]

Le jeudi 24 mars 2011 à 22:40 -0400, R. David Murray a écrit :
> On Fri, 25 Mar 2011 01:20:34 +0100, Paul Boddie  wrote:
> > Since this topic has come up a few times before, I thought it might be time 
> > to 
> > collect references to it as well as to other topics that people doing 
> > embedded work might be interested in, along with the recurring problems 
> > that 
> > seem to get solved, probably all too frequently from scratch, outside the 
> > CPython development scene. (Just looking at an average cross-compilation 
> > issue in the tracker is likely to fill you with despair if you're waiting 
> > for 
> > a resolution in the official releases, unfortunately.)
> 
> Personally I think it would be a good thing for CPython to better support
> both embedded systems and cross compilation in general.  I think that
> many improvements that would make it better for embedded use would
> also make it better for general use (such as improved startup time).
> I also think we have a dearth of active core committers with experience
> in cross compilation.

I proposed to integrate Buildroot patches which are 12 patches to
improve cross-compilation and remove/disable some Python features:
http://bugs.python.org/issue11365

Roumen Petrov wrote "All is duplicate on already posted patches . It is
not work to review limited functionality posted here." But I don't know
the number of the issues cited by Roumen.

Victor


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unload a module written in C

[Victor Stinner]

Le vendredi 25 mars 2011 à 07:59 +0100, "Martin v. Löwis" a écrit :
> > Is there a bug somewhere, or do I misunderstood something important?
> 
> Module unloading is simply not implemented, and would be very difficult
> to implement.

My problem is that if Python is embeded, my module will still be active
after Py_FinalizeEx(). For example, if it installed an handler for the
SIGSEGV signal: a segmentation fault will call the handler which will
try to get the interpreter state, but there is no more interpreter. I
don't know if it is a problem or not, but I would prefer to cleanup my
module on Py_FinalizeEx().

I can try to ensure that Python does restore all signals installed by
faulthandler and cancel the current alarm() (used by
dump_traceback_later()). Or I can hardcode something to unload
faulthandler in Py_FinalizeEx() (or somewhere else).

Victor

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2to3 status, repositories and HACKING guide

[anatoly techtonik]

Hi, Benjamin,

Is your repository for 2to3 is still actual?
http://svn.python.org/view/sandbox/trunk/2to3/

Which should I use to start hacking on 2to3?

--
anatoly t.



On Wed, Mar 23, 2011 at 9:01 AM, anatoly techtonik  wrote:
> Hi,
>
> Currently 2to3 page at http://wiki.python.org/moin/2to3 lists
> http://svn.python.org/view/sandbox/trunk/2to3 as a repository for 2to3
> tool. There is also an outdated repository at http://hg.python.org/
> and the page says that the code is finally integrated into CPython 2.6
> - you can see it at
> http://hg.python.org/cpython/file/default/Lib/lib2to3. So, what
> version is more up-to-date?
>
> In svn repository there is a HACKING guide advising to use
> find_pattern.py script for writing new fixer. However, there is no
> find_pattern.py in CPython repository, no HACKING guide, no any
> documentation about how to write fixers or description of PATTERN
> format. Did I miss something?
> --
> anatoly t.
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unload a module written in C

[Victor Stinner]

Le vendredi 25 mars 2011 à 10:24 +0100, Stefan Behnel a écrit :
> "Martin v. Löwis", 25.03.2011 07:59:
> >> Is there a bug somewhere, or do I misunderstood something important?
> >
> > Module unloading is simply not implemented, and would be very difficult
> > to implement.
> 
> Are you saying that because objects instantiated from a module do not 
> normally keep a reference to it to keep it alive?

If you are right, I can understand that it is not possible to unload
safely a module.  In my case, faulthandler module doesn't create an
object, and it has a function to unload itself safely.

Victor

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] CRLF line endings

[Stefan Krah]

Hi,

A commit hook prevented pushing changes to the cdecimal repository:

pushing to ssh://h...@hg.python.org/features/cdecimal
searching for changes
8 changesets found
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 8 changesets with 117 changes to 117 files
remote: error: pretxnchangegroup.eol hook failed: 
Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not have CRLF line 
endings
remote: transaction abort!
remote: rollback completed
remote: abort: Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not 
have CRLF line endings


However, dnloop.patch is correct and must have CRLF line endings. How
can I disable the commit hook?


Stefan Krah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unload a module written in C

[Stefan Behnel]

"Martin v. Löwis", 25.03.2011 07:59:

Is there a bug somewhere, or do I misunderstood something important?


Module unloading is simply not implemented, and would be very difficult
to implement.


Are you saying that because objects instantiated from a module do not 
normally keep a reference to it to keep it alive?


Stefan

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal for Python 3.3: dependence injection

[Simon Cross]

On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan  wrote:
> As an example of the last point, perhaps rather than modifying all the
> *clients* of the socket module, it may make more sense to have tools
> in the socket module itself to temporarily customise the socket
> creation process in the current thread. The advantage of such an
> approach is that it would then work for 3rd party libraries that
> create sockets, without requiring any further modification.

-2.  That wouldn't allow one to use normal sockets in one 3rd party
library and special sockets in another 3rd party library.

Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unload a module written in C

[Martin v. Löwis]

> Is there a bug somewhere, or do I misunderstood something important?

Module unloading is simply not implemented, and would be very difficult
to implement.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com