[Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

2015-07-21 Thread Nick Coghlan 
On 20 July 2015 at 22:34, Ben Finney  wrote:
> Paul Moore  writes:
>
>> Again, I'm sorry to pick on one sentence out of context, but it cut
>> straight to my biggest fear when doing a commit (on any project) -
>> what if, after all the worrying and consideration I put into doing
>> this commit, people disagree with me (or worse still, I made a
>> mistake)? Will I be able to justify what I decided?
>
> That seems quite healthy to me. On a collaborative project with effects
> far beyond oneself, yes, any change *should* be able to be justified
> when challenged.

No, that's not how this works: if folks are thinking that being a
Python user, or even a CPython core developer, means that we're
entitled to micromanage core developers by demanding extensive
explanations for any arbitrary commit we choose, they're thoroughly
mistaken. Only Guido has that privilege, and one of the reasons he's
as respected as he is is his willingness to trust the experience and
expertise of others and only rarely exercise his absolute authority.

Folks are granted core committer privileges because we *trust their
instincts*. We trust them to know when they're acting within the
limits of their own expertise and experience, and we trust them to
know when it would be beneficial to seek feedback from a wider
audience before making up their minds.

There are *many* cases where we *don't know* up front what the right
answer is, so we'll actively seek consultation, whether that's through
a review request on the issue tracker, a focused python-dev
discussion, a more speculative discussion on python-ideas, or engaging
in the full Python Enhancement Proposal process.

There are also cases where we'll decide "it seems plausible that this
might be a good idea, so let's try it out and see what happens in
practice rather than continuing to speculate" - only ever doing things
that you're already 100% certain are a good idea is a recipe for
stagnation and decline (hence the "Now is better than never" line in
the Zen). A feedback cycle of a few years is a relatively short time
in programming language development, so if we discover with the
benefit of hindsight that something that seemed plausible really was
in fact a genuinely bad idea, that's why we have a deprecation process
(as well as the abilty to mark new APIs as provisional). If we want a
faster feedback cycle measured in days or weeks or months rather than
years, then we'll find a way to make the idea available for
experimentation via PyPI or at least as a cookbook recipe or in a
public source repo.

But the authority and responsibility to make changes, to decide what
constitutes a reasonable risk, to decide which updates are appropriate
to send out to tens of millions of Python users worldwide remains
*ours*.

Some of those decisions will be akin to deciding to paint a bikeshed
blue instead of yellow (or green, or red, or chartreuse, or ...).
Others will be about mitigating the observed negative consequences of
a previous design decision while retaining the positive aspects.

Those kinds of design decision are still more art than science -
that's why our solution to them is to attempt to recruit people with
the interest, ability and time needed to make them well, and then
largely leave them to it. Explaining design decisions after the fact
isn't about *defending* those decisions, it's about attempting to
convey useful design knowledge, in order to help build new core
contributors (and also because explaining something to someone else is
a good way to understand it better yourself).

All of this is why the chart that I believe should be worrying people
is the topmost one on this page:
http://bugs.python.org/issue?@template=stats

Both the number of open issues and the number of open issues with
patches are steadily trending upwards. That means the bottleneck in
the current process *isn't* getting patches written in the first
place, it's getting them up to the appropriate standards and applied.
Yet the answer to the problem isn't a simple "recruit more core
developers", as the existing core developers are *also* the bottleneck
in the review and mentoring process for *new* core developers.

In my view, those stats are a useful tool we can use to ask ourselves
"Am I actually helping with this contribution, or at the very least,
not causing harm?":

* participating in the core-mentorship list, and actively looking for
ways to improve the effectiveness of the mentorship program (that
don't just queue up more work behind the existing core developer
bottleneck) should help make those stats better

* sponsoring or volunteering to help with the upstream projects our
core workflow tools are based on (Roundup, Buildbot) or with updating
our specific installations of them should help make those stats better
(and also offers faster iteration cycles than core development itself)

* helping core developers that have time to work on "CPython in
general" rather than specific projects of interest to them to

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

2015-07-21 Thread Baptiste Carvello 
Hello,

since this thread is restarting in debriefing mode: one thing struck me
as a non-committer following python-dev.

It seems that we (non-committers) have a difficulty making the
distinction between pre-implementation design discussions (PEPs beeing
the typical example), where relevant technical comments are welcome,
even on minor points, and post-commit discussions, where the maintainer
already made the design decisions, and discussing anything except real
bugs is unhelpful.

In this particular thread, the distinction was all the more blurred by
the very generic title. A thread titled something like "Commit-xxx:
should mock try to detect user typos?" would have been much less likely
to attract comments discussing principles in the abstract, without
taking the context into account.

Regards,

Baptiste

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

2015-07-21 Thread Ben Finney 
Nick Coghlan  writes:

> On 20 July 2015 at 22:34, Ben Finney  wrote:
> > Paul Moore  writes:
> >
> >> […] my biggest fear when doing a commit (on any project) - what if,
> >> after all the worrying and consideration I put into doing this
> >> commit, people disagree with me (or worse still, I made a mistake)?
> >> Will I be able to justify what I decided?
> >
> > That seems quite healthy to me. On a collaborative project with
> > effects far beyond oneself, yes, any change *should* be able to be
> > justified when challenged.
>
> No, that's not how this works: if folks are thinking that being a
> Python user, or even a CPython core developer, means that we're
> entitled to micromanage core developers by demanding extensive
> explanations for any arbitrary commit we choose, they're thoroughly
> mistaken.

Definitely agreed, and I'm not implying otherwise.

There is a distinction to be drawn:

* If challenged to do so, could one (the contributor) present a
  compelling justification for the change?

  This is what I claim Paul Moore's doubt (fear?) is indicative of. I
  maintain that this doubt is quite healthy: it helps the contributor to
  pause, reflect, seek assistance in making decisions, and thereby also
  tends to exclude poorly-justified changes which would otherwise be
  committed.

* If a participant on this forum feels entitled to challenge a change,
  must the contributor present an arbitrary quantity of justification of
  each decision when challenged?

  This seems to be what many contributors object to, but I don't assert
  this at all. I never meant to imply that mere participation here
  entitles a person to demand justification for changes.

> Folks are granted core committer privileges because we *trust their
> instincts*. We trust them to know when they're acting within the
> limits of their own expertise and experience, and we trust them to
> know when it would be beneficial to seek feedback from a wider
> audience before making up their minds.

That's all good, and it's quite compatible with the healthy doubt I
described above.

> But the authority and responsibility to make changes, to decide what
> constitutes a reasonable risk, to decide which updates are appropriate
> to send out to tens of millions of Python users worldwide remains
> *ours*.

No objection from me.

I am not asking that contributors be at the mercy of limitless demands
for justification from arbitrary participants in this forum.

I am asking that contributors should *have* compelling justification for
any change they commit, if someone with sufficient authority were to ask
for it.

That doesn't make contributors any more answerable to arbitrary
participants here. It does make explicit that contributors, while
trusted of course, are answerable to more than their instincts and what
“feels right”: they are answerable also the community of core
contributors as a condition of that trust. They are also effectively
answerable to their own conscience about what justification that
community may ask in future.

-- 
 \  “We suffer primarily not from our vices or our weaknesses, but |
  `\from our illusions.” —Daniel J. Boorstin, historian, 1914–2004 |
_o__)  |
Ben Finney

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

2015-07-21 Thread Paul Moore 
On 21 July 2015 at 11:03, Ben Finney  wrote:
> * If challenged to do so, could one (the contributor) present a
>   compelling justification for the change?
>
>   This is what I claim Paul Moore's doubt (fear?) is indicative of. I
>   maintain that this doubt is quite healthy: it helps the contributor to
>   pause, reflect, seek assistance in making decisions, and thereby also
>   tends to exclude poorly-justified changes which would otherwise be
>   committed.

That is *not* what I was trying to express. My fear is that I will be
subjected to the sort of unreasonable level of debate and frankly
criticism that came up in this thread, and I'm not sure if I have the
energy to deal with it. I wouldn't ever commit something unless *in my
judgement* it was OK to go in. Whether my judgement is sufficient is
the whole point here.

And to be honest, there's an implication in your comment that you
think there is a possibility that any of the core devs might commit
something when they had a level of doubt[1] about whether it was right
to do so. I think that implication is unwarranted, and constitutes
exactly the sort of subtle criticism that escalates things like this.
I'm sure that's not what you intended, and I *know* I've reached a
point with this thread where I'm over-sensitive to such implications,
but it's a good illustration of how even a well-meaning comment can be
perceived very differently than it was intended by the recipient.

For something which is a hobby for me, I'd rather feel more joy in
what I achieve, and less burden of responsibility. Changing code that
affects I-don't-even-want-to-know-how-many people and businesses is
quite enough responsibility without also having to put up with only
hearing from people who disagree with what I do, and never from people
who are grateful...

End of unnecessarily emotional outpouring, we now return you to your
regular scheduled flamewars :-)

Paul

[1] That's doubt, not mistakes. People make mistakes. The big problem
here is python-dev is becoming pretty hostile to people who (are
perceived to) make mistakes. That is, ultimately, all of us.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

2015-07-21 Thread Nick Coghlan 
On 21 July 2015 at 21:19, Paul Moore  wrote:
> On 21 July 2015 at 11:03, Ben Finney  wrote:
>> * If challenged to do so, could one (the contributor) present a
>>   compelling justification for the change?
>>
>>   This is what I claim Paul Moore's doubt (fear?) is indicative of. I
>>   maintain that this doubt is quite healthy: it helps the contributor to
>>   pause, reflect, seek assistance in making decisions, and thereby also
>>   tends to exclude poorly-justified changes which would otherwise be
>>   committed.
>
> That is *not* what I was trying to express. My fear is that I will be
> subjected to the sort of unreasonable level of debate and frankly
> criticism that came up in this thread, and I'm not sure if I have the
> energy to deal with it. I wouldn't ever commit something unless *in my
> judgement* it was OK to go in. Whether my judgement is sufficient is
> the whole point here.

Exactly. Being granted a commit bit means "The folks that got CPython
to where it is today trust you to take appropriate risks in guiding
CPython's future". It can be safely assumed that *everyone* that has
that authority takes it *very* seriously (otherwise they wouldn't have
been granted commit privileges).

If there weren't any risks to be weighed and judgment calls to be
made, we could let a computer decide what commits should go in (and
indeed "make patchcheck" already handles some of those basic tasks,
and we'd like to automate even more of them like "does this patch
apply, and do the tests still pass on x86_64 under at least Windows
and a long term support Linux distro after applying it?"). This
challenge is reflected in the fact that the Zen of Python is
deliberately self-contradictory, as it articulates competing design
principles to take into consideration, rather than being able to
provide ironclad rules that avoid the need for human judgement in
determining *which* of those design guidelines are most salient in any
given situation.

Now, proposing further *enhancements* to a change is perfectly
reasonable, especially if the feedback is based on practical
experience with the original version of the change. The implementation
of PEP 492 (async/await), for example, underwent some fundamental
changes during the beta process, as developers' feedback showed that
some of the design decisions we made in the original version were
quite problematic. The original exception suppression mechanism in PEP
409 (which made clever-but-idiosyncratic use of Ellipsis), was
replaced with the simpler mechanism in PEP 415 (which instead uses a
more conventional setter-with-side-effects-on-other-attributes
approach).

Reverting changes because they broke the buildbots, or because they're
determined to cause bugs worse than the original problem is also not a
problem - in those cases, there's new information introduced into the
situation that changes the original risk assessment. An example of
that was deciding to deprecate and remove contextlib.nested() before
I'd figured out how to replace its legitimate use cases - I'd flat out
missed a fundamental problem with the way it interacted with open()
and similar resource allocation functions.

The draining and demotivating cases are the ones where *no new
information is introduced*, but the design decision is *challenged
anyway*. Those are the ones that feel like folks are saying "We don't
*actually* trust you with that authority and responsibility you've
been granted, so we're going to closely police the way you use it, and
expect to be able to persuade you to change your mind not through
reasoned argument, but through sheer volume".

For new core developers, or folks aspiring to become core developers,
it is *literally* the scenario that inspired Poul-Henning Kamp to
write the post at http://bikeshed.org/ (hit refresh if you get a low
contrast colour scheme, it will change). Don't bother trying to
improve anything, you'll just get grief and opposition for it rather
than community support.

For experienced core developers, it's a "Right, so you trust me to
build the nuclear power plant, but not to choose the colour of the
bike shed behind it" situation. Knowing we're trusted to build power
plants, but will get grief for working on smaller things creates an
even greater incentive to work solely on the big changes, and those
are already inherently more fun to work on anyway - they really don't
need the extra help.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How far to go with user-friendliness

2015-07-21 Thread Christie Wilson 
I am terrified of replying to this thread since so many folks on it seem
unhappy that it is continuing, but I want to +1 what Erik said.

Robert's solution is downright inspiring in how it gets to the heart of the
problem that the assret/assert feature is trying to address, and as a
frequent user of mock, I very much would like to see it implemented.

On Mon, Jul 20, 2015 at 11:30 AM, Erik Bray  wrote:

> On Tue, Jul 14, 2015 at 6:22 PM, Robert Collins
>  wrote:
> > For clarity, I think we should:
> >  - remove the assret check, it is I think spurious.
> >  - add a set of functions to the mock module that should be used in
> > preference to Mock.assert*
> >  - mark the Mock.assert* functions as PendingDeprecation
> >  - in 3.6 move the PendingDeprecation to Deprecated
> >  - in 3.7 remove the Mock.assert* functions and the check for method
> > names beginning with assert entirely.
>
> Hi all,
>
> I'm just an onlooker, and haven't read every word of this thread.  In
> fact I worry that it's pointless to reply to rather than starting a
> new thread.  I just wanted to make sure that the specific message I'm
> replying too wasn't lost in the noise because I think Robert's
> suggestion makes vastly more sense than anything else I've seen here
> (I came searching through the thread to see if anyone else suggested
> this before I started a thread to do so).
>
> I don't think it makes any sense to have magic assert_ methods on the
> Mock object.  Not only does the "magic" clearly lead to too many
> ambiguities and other problems--I think they make less sense from an
> API standpoint in the first place.  Typically asserting something in a
> test is not something an object *does*--a method.  More often we as a
> test writers assert something *about* an object.  The assertion is an
> external tool meant to measure and introspect things about the system
> under observation.  In this case, although Mock is itself a testing
> tool, we're introspecting something about the Mock object as external
> observers.
>
> ***Assertions on Mock objects should be implemented as stand-alone
> functions (that happen to be used primarily on Mock objects as
> input).***
>
> Aside from, in my mind, making more sense philosophically, using
> specialized assert functions for this has absolutely none of the
> spelling ambiguities or other problems of the magic methods.
>
> I'm -0 on removing the assret_ methods unless no one is using them
> yet.  I don't care if they're there as long as they're deprecated
> along with the other magic methods of Mock.
>
> Best,
> Erik
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com
>



-- 
Christie Wilson
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How far to go with user-friendliness

2015-07-21 Thread Tim Golden 
On 20/07/2015 19:48, Christie Wilson wrote:
> I am terrified of replying to this thread since so many folks on it seem
> unhappy that it is continuing, but I want to +1 what Erik said.

Don't be terrified :)

But do understand that, in general, and especially for this
already-noisy thread, the right place for arguments supporting a change
or a reversion is usually on the issue tracker:

 https://bugs.python.org/

I don't know whether Robert's opened an issue to propose his solution,
but if not, you could open one and add him as nosy.

TJG
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

2015-07-21 Thread Robert Collins 
On 21 July 2015 at 00:34, Ben Finney  wrote:
> Paul Moore  writes:
>
>> Again, I'm sorry to pick on one sentence out of context, but it cut
>> straight to my biggest fear when doing a commit (on any project) -
>> what if, after all the worrying and consideration I put into doing
>> this commit, people disagree with me (or worse still, I made a
>> mistake)? Will I be able to justify what I decided?
>
> That seems quite healthy to me. On a collaborative project with effects
> far beyond oneself, yes, any change *should* be able to be justified
> when challenged.

Depending on what you mean by justification , this leaves no leeway
for hunches, feelings, intuition, or grey area changes.

It's also a terrible way to treat people that are contributing their
own time and effort: assume good faith is a much better starting
point.

I think its reasonable to say that any change should be open to post
hoc discussion. Thats how we learn, but justification and challenging
is an adversarial framing, and one I'm flatly uninterested in. Life is
too short to volunteer on adversarial activies.

> That isn't a mandate to challenge every change, of course. It does mean
> that every change should be considered in light of “Can I justify
> this, if challenged?”
>
> So what you describe sounds like a healthy barrier: one which works to
> keep out unjustifiable changes.

I don't understand why thats healthy or useful.

> What is needed is to have both that *and* the support of the community
> so it's not a barrier to the *contributors*. The contributors should not
> feel excluded merely because some of their changes might need to be.

I don't think that contributors are a problem here. But, I'm going to
dig into that more in reply to Nick.

>> Hmm, maybe I'd better hold off and let someone else make the
>> decision...
>
> What of the (obvious, to me) option to retain the authority to make the
> decision, but take the doubt as a sign that one should consult with
> others before making the decision?
>
> That is, there's no need to feel that one shouldn't make the decision.
> But perhaps one shouldn't make it solely on one's own experience or
> insight. Get others involved, even non-committers, and discuss it, and
> understand the issue better. With that improved basis, then make the
> decision.

As a case study, this discussion where something like 90% of the
kibbitzing demonstrated a clear lack of understanding of the very
behaviour of Mock, *and* the change in question was discussed, *prior*
to it being done, *and* users have welcomed itI must conclude that
either:
 - this discussion was the exception to prove your general rule (but
why would we derive that general rule from this discussion)
 - the general rule isn't general.

> Am I naive to think that's desirable for PYthon core committers?

What's the goal here: what actual problem are we trying to solve for?

More contributors? A better Python more people can use? Keeping up
with the contributions we've already received but not actioned? [...]

Like: pick one thing. What we /really/ want to achieve, then lets look
at what will let us get there.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

2015-07-21 Thread Robert Collins 
On 21 July 2015 at 19:40, Nick Coghlan  wrote:
> On 20 July 2015 at 22:34, Ben Finney  wrote:
>> Paul Moore  writes:
>>
>>> Again, I'm sorry to pick on one sentence out of context, but it cut
>>> straight to my biggest fear when doing a commit (on any project) -
>>> what if, after all the worrying and consideration I put into doing
>>> this commit, people disagree with me (or worse still, I made a
>>> mistake)? Will I be able to justify what I decided?
>>
>> That seems quite healthy to me. On a collaborative project with effects
>> far beyond oneself, yes, any change *should* be able to be justified
>> when challenged.
>
> No, that's not how this works: if folks are thinking that being a
> Python user, or even a CPython core developer, means that we're
> entitled to micromanage core developers by demanding extensive
> explanations for any arbitrary commit we choose, they're thoroughly
> mistaken. Only Guido has that privilege, and one of the reasons he's
> as respected as he is is his willingness to trust the experience and
> expertise of others and only rarely exercise his absolute authority.

I wouldn't even agree that Guido is entitled to micromanage us. He is
certainly entitled to demand explanations etc if he feels appropriate
- but if that turned into micromanaging, I think we'd be in a very bad
place.

> All of this is why the chart that I believe should be worrying people
> is the topmost one on this page:
> http://bugs.python.org/issue?@template=stats
>
> Both the number of open issues and the number of open issues with
> patches are steadily trending upwards. That means the bottleneck in
> the current process *isn't* getting patches written in the first
> place, it's getting them up to the appropriate standards and applied.

Perhaps.

> Yet the answer to the problem isn't a simple "recruit more core
> developers", as the existing core developers are *also* the bottleneck
> in the review and mentoring process for *new* core developers.

sidebar: So, anyone here familiar with theory of constraints - e.g.
'The Goal', 'Critical Chain' etc? Might be interesting to do some
brainstorming in that shape if folk are interest.

Having open idle patches is I think generally acknowledged as a poor
thing. I think of them as inventory in a manufacturing plant: they
take up space, they take effort to create, they offer no value [until
they're actually shipped to users], and they have direct negatives
(tracker is harder to work with due to the signal-to-noise ratio,
perception of the project suffers, contributors make the rational
discussion not to contribute further...).

Lets assume that our actual goal is to ship new Python versions,
offering more and better things to users.

AFAIK we're not lacking any infrastructure resources - we have enough
buildbots, we have freely available compilers for all platforms.

> In my view, those stats are a useful tool we can use to ask ourselves
> "Am I actually helping with this contribution, or at the very least,
> not causing harm?":

I like this approach  :). But - can we go further, can we actively
protect core committer time such that they waste less of it? Adding
core committers won't help if the problem isn't the number of
committers, but rather the amount of the time that they can devote to
Python that actually gets spent on committer-activities.

> * helping core developers that have time to work on "CPython in
> general" rather than specific projects of interest to them to focus
> their attention more effectively may help make those stats better (and
> it would be even better if we could credit such triaging efforts
> appropriately)

Iterating on a patch someone else put up can help. Making sure its
passing tests, trying it with ecosystem projects and giving feedback.

> * exploring ways to extract contribution metrics from Roundup so we
> can have a more reliable detection mechanism for active and consistent
> contributors than the "Mark 1 core developer memory, aka the
> notoriously unreliable human brain" may help make those stats better

OTOH, make sure that what we measure provokes things that help our
goal :). Double edged sword this.

> Make no mistake, sustainable open source development is a *genuinely
> hard problem*. We're in a much better position than most projects
> (being one of the top 5 programming languages in the world has its
> benefits), but we're still effectively running a giant multinational
> collaborative software development project with close to zero formal
> management support. While their are good examples we can (and are)
> learning from, improving the support structures for an already wildly
> successful open source project without alienating existing
> contributors isn't a task that comes with an instruction manual :)

+1

-Rob
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-d

Re: [Python-Dev] How far to go with user-friendliness

2015-07-21 Thread Robert Collins 
On 22 July 2015 at 03:47, Tim Golden  wrote:
> On 20/07/2015 19:48, Christie Wilson wrote:
>> I am terrified of replying to this thread since so many folks on it seem
>> unhappy that it is continuing, but I want to +1 what Erik said.
>
> Don't be terrified :)
>
> But do understand that, in general, and especially for this
> already-noisy thread, the right place for arguments supporting a change
> or a reversion is usually on the issue tracker:
>
>  https://bugs.python.org/
>
> I don't know whether Robert's opened an issue to propose his solution,
> but if not, you could open one and add him as nosy.

I did: http://bugs.python.org/issue24651

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reminder: Python 3.5 beta 4 is tagged in one week

2015-07-21 Thread Robert Collins 
Cool. http://bugs.python.org/issue21750 is in a bad state right now.

I landed a patch to fix it, which when exposed to users had some
defects. I'm working on a better patch now, but need to either roll
the prior patch completely back, or get the new one landed before the
next beta. I hope to have that up for review later today {fingers
crossed} - will that be soon enough, or should I look up how to easily
revert stuff out with hg?

-Rob

On 18 July 2015 at 22:24, Larry Hastings  wrote:
>
>
> Approximately a week from when I post this, I'll be tagging Python 3.5 beta
> 4, which is the last beta before we go to release candidates.  Please wind
> up all your bug fixes soon, I'd really like checkins to 3.5 to stop soon.
>
> And a minor reminder: when we hit Release Candidate 1, I'll be switching the
> canonical repo for 3.5 to a public Bitbucket repo.  Any bug fixes that go in
> between RC 1 and final will only be merged using Bitbucket "pull requests".
>
> The new workflow experiment continues,
>
>
> /arry
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/robertc%40robertcollins.net
>



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reminder: Python 3.5 beta 4 is tagged in one week

2015-07-21 Thread Larry Hastings 



On 07/21/2015 06:35 PM, Robert Collins wrote:

Cool. http://bugs.python.org/issue21750 is in a bad state right now.

I landed a patch to fix it, which when exposed to users had some
defects. I'm working on a better patch now, but need to either roll
the prior patch completely back, or get the new one landed before the
next beta. I hope to have that up for review later today {fingers
crossed} - will that be soon enough, or should I look up how to easily
revert stuff out with hg?


If you want to undo it, "hg backout" is the command you want.  In 
general it's best to not check in broken stuff.



//arry/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Devguide - Add Communications Quick Start Section

2015-07-21 Thread Carol Willing 
I would like to add a "Communications Quick Start" section to the 
beginning of the Python Developer's Guide.


Productive communication between each other will always be critical to 
future development of CPython and maintaining releases, infrastructure, 
documentation, and more.


Unproductive communication saps energy of contributors, reduces 
engagement in the project, and limits creativity and fulfillment in 
contributing. As a contributor who finds great value in the power and 
zen of Python, I want to foster more effective and productive 
communication. I've been thinking about ways to do this since the PyCon 
sprints. New developers would benefit from understanding how to interact 
with the community and its norms. Existing contributors would hopefully 
benefit from less time reexplaining community communication norms.


The Communications Quick Start section would be brief and practical much 
like the Quick Start section for downloading and testing the source 
code. Placing the Communications Quick Start section before the existing 
Quick Start section would emphasize the importance that productive 
communications has on CPython development.


Thanks,
Carol

P.S. Thank you to all that devote time and energy to the development of 
CPython. I have posted this to the python-dev mailing list for feedback 
due to the recent discussions. Nick and Brett, please feel free to move 
this to python-ideas if you feel that would be a better place to discuss 
this addition to the devguide.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide - Add Communications Quick Start Section

2015-07-21 Thread Brett Cannon 
On Tue, Jul 21, 2015 at 11:05 AM Carol Willing <
[email protected]> wrote:

> I would like to add a "Communications Quick Start" section to the
> beginning of the Python Developer's Guide.
>
> Productive communication between each other will always be critical to
> future development of CPython and maintaining releases, infrastructure,
> documentation, and more.
>
> Unproductive communication saps energy of contributors, reduces
> engagement in the project, and limits creativity and fulfillment in
> contributing. As a contributor who finds great value in the power and
> zen of Python, I want to foster more effective and productive
> communication. I've been thinking about ways to do this since the PyCon
> sprints. New developers would benefit from understanding how to interact
> with the community and its norms. Existing contributors would hopefully
> benefit from less time reexplaining community communication norms.
>
> The Communications Quick Start section would be brief and practical much
> like the Quick Start section for downloading and testing the source
> code. Placing the Communications Quick Start section before the existing
> Quick Start section would emphasize the importance that productive
> communications has on CPython development.
>

Sounds great to me! Social norms are just as important to get to speed on
as technical requirements when contributing to an open source community, so
this seems like a worthy project.


>
> Thanks,
> Carol
>
> P.S. Thank you to all that devote time and energy to the development of
> CPython. I have posted this to the python-dev mailing list for feedback
> due to the recent discussions. Nick and Brett, please feel free to move
> this to python-ideas if you feel that would be a better place to discuss
> this addition to the devguide.
>

Nope, here is fine. This isn't a new idea and it affects people on this
list more directly than the python-ideas folks.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide - Add Communications Quick Start Section

2015-07-21 Thread Terry Reedy 

On 7/21/2015 1:06 PM, Carol Willing wrote:

I would like to add a "Communications Quick Start" section to the
beginning of the Python Developer's Guide.


I would rename 'Quick Start' to 'Quick Start: Code Development' and add 
'Quick Start: Communications' (or maybe 'Q S: Community Interaction'). 
I am not sure about the order.


Unless there is opposition I do not expect, go ahead and open an issue.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reminder: Python 3.5 beta 4 is tagged in one week

2015-07-21 Thread Robert Collins 
On 22 July 2015 at 05:08, Larry Hastings  wrote:
>
>
> On 07/21/2015 06:35 PM, Robert Collins wrote:
>
> Cool. http://bugs.python.org/issue21750 is in a bad state right now.
>
> I landed a patch to fix it, which when exposed to users had some
> defects. I'm working on a better patch now, but need to either roll
> the prior patch completely back, or get the new one landed before the
> next beta. I hope to have that up for review later today {fingers
> crossed} - will that be soon enough, or should I look up how to easily
> revert stuff out with hg?
>
>
> If you want to undo it, "hg backout" is the command you want.  In general
> it's best to not check in broken stuff.

Thanks. And yes, naturally - we didn't realise it was broken. Passing
tests != fit for purpose.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 3.4.3 on RedHat 6.6 s390x make fails with: make: *** [sharedmods] Error 139

2015-07-21 Thread Vitale, Joseph 
Hello,

Trying to install Python 3.4.3  on Red Hat  6.6 zLinux(s390x)  but "make" fails 
and core dumps.  Not using OpenSSL and did not configure for it.

Can you provide direction?


./configure

make

 gcc -pthread -fPIC -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

 -Werror=declaration-after-statement -I/usr/local/ssl/include

 -I./Include -I. -IInclude -I/usr/local/include

 -I/xjp/Python-3.4.3/Include -I/xjp/Python-3.4.3 -c

 /xjp/Python-3.4.3/Modules/_ssl.c -o

 build/temp.linux-s390x-3.4/xjp/Python-3.4.3/Modules/_ssl.o

gcc -pthread -shared

 build/temp.linux-s390x-3.4/xjp/Python-3.4.3/Modules/_ssl.o

 -L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o

 build/lib.linux-s390x-3.4/_ssl.cpython-34

m.so



/bin/sh: line 6: 48734 Segmentation fault  (core dumped) CC='gcc -pthread' 
LDSHARED='gcc -pthread -shared  ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes' _TCLTK_I

NCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py $quiet build

make: *** [sharedmods] Error 139

Thanks

Joe

The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

2015-07-21 Thread Stephen J. Turnbull 
Ben Finney writes:

 > Definitely agreed, and I'm not implying otherwise.
 > 
 > There is a distinction to be drawn:
 > 
 > * If challenged to do so, could one (the contributor) present a
 >   compelling justification for the change?

Aside from Paul's disclaimer, this is way too high a bar.  Nick tried
to express that in his post, but I doubt it's possible to successfully
communicate what Nick means in a mailing list post because it's a very
subtle distinction that requires a lot of "what could he be thinking"
effort from *each* reader to convey.

 > * If a participant on this forum feels entitled to challenge a
 >   change, must the contributor present an arbitrary quantity of
 >   justification of each decision when challenged?

This expression is improperly restrictive.  Contributors object to it
because it's objectively objectionable, and easy to express.  But they
also don't want to wade through arbitrary amounts of feedback which is
often context-free and/or actually misguided.  They don't want to
explain a point multiple times to casual readers who miss it, or spend
the inordinate amount of effort required to compose a post that covers
all the context needed in terms that all the casual readers can parse.
All that is much harder to explain in terms which will result in
*well-informed, to-the-point* feedback, and without sounding like "I
know what I'm doing so STFU" (the recent "to python-dev from
python-dev" post is an example of the kind of wording that can be
misinterpreted this way).

So people object to "micro-management" as a summary of frustration,
but the actual sematics are complex and subtle.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

2015-07-21 Thread Stephen J. Turnbull 
Nick Coghlan writes:

 > The draining and demotivating cases are the ones where *no new
 > information is introduced*, but the design decision is *challenged
 > anyway*.

But this particular thread is an extreme case, that demonstrates why
this kind of thing happens *despite* the good intentions of everyone
involved.  The design decision (to special-case a typo) that was made
is a true "WTF?!"  The "meta" of "special cases aren't special enough
to break the rules" is that no design decision that violates it should
be dismissed as "minor".  In context of a mailing list, doing so is
going to be taken by readers as "I know what I'm doing, and you don't
know what you're talking about, so STFU."

The average poster to Python-Dev surely trusts the core developers to
know what they're doing.  If you (as the developer or developers on
the spot) don't have time to explain, at least indicate that the
process implied in

 > Folks are granted core committer privileges because we *trust their
 > instincts*. We trust them to know when they're acting within the
 > limits of their own expertise and experience, and we trust them to
 > know when it would be beneficial to seek feedback from a wider
 > audience before making up their minds.

was followed.[1]  Something like

The special case of trapping the typo "assret" was discussed on
python-committers.  The conclusion was that in the special context
of mock this is a case where "practicality beats purity".  In any
case, the decision has been discussed thoroughly and isn't going
to change in the absence of truly new information, so further
discussion here is pointless.  Let's move on.

would have stopped the thread in its tracks, I believe.[2]  But
repeated unexplained assertions that the design decision is "minor"
were just a red cape to a bull.  That explanation just *feels*
*wrong*, it causes massive cognitive dissonance -- and makes it very
hard for readers to respond appropriately to perfectly valid
explanations that "this is not the time to make a change anyway".

 > Those are the ones that feel like folks are saying "We don't
 > *actually* trust you with that authority and responsibility you've
 > been granted, so we're going to closely police the way you use it, and
 > expect to be able to persuade you to change your mind not through
 > reasoned argument, but through sheer volume".

This is a fallacy, very human, but still the fallacy of
anthropomorphizing a crowd.  A very few people repeatedly posted with
the content limited to "Special cases aren't", but most expressed
their puzzlement in varied ways over time.  Of course all of them
started with "special cases aren't", which is why the proponents feel
browbeaten.

*Both* roles in this comedy of errors are natural, they are inherent
in human cognition (citations on request), and nobody is to be blamed.
At Python's scale, *some* (not all) of the core developers are going
to need to recognize the "crowd" dynamic and deal with it -- or Python
won't scale any further IMO.  (In theory there may be better channels
than mailing lists which would inhibit this dynamic, but I don't know
of any practical ones.)

 > Don't bother trying to improve anything, you'll just get grief and
 > opposition for it rather than community support.
 > 
 > For experienced core developers, it's a "Right, so you trust me to
 > build the nuclear power plant, but not to choose the colour of the
 > bike shed behind it" situation.

Et tu, Brutus!  This point has been made *so* many times in this
thread.  Surely you don't think anybody missed it!

The only *practical* suggestion from "the core" has been self-
restraint on the part of "the crowd".  But that has severe limits
*because* the "crowd" is made up of people who "aren't Dutch yet".
They *are* going to ask questions, and as Python Dev gets bigger, more
of them are going to ask questions, and in particularly controversial
cases they are going to ask more or less simultaneously, resulting in
the "browbeating effect".

I think it's time to either end this "meta" thread, or refocus it from
"why contributors feel sad" and "why we should trust committers"
(AFAICS there is actually consensus on both, although sometimes
expressed as apparent disagreement) to discussion of practical ways to
resolve the conflict.  That is the conflict between the need of actual
contributors to get to-the-point feedback and the need of contributors-
in-embryo to learn what's going on.  Sadly, as long as the proposed
"Communication" section in the devguide concentrates on the
responsibility of commenters to exercise restraint to the exclusion of
the possibility of "somebody" managing threads, it's not going to help
much IMO.  Python Dev is *already* as civil a forum as any I've seen,
considering its scale and its success in recruiting new contributors
at all levels of maturity.

Steve

Footnotes: 
[1]  It occurs to me that pointing to existing discussion actually is
the responsibility of an OP wh

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?

2015-07-21 Thread Nikolaus Rath 
On Jul 21 2015, Nick Coghlan  wrote:
> All of this is why the chart that I believe should be worrying people
> is the topmost one on this page:
> http://bugs.python.org/issue?@template=stats
>
> Both the number of open issues and the number of open issues with
> patches are steadily trending upwards. That means the bottleneck in
> the current process *isn't* getting patches written in the first
> place, it's getting them up to the appropriate standards and applied.
> Yet the answer to the problem isn't a simple "recruit more core
> developers", as the existing core developers are *also* the bottleneck
> in the review and mentoring process for *new* core developers.

As a random datapoint:

Early last year I wanted get involved in CPython development. In the
next months I submitted and reviewed maybe 20 - 25 patches in the bug
tracker. After seeing all of them languish, I stopped submitting and
reviewing and just tried to get someone to look at the issues that I'd
worked on. Eventually, I managed to get almost all of them committed
(the last one sometime this February, after more than a year). However,
it was such an uphill battle just to get someone to look at my
contributions that I haven't touched the bugtracker ever since.

If it were up to me, I'd focus all the resources of the PSF on reducing
this backlog - be that by hiring some core developers to work full-time
on just the open bugtracker issues, or by financing development of
better code review and commit infrastructure. The current situation
looks like a downward spiral to me. New contributors are frustrated and
leave because they feel their contribution is not welcome, and core
developers get burned out by the gigantic backlog and the interaction
with frustrated patch submitters - thus further reducing the available
manpower.

(I am aware of the forge PEPs that you mention below, but as far as I
know even those are stalled because of - guess what - lack of available
core developer time).

Working on Roundup, the CPython infrastructure or Kallithea may be less
frustrating for new contributors (I don't know), but what this boils
down to is that you're contributing to a different project, and not to
CPython. But if you've decided to work on something else, there is (at
least for me) little reason to restrict the choice to projects that are
used *for* CPython development. And compared to the whole range of other
open source projects, I suspect the above options just don't look all
that interesting to many people. In other words: you typically can't
tell volunteers what to work on - you've got to accept the contribution
in the area they're interested in, or you loose the contributor. In case
of CPython the latter may be unavoidable at the moment, but I think it's
illusory to think that this can be solved by "redirecting" the stream of
contributions. Suppose you just found a bug in Python and you want to
upstream the patch so you don't have to carry the workaround
forever. Now you see there are already a lot of open issues with patches
- are you going to forget about your patch and e.g. decide to work on
the buildbots insteads?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide - Add Communications Quick Start Section

2015-07-21 Thread Nick Coghlan 
On 22 July 2015 at 04:08, Brett Cannon  wrote:
> On Tue, Jul 21, 2015 at 11:05 AM Carol Willing
>  wrote:
>> The Communications Quick Start section would be brief and practical much
>> like the Quick Start section for downloading and testing the source
>> code. Placing the Communications Quick Start section before the existing
>> Quick Start section would emphasize the importance that productive
>> communications has on CPython development.
>
>
> Sounds great to me! Social norms are just as important to get to speed on as
> technical requirements when contributing to an open source community, so
> this seems like a worthy project.

+1 from me as well. The discussion of a more formal CoC on the
python-committers list also highlighted for me that our main current
problems don't appear to be with any ill-intent on anyone's part, but
rather with well-intentioned messages that nevertheless have the
effect of causing folks to feel unappreciated and resentful. A
practical quick start guide is likely to be more effective in
addressing that aspect than a more explicit CoC (although I still
think the latter would be a good idea in the long run).

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?

2015-07-21 Thread Nick Coghlan 
On 22 July 2015 at 13:23, Nikolaus Rath  wrote:
> If it were up to me, I'd focus all the resources of the PSF on reducing
> this backlog - be that by hiring some core developers to work full-time
> on just the open bugtracker issues, or by financing development of
> better code review and commit infrastructure.

Ah, but the PSF can't do that without infringing on python-dev's
autonomy - switching to my PSF Director's hat, while we'd certainly be
prepared to help with funding a credible grant proposal for something
like the Twisted technical fellowship, we wouldn't *impose* help that
the core developers haven't asked for. That again bottlenecks on core
developer time, though - figuring out how to reasonably run such a
fellowship programme (especially the recruiting aspects) without
alienating volunteers is yet another "hard community management
problem".

>From the "strange but true" files, it's also the case that growing the
core developer community *isn't* actually the PSF's highest priority -
that honour goes to growing the Python *user* community, and the
reference interpreter itself is only one aspect of that (while
https://wiki.python.org/moin/PythonSoftwareFoundation/Proposals/StrategicPriorities
is only a draft, it still gives a good guide as to the extent of the
PSF's wider activities).

> The current situation
> looks like a downward spiral to me. New contributors are frustrated and
> leave because they feel their contribution is not welcome, and core
> developers get burned out by the gigantic backlog and the interaction
> with frustrated patch submitters - thus further reducing the available
> manpower.

We actually still have a lot of paid core developer (and potential
core developer) time locked up in facilitating the Python 2 -> 3
migration, as we didn't fully appreciate the extent to which Python
had been adopted in the Linux ecosystem and elsewhere until folks
started seeking help upgrading.

Knowing that doesn't help in the near term, of course, but it does
mean we know there's a relatively large pool of paid development time
currently being directed elsewhere that may be brought more directly
to bear upstream in the future.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide - Add Communications Quick Start Section

2015-07-21 Thread Carol Willing 

On 7/21/15 9:31 PM, Nick Coghlan wrote:

On 22 July 2015 at 04:08, Brett Cannon  wrote:

On Tue, Jul 21, 2015 at 11:05 AM Carol Willing
 wrote:

The Communications Quick Start section would be brief and practical much
like the Quick Start section for downloading and testing the source
code. Placing the Communications Quick Start section before the existing
Quick Start section would emphasize the importance that productive
communications has on CPython development.


Sounds great to me! Social norms are just as important to get to speed on as
technical requirements when contributing to an open source community, so
this seems like a worthy project.

+1 from me as well. The discussion of a more formal CoC on the
python-committers list also highlighted for me that our main current
problems don't appear to be with any ill-intent on anyone's part, but
rather with well-intentioned messages that nevertheless have the
effect of causing folks to feel unappreciated and resentful. A
practical quick start guide is likely to be more effective in
addressing that aspect than a more explicit CoC (although I still
think the latter would be a good idea in the long run).

Regards,
Nick.


I have created an issue
 on the Quick Start: Communications section. Please feel free to add further 
suggestions there.

Thanks for the support. Terry, I like your suggested wording :)

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4.3 on RedHat 6.6 s390x make fails with: make: *** [sharedmods] Error 139

2015-07-21 Thread Terry Reedy 

On 7/21/2015 6:20 PM, Vitale, Joseph wrote:

Hello,

Trying to install Python 3.4.3  on Red Hat  6.6 zLinux(s390x)  but
“make” fails and core dumps.  Not using OpenSSL and did not configure
for it.


Questions about installing current Python should be directed to 
python-list.  pydev is for developing future releases and versions of 
Python.


--
Terry Jan Reedy


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com