On 29 July 2015 at 02:17, Ben Finney ben+pyt...@benfinney.id.au wrote:
Paul Moore p.f.mo...@gmail.com writes:
On 28 July 2015 at 13:35, Ben Finney ben+pyt...@benfinney.id.au wrote:
People can, do, and probably must make many decisions through
non-rational processes. I don't propose to
On Jul 28, 2015 10:41 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Ben Finney writes:
I've made a clear distinction between the need to *be able to*
justify a change, versus arbitrary demands to do so by arbitrary
members.
The latter is what you're arguing against, and of
On 07/29/2015 09:18 AM, Wes Turner wrote:
sorry, I haven't the context for this
tl;dr -- Mock objects now protect against accidentally accessing wrong assert methods by raising an attribute error; this is different than past behavior in that any attribute that didn't exist
simply returned a
On 28 July 2015 at 05:18, Ben Finney ben+pyt...@benfinney.id.au wrote:
Indeed, these non-rational ways of reaching a decision are essential to
allow us to act with any kind of speed. Non-rational decision making is
much faster, and necessarily will form the great majority of our
decision
Paul Moore p.f.mo...@gmail.com writes:
On 28 July 2015 at 13:35, Ben Finney ben+pyt...@benfinney.id.au wrote:
People can, do, and probably must make many decisions through
non-rational processes. I don't propose to change that.
Good.
Choices can be made that, when challenged, lack
Paul Moore p.f.mo...@gmail.com writes:
But isn't the whole *point* of a non-rational decision (as you
describe it) that you *can't* articulate your reasons for making that
decision.
You've conflated the process used to make a decision, with the
justifications that support that decision.
On 28 July 2015 at 13:35, Ben Finney ben+pyt...@benfinney.id.au wrote:
People can, do, and probably must make many decisions through
non-rational processes. I don't propose to change that.
Good.
Choices can be made that, when challenged, lack compelling rational
justification. I do propose
Ben Finney writes:
I've made a clear distinction between the need to *be able to*
justify a change, versus arbitrary demands to do so by arbitrary
members.
The latter is what you're arguing against, and of course I agree. I've
never advocated that.
Sure, but the former, when stated
On 29 July 2015 at 00:17, Ben Finney ben+pyt...@benfinney.id.au wrote:
I've made a clear distinction between the need to *be able to* justify a
change, versus arbitrary demands to do so by arbitrary members.
The latter is what you're arguing against, and of course I agree. I've
never
Robert Collins robe...@robertcollins.net writes:
On 21 July 2015 at 00:34, Ben Finney ben+pyt...@benfinney.id.au wrote:
Paul Moore p.f.mo...@gmail.com 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
Stephen J. Turnbull step...@xemacs.org writes:
[…] 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.
Thank you. That dismissal was very upsetting; essentially telling Python
users that their concerns
On 23 Jul 2015 01:36, Nikolaus Rath nikol...@rath.org wrote:
On Jul 22 2015, Nick Coghlan ncogh...@gmail.com wrote:
On 22 July 2015 at 13:23, Nikolaus Rath nikol...@rath.org 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
On 23 July 2015 at 03:01, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Jul 22, 2015 at 7:09 AM, Paul Moore p.f.mo...@gmail.com wrote:
does anyone seriously think a core dev
commits code as a joke???
Yes, https://hg.python.org/cpython/rev/0530aadff696. :-)
Second
On Jul 22 2015, Nick Coghlan ncogh...@gmail.com wrote:
On 22 July 2015 at 13:23, Nikolaus Rath nikol...@rath.org 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
On 22 July 2015 at 12:09, Paul Moore p.f.mo...@gmail.com wrote:
5. Assume that the decision was well-considered and made with good
reasons. If you don't understand the reasons, and feel you need to,
ask for them, but refrain from judgement until you have the reasons.
The original mail in this
* Nikolaus Rath nikol...@rath.org [2015-07-21 20:23:15 -0700]:
On Jul 21 2015, Nick Coghlan ncogh...@gmail.com 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
On 22 July 2015 at 03:18, Stephen J. Turnbull step...@xemacs.org wrote:
The only *practical* suggestion from the core has been self-
restraint on the part of the crowd
I would have said the following has been covered, but maybe not. At
the risk of repeating something that's already been said,
On Wed, Jul 22, 2015 at 7:09 AM, Paul Moore p.f.mo...@gmail.com wrote:
does anyone seriously think a core dev
commits code as a joke???
Yes, https://hg.python.org/cpython/rev/0530aadff696. :-)
___
Python-Dev mailing list
Python-Dev@python.org
On 21 July 2015 at 00:34, Ben Finney ben+pyt...@benfinney.id.au wrote:
Paul Moore p.f.mo...@gmail.com 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
On 21 July 2015 at 19:40, Nick Coghlan ncogh...@gmail.com wrote:
On 20 July 2015 at 22:34, Ben Finney ben+pyt...@benfinney.id.au wrote:
Paul Moore p.f.mo...@gmail.com 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
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
On 22 July 2015 at 13:23, Nikolaus Rath nikol...@rath.org 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
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
On Jul 21 2015, Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com writes:
On 20 July 2015 at 22:34, Ben Finney ben+pyt...@benfinney.id.au wrote:
Paul Moore p.f.mo...@gmail.com writes:
[…] my biggest fear when doing a commit (on any project) - what if,
after all the worrying and consideration I put into doing this
On 21 July 2015 at 11:03, Ben Finney ben+pyt...@benfinney.id.au 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:
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
On 21 July 2015 at 21:19, Paul Moore p.f.mo...@gmail.com wrote:
On 21 July 2015 at 11:03, Ben Finney ben+pyt...@benfinney.id.au 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?)
28 matches
Mail list logo
