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

Since I started this thread: I like mock's magic I appreciate plain language extra features (.called, .reset_mock(), .side_effect, etc) [1] I even appreciate assert* error magic [2] assret* is just puzzling, unexpected. [1] those who want clear separation like `._assert_called_with()` are going t

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

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,

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

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 righ

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

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 o

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

Dear Python-dev Nobody who cares is reading this thread any more - I'm guessing Guido silenced it within the first 10 emails and so has almost everyone else. All you're doing is exposing your own inabilities to understand the issue (there are not now, have never been, and never will be, methods

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

On 07/20/2015 01:35 PM, Florian Bruhin wrote: > >>>m.assert_me() >Traceback (most recent call last): > File "", line 1, in > File "/media/hda2/home/ra/Dev/python-dev/python3.5/cpython-master/Lib/unittest/mock.py", >line 583, in __getattr__ > raise AttributeError(name) >AttributeError

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

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 PendingDeprecati

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

* Ron Adam [2015-07-20 12:57:08 -0400]: > >It's "unsafe" because tests which: > > > >1) are using the assert_* methods of a mock, and > >2) where the programmer did a typo (assert_called() instead of > >assert_called_with() for example) > > > >do silently pass. > > And further down, you say..

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

On 07/20/2015 03:32 AM, Florian Bruhin wrote: * Ron Adam [2015-07-19 18:06:22 -0400]: > > >On 07/19/2015 02:33 PM, Florian Bruhin wrote: > >* Ron Adam [2015-07-19 11:17:10 -0400]: > >>>I had to look at the source to figure out what this thread was really all > >>>about. > >And it seems I

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

On 20 July 2015 at 13:34, Ben Finney wrote: >> 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

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

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

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

On 20 July 2015 at 08:15, Stephen J. Turnbull wrote: > Every one needs to be considered carefully, It's very hard to pick out snippets like this out of context, particularly in a thread that has already caused a lot of turmoil, but I think this point is worth addressing. And my apologies in advan

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

On 20 July 2015 at 17:15, Stephen J. Turnbull wrote: > ISTM that the missing rationale is that the real special case is mock > itself. Michael referred to this context, but didn't make it > explicit. Mock effectively "monkeypatches the world". In that > context, the decision to protect against

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

* Ron Adam [2015-07-19 18:06:22 -0400]: > > > On 07/19/2015 02:33 PM, Florian Bruhin wrote: > >* Ron Adam [2015-07-19 11:17:10 -0400]: > >>>I had to look at the source to figure out what this thread was really all > >>>about. > > And it seems I don't quite get it still, but I am trying. No wo

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

Terry Reedy writes: > Good (or certainly much better): this blank> I think so too, but IMO Nick and Antoine made a serious mistake by deprecating this as a "minor design decision" without further rationale. That's no excuse at all! The point of the Zen about "special cases" is that these mino

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

Nick Coghlan writes: > Sorry, I crossed a line there - I know everyone posting to this thread > is doing so with the best interests of Python at heart. Thanks for saying so, I was mulling a similar post but yours came first. > The *problem* with threads like this one is that they end up feeling

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

On 07/19/2015 02:33 PM, Florian Bruhin wrote: * Ron Adam [2015-07-19 11:17:10 -0400]: >I had to look at the source to figure out what this thread was really all >about. And it seems I don't quite get it still, but I am trying. >Basically it looks to me the purpose of adding "assret" is t

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

On 19/07/2015 22:06, Brett Cannon wrote: On Sun, Jul 19, 2015 at 8:58 AM Ethan Furman mailto:et...@stoneleaf.us>> wrote: On 07/19/2015 02:22 AM, s.krah wrote: > Ein Sa, 18 Jul 2015 15:35:05 + *Stephen J. Turnbull hat geschrieben >> s.krah writes: >>> Sorry

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

On Sun, Jul 19, 2015 at 8:58 AM Ethan Furman wrote: > On 07/19/2015 02:22 AM, s.krah wrote: > > Ein Sa, 18 Jul 2015 15:35:05 + *Stephen J. Turnbull hat > geschrieben > >> s.krah writes: > > >>> Sorry, that amounts to twisting my words. > >> > >> Let's not play the dozens here. That

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

On 07/19/2015 11:11 AM, Terry Reedy wrote: Given that the issue is one of only partial reversion, and that a new patch would therefore be needed, I also think that some fuss would have been avoided if one of the initial objectors had done what you did, or volunteered to write a new patch, or

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

* Ron Adam [2015-07-19 11:17:10 -0400]: > I had to look at the source to figure out what this thread was really all > about. > > Basically it looks to me the purpose of adding "assret" is to add an "alias > check" for "unsafe" methods. It doesn't actually add an "alias". It allows > a developer

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

On 7/19/2015 11:52 AM, Ethan Furman wrote: On 07/18/2015 05:13 PM, Nick Coghlan wrote: However, from the core developer side [...] Participants Core Dev? Position on "assret" ----- Dima Tismek no

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

On 07/19/2015 11:52 AM, Ethan Furman wrote: Seems to me a lot of fuss could have been avoided by just acknowledging that a mistake may have been made, and asking for patches if anybody cared enough about it. I'm not sure it's a mistake, but it may not be the best way to do what the "alias ch

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

On 07/19/2015 02:22 AM, s.krah wrote: Ein Sa, 18 Jul 2015 15:35:05 + *Stephen J. Turnbull hat geschrieben s.krah writes: Sorry, that amounts to twisting my words. Let's not play the dozens here. That just extends the thread to no point. Indeed. I'll just filter you from n

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

On 07/18/2015 01:11 AM, Victor Stinner wrote: For the discussion on "assret", I'm surprised how much people replied. The mock maintainer, Michael Foord, replied: it was an explicit request from users... Users ask for lots of things that don't make it into the stdlib. -- ~Ethan~

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

On 07/18/2015 05:13 PM, Nick Coghlan wrote: However, from the core developer side [...] Participants Core Dev? Position on "assret" ----- Dima Tismek no-1 Xavier Morel no-

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

On 07/16/2015 07:48 PM, Antoine Pitrou wrote: On Fri, 17 Jul 2015 11:35:53 +1200 Alexander wrote: > >I do not want to read mistyped code from other developers and try to >guess whether it will work properly or not. You don't have to guess anything. If it's mistyped, either it raises Attrib

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

Ein Sa, 18 Jul 2015 15:35:05 + Stephen J. Turnbull hat geschrieben s.krah writes: >> Sorry, that amounts to twisting my words. > Let's not play the dozens here. That just extends the thread to no point. Indeed. I'll just filter you from now on. St

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

On 18 Jul 2015 1:19 pm, "Nick Coghlan" wrote: > I'm with Antoine in wondering why we even bother with contributing when the thanks we can expect is for people to feel entitled to demand we spend hours of our time debating trivial details Sorry, I crossed a line there - I know everyone posting to

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

s.krah writes: > Sorry, that amounts to twisting my words. Let's not play the dozens here. That just extends the thread to no point. > It would be a great loss if he really stops and I hope he'll > reconsider. I agree with both points. I don't think anybody disagrees, so let's not belabor

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

Stephen J. Turnbull wrote: >> Hypothetically speaking, I'd wager that someone writing an >> industrial strength concurrent garbage collector is *far more >> likely* to share Antoine's attitude. > I hope not. It's one thing to wish that one can be surrounded by > pee

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

s.krah writes: > I don't think growing committer numbers is CPython's #1 problem. Maybe not; not being a committer I don't have a strong opinion myself. However, committers, and especially the group qualified for the BD1P role, regularly post wishes for more senior developers to these lists. >

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

Ein Sa, 18 Jul 2015 04:34:19 + Stephen J. Turnbull hat geschrieben Antoine Pitrou writes: > [...] is amongst the reasons why I'm stopping contributing to > CPython. > We'll miss your code. But you're only one committer, even if you've > contributed mo

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

Hi Antoine, I'm really sad to read your message. Antoine is one of the most active Python core developer and it would be a big loss if he really stops contributing. Antoine helped me to stop the drug called "micro optimization", he always has good advices on the Python development. I tried to sta

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

Antoine Pitrou writes: > Frankly, this kind of inept discussion, I think you misunderstand what's going on. The people who advocate removal of a gratuitous special case may lack your perspective, but they're not incompetent to understand it. Specifically, you have a senior committer's perspect

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

On 18 July 2015 at 15:19, Nick Coghlan wrote: > > This change *doesn't really matter* in the grand scheme things, but would > require a non-zero amount of time and effort to reverse, so unless you're > offering one of the unittest maintainers a contract gig to change it back, > let it go. s/unit

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

On 18 Jul 2015 10:40 am, "Ben Finney" wrote: > > Nick Coghlan writes: > > > On 17 July 2015 at 08:30, Ben Finney wrote: > > > By definition, advocating to not add cruft to an API is going to be in > > > advance of being bitten by those additions. > > > > That's not what people are doing. Folks a

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

Nick Coghlan writes: > On 17 July 2015 at 08:30, Ben Finney wrote: > > By definition, advocating to not add cruft to an API is going to be in > > advance of being bitten by those additions. > > That's not what people are doing. Folks are actually arguing for > *restoring* the ability to mock out

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

On 07/17/2015 05:11 PM, Nick Coghlan wrote: Do NOT spend days nitpicking tiny details of work that has already been done to the point where people are wondering why they bother giving the gift of their time and contributions to our community. You mean like you keep expressing dismay and surpr

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

On 18 Jul 2015 8:13 am, "Ethan Furman" wrote: > > On 07/16/2015 11:30 PM, Nick Coghlan wrote: > >> On 17 July 2015 at 08:30, Ben Finney wrote: > > >>> By definition, advocating to not add cruft to an API is going to be in >>> advance of being bitten by those additions. >> >> >> That's not what peo

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

On 18/07/2015 01:00, Ryan Gonzalez wrote: I am tempted to reply with a slightly sarcastic message involving a cookie... I'm not tempted, I will ask, what the hell are you on about? On July 17, 2015 6:40:21 PM CDT, Antoine Pitrou wrote: Frankly, this kind of inept discussion, where a b

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

I am tempted to reply with a slightly sarcastic message involving a cookie... On July 17, 2015 6:40:21 PM CDT, Antoine Pitrou wrote: > >Frankly, this kind of inept discussion, where a bunch of folks get hung >up about an extremely minor design decision (who cares whether "assret" >is being specia

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

Frankly, this kind of inept discussion, where a bunch of folks get hung up about an extremely minor design decision (who cares whether "assret" is being special-cased or not? in the actual world, not the fantasy world of righteous indignation and armchair architects?), is amongst the reasons why I

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

On 07/16/2015 11:30 PM, Nick Coghlan wrote: On 17 July 2015 at 08:30, Ben Finney wrote: By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. That's not what people are doing. Folks are actually arguing for *restoring* the ability

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

Nothing huge to add, and I'm not experienced using mock. But the special handling of 'assret' as a "misspelling of 'assert'" definitely strikes me as a wart also. That sort of thing really has no place in a library itself, but rather only in a linter. On Fri, Jul 17, 2015 at 9:20 AM, Steven D'Ap

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

On Fri, Jul 17, 2015 at 04:37:04PM +1000, Nick Coghlan wrote: > The specific typo that is checked is the only one that changes the > spelling without also changing the overall length and shape of the > word. I don't think your comment above is correct. assert => aasert aseert azzert essert a

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

On 17 July 2015 at 09:35, Alexander wrote: >> By the way, I've also been bitten by this several times, so I >> appreciate the desire to at least warn users (or raise an exception, or >> whatever). > > It is not an intention to make tests more robust. It is the > implementation, which is questionab

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

On 17 July 2015 at 08:30, Ben Finney wrote: > By definition, advocating to not add cruft to an API is going to be in > advance of being bitten by those additions. That's not what people are doing. Folks are actually arguing for *restoring* the ability to mock out method names starting with "assre

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

On 17 Jul 2015 08:34, "Michael Foord" wrote: > > > > On Wednesday, 15 July 2015, Robert Collins wrote: > > On 15 July 2015 at 12:59, Nick Coghlan wrote: > >> > >> There is zero urgency here, so nothing needs to change for 3.5. > >> Robert's plan is a fine one to propose for 3.6 (and the PyPI moc

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

On 07/16/2015 04:48 PM, Antoine Pitrou wrote: On Fri, 17 Jul 2015 11:35:53 +1200 Alexander wrote: I do not want to read mistyped code from other developers and try to guess whether it will work properly or not. You don't have to guess anything. If it's mistyped, either it raises AttributeErro

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

On Fri, 17 Jul 2015 11:35:53 +1200 Alexander wrote: > > I do not want to read mistyped code from other developers and try to > guess whether it will work properly or not. You don't have to guess anything. If it's mistyped, either it raises AttributeError (because it starts with "assert_"), or it

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

> By the way, I've also been bitten by this several times, so I > appreciate the desire to at least warn users (or raise an exception, or > whatever). It is not an intention to make tests more robust. It is the implementation, which is questionable at least. I actually still hope that the whole th

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

On Wed, 15 Jul 2015 07:40:57 +1200 Robert Collins wrote: > On 15 July 2015 at 07:39, Paul Moore wrote: > > On 14 July 2015 at 20:27, Robert Collins wrote: > > >>> In effect, this patch is "reserving" all attributes starting with > >>> "assert" or "assret" as actual methods of the mock object,

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

On Wed, 15 Jul 2015 20:39:37 +1200 Robert Collins wrote: > On 15 July 2015 at 19:17, Antoine Pitrou wrote: > > On Wed, 15 Jul 2015 10:22:14 +1200 > > Robert Collins wrote: > >> > >> For clarity, I think we should: > >> - remove the assret check, it is I think spurious. > >> - add a set of func

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

On Fri, 17 Jul 2015 08:30:59 +1000 Ben Finney wrote: > Antoine Pitrou writes: > > > On Fri, 17 Jul 2015 06:59:16 +1000 > > Ben Finney wrote: > > > > > > +1. > > > > > > These checks are a good thing, but they belong in a linter tool not as > > > aliases in the API. > > > > Practicality beats

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

From: Python-Dev on behalf of Ben Finney Sent: Thursday, July 16, 2015 15:59 To: python-dev@python.org Subject: Re: [Python-Dev] How far to go with user-friendliness > Ethan Furman writes: > > > On 07/16/2015 01:29 PM, Michael Foord wrote: > > > On Tuesday, 14 July

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

Antoine Pitrou writes: > On Fri, 17 Jul 2015 06:59:16 +1000 > Ben Finney wrote: > > > > +1. > > > > These checks are a good thing, but they belong in a linter tool not as > > aliases in the API. > > Practicality beats purity. Unless you have been actually *bitten* by > those checks I don't thi

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

On Fri, 17 Jul 2015 06:59:16 +1000 Ben Finney wrote: > > +1. > > These checks are a good thing, but they belong in a linter tool not as > aliases in the API. Practicality beats purity. Unless you have been actually *bitten* by those checks I don't think there's any serious reason to complain.

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

Ethan Furman writes: > On 07/16/2015 01:29 PM, Michael Foord wrote: > > On Tuesday, 14 July 2015, Christie Wilson wrote: > > >> Unless the line silently executes and they don't notice the mistake for > >> years :'( > > > > Indeed. This has been a problem with mock, misspelled (usually > > misre

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

On 07/16/2015 01:29 PM, Michael Foord wrote: On Tuesday, 14 July 2015, Christie Wilson wrote: Unless the line silently executes and they don't notice the mistake for years :'( Indeed. This has been a problem with mock, misspelled (usually misremembered) assert methods silently did nothing.

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

On Wednesday, 15 July 2015, Robert Collins wrote: > On 15 July 2015 at 12:59, Nick Coghlan wrote: >> >> There is zero urgency here, so nothing needs to change for 3.5. >> Robert's plan is a fine one to propose for 3.6 (and the PyPI mock >> backport). > > Right - the bad API goes back to the very

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

On Tuesday, 14 July 2015, Christie Wilson wrote: >> If people do misspell it, I think they do learn not to in after it happens a few times. > > Unless the line silently executes and they don't notice the mistake for years :'( Indeed. This has been a problem with mock, misspelled (usually misremem

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

On 15 July 2015 at 19:17, Antoine Pitrou wrote: > On Wed, 15 Jul 2015 10:22:14 +1200 > 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.as

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

On Wed, 15 Jul 2015 10:22:14 +1200 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 PendingDepr

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

On 15 July 2015 at 12:59, Nick Coghlan wrote: > > There is zero urgency here, so nothing needs to change for 3.5. > Robert's plan is a fine one to propose for 3.6 (and the PyPI mock > backport). Right - the bad API goes back to the very beginning. I'm not planning on writing the new thing I sketc

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

On 15 July 2015 at 08:58, Berker Peksağ wrote: > On Wed, Jul 15, 2015 at 1:22 AM, Robert Collins >> 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

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

On 14/07/2015 23:22, 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 mov

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

On Wed, Jul 15, 2015 at 1:22 AM, Robert Collins wrote: > On 15 July 2015 at 10:05, Ethan Furman wrote: >> On 07/14/2015 02:53 PM, Robert Collins wrote: > ... I don't think unittest can protect its users from such things. >>> >>> >>> It can't, but there is a sliding scale of API usability, an

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

On Tue, Jul 14, 2015 at 3:22 PM Robert Collins wrote: > On 15 July 2015 at 10:05, Ethan Furman wrote: > > On 07/14/2015 02:53 PM, Robert Collins wrote: > ... > >>> I don't think unittest can protect its users from such things. > >> > >> > >> It can't, but there is a sliding scale of API usabilit

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

On 2015-07-14 23:05, Ethan Furman wrote: On 07/14/2015 02:53 PM, Robert Collins wrote: On 15 July 2015 at 09:41, A.M. Kuchling wrote: On Tue, Jul 14, 2015 at 09:53:33AM -0700, Ethan Furman wrote: Part of writing tests is making sure they fail (and for the right reason) -- proper testing of t

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

On 15 July 2015 at 10:05, Ethan Furman wrote: > On 07/14/2015 02:53 PM, Robert Collins wrote: ... >>> I don't think unittest can protect its users from such things. >> >> >> It can't, but there is a sliding scale of API usability, and we should >> try to be up the good end of that :). > > > I hope

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

On 07/14/2015 02:53 PM, Robert Collins wrote: On 15 July 2015 at 09:41, A.M. Kuchling wrote: On Tue, Jul 14, 2015 at 09:53:33AM -0700, Ethan Furman wrote: Part of writing tests is making sure they fail (and for the right reason) -- proper testing of the tests would reveal such a typo. And t

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

On 15 July 2015 at 09:41, A.M. Kuchling wrote: > On Tue, Jul 14, 2015 at 09:53:33AM -0700, Ethan Furman wrote: >> Part of writing tests is making sure they fail (and for the right reason) -- >> proper testing of the tests would reveal such a typo. > > And there are other failure modes for writing

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

On Tue, Jul 14, 2015 at 09:53:33AM -0700, Ethan Furman wrote: > Part of writing tests is making sure they fail (and for the right reason) -- > proper testing of the tests would reveal such a typo. And there are other failure modes for writing tests that succeed but are not testing what you think.

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

On 15 July 2015 at 07:39, Paul Moore wrote: > On 14 July 2015 at 20:27, Robert Collins wrote: >>> In effect, this patch is "reserving" all attributes starting with >>> "assert" or "assret" as actual methods of the mock object, and not >>> mocked attributes. >> >> Yes, and thats ugly. OTOH it cau

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

On 14 July 2015 at 20:27, Robert Collins wrote: > Well. > > I'd go further and just separate the APIs. > > mock.assert_called_with(a_mock, *args, **kwargs) > > mock can know how to poke under the covers (e.g. using > __Mock_assert_called_with) without leaking it into the users objects. As someone

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

On 14/07/2015 19:11, Terry Reedy wrote: To many, the beauty of Python is that it is relatively clean and simple, and not filled with hundreds of nitpicky exceptions and special cases. Being BDFL for a module should not be a license to add junk like this. +1. Speaking as someone who has t

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

On 15 July 2015 at 02:06, Paul Moore wrote: > On 14 July 2015 at 14:51, Florian Bruhin wrote: >> * Steven D'Aprano [2015-07-14 23:41:56 +1000]: ... >> With the patch, an AttributeError is raised if you call something >> starting with assert or assret instead. > > In retrospect, this seems like a

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

On 07/14/2015 02:39 PM, Nick Coghlan wrote: > Drawing the line at only rejecting "assert_" *would* have been a > reasonable alternative design choice, but it isn't the one Kushal and > Michael made, and there isn't a compelling argument in favour of > changing the implementation of the new guard t

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

On 7/14/2015 8:39 AM, Nick Coghlan wrote: On 14 July 2015 at 22:06, Dima Tisnek wrote: Thus the question, how far should Python go to detect possible erroneous user behaviour? Granted it is in tests only, but why not detect assrte, sasert, saster and assrat? Drawing the line at only rejecti

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

On 07/14/2015 12:36 PM, Christie Wilson wrote: If people do misspell it, I think they do learn not to after it happens a few times. Unless the line silently executes and they don't notice the mistake for years :'( Yes, and I'm concerned that allowing it in one location may bring abo

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

On 07/14/2015 07:06 AM, Paul Moore wrote: On 14 July 2015 at 14:51, Florian Bruhin wrote: On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote: https://bugs.python.org/issue21238 introduces detection of missing/misspelt mock.assert_xxx() calls on getattr level in Python 3.5 Michael an

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

> > If people do misspell it, I think they do learn not to in after it happens > a few times. Unless the line silently executes and they don't notice the mistake for years :'( On Tue, Jul 14, 2015 at 9:15 AM, Ron Adam wrote: > > > On 07/14/2015 09:41 AM, Steven D'Aprano wrote: > >> On Tue, Jul

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

On 07/14/2015 09:41 AM, Steven D'Aprano wrote: On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote: >https://bugs.python.org/issue21238 introduces detection of >missing/misspelt mock.assert_xxx() calls on getattr level in Python >3.5 > >Michael and Kushal are of the opinion that "assr

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

On Tue, Jul 14, 2015 at 5:06 AM, Dima Tisnek wrote: > https://bugs.python.org/issue21238 introduces detection of > missing/misspelt mock.assert_xxx() calls on getattr level in Python > 3.5 It was controversial when it got committed too. Discussions happened in python-committers and IRC. Michael

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

On Tue, Jul 14, 2015 at 5:00 PM, Steven D'Aprano wrote: > On Tue, Jul 14, 2015 at 11:09:50PM +1000, Nick Coghlan wrote: > >> Dima's right that the main defence against this kind of error is >> actually linters and IDEs, but detecting this particular one at >> runtime is harmless, so there's no par

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

On 14 July 2015 at 14:51, Florian Bruhin wrote: > * Steven D'Aprano [2015-07-14 23:41:56 +1000]: >> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote: >> > https://bugs.python.org/issue21238 introduces detection of >> > missing/misspelt mock.assert_xxx() calls on getattr level in Python

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

On Tue, Jul 14, 2015 at 11:09:50PM +1000, Nick Coghlan wrote: > Dima's right that the main defence against this kind of error is > actually linters and IDEs, but detecting this particular one at > runtime is harmless, so there's no particular reason *not* to do it > when it's possible to construct

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

On Tue, Jul 14, 2015 at 11:51 PM, Florian Bruhin wrote: > However, it also has some special methods to see if it has been > called: > > >>> m.assert_called_with() > [...] > AssertionError: Expected call: mock() > Not called I suppose it's too late to change this so these aren't me

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

* Steven D'Aprano [2015-07-14 23:41:56 +1000]: > On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote: > > https://bugs.python.org/issue21238 introduces detection of > > missing/misspelt mock.assert_xxx() calls on getattr level in Python > > 3.5 > > > > Michael and Kushal are of the opinio

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

On Jul 14, 2015, at 02:06 PM, Dima Tisnek wrote: >Michael and Kushal are of the opinion that "assret" is a common typo >of "assert" and should be supported in a sense that it also triggers >AttributeError and is not silently ignored like a mocked user >attribute. It's seems like a dubious special

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

On 2015-07-14 14:09, Nick Coghlan wrote: On 14 July 2015 at 22:53, Xavier Morel wrote: On 2015-07-14, at 14:39 , Nick Coghlan wrote: On 14 July 2015 at 22:06, Dima Tisnek wrote: Thus the question, how far should Python go to detect possible erroneous user behaviour? Granted it is in test

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

On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote: > https://bugs.python.org/issue21238 introduces detection of > missing/misspelt mock.assert_xxx() calls on getattr level in Python > 3.5 > > Michael and Kushal are of the opinion that "assret" is a common typo > of "assert" and should be

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

On 14 July 2015 at 22:53, Xavier Morel wrote: > > On 2015-07-14, at 14:39 , Nick Coghlan wrote: > >> On 14 July 2015 at 22:06, Dima Tisnek wrote: >>> Thus the question, how far should Python go to detect possible >>> erroneous user behaviour? >>> >>> Granted it is in tests only, but why not dete

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

On 2015-07-14, at 14:39 , Nick Coghlan wrote: > On 14 July 2015 at 22:06, Dima Tisnek wrote: >> Thus the question, how far should Python go to detect possible >> erroneous user behaviour? >> >> Granted it is in tests only, but why not detect assrte, sasert, saster >> and assrat? > > Because "

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

On 14 July 2015 at 22:06, Dima Tisnek wrote: > Thus the question, how far should Python go to detect possible > erroneous user behaviour? > > Granted it is in tests only, but why not detect assrte, sasert, saster > and assrat? Because "r" and "e" are right next to each other on a QWERTY keyboard

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

https://bugs.python.org/issue21238 introduces detection of missing/misspelt mock.assert_xxx() calls on getattr level in Python 3.5 Michael and Kushal are of the opinion that "assret" is a common typo of "assert" and should be supported in a sense that it also triggers AttributeError and is not sil