[Python-Dev] documentation / implementation question for subprocess.check_output
Hi All, Curious to see this in the docs for subprocess.check_output: "Do not use stderr=PIPE with this function as that can deadlock based on the child process error volume. Use Popen with the communicate() method when you need a stderr pipe." Given that check_output's implementation uses communicate(), how could stderr=PIPE cause a deadlock in a way that wouldn't happen if you called Popen.communicate() yourself? cheers, Chris ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] documentation / implementation question for subprocess.check_output
In which version? I don't see that phrase in the 3.5 docs. On Thu, Jul 16, 2015 at 9:52 AM, Chris Withers wrote: > Hi All, > > Curious to see this in the docs for subprocess.check_output: "Do not use > stderr=PIPE with this function as that can deadlock based on the child > process error volume. Use Popen with the communicate() method when you need > a stderr pipe." > > Given that check_output's implementation uses communicate(), how could > stderr=PIPE cause a deadlock in a way that wouldn't happen if you called > Popen.communicate() yourself? > > cheers, > > Chris > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] documentation / implementation question for subprocess.check_output
On 16 July 2015 at 20:35, Guido van Rossum wrote: > In which version? I don't see that phrase in the 3.5 docs. The equivalent note in 3.x is "Do not use stdout=PIPE or stderr=PIPE with this function. The child process will block if it generates enough output to a pipe to fill up the OS pipe buffer as the pipes are not being read from." I think Chris is right that it's a docs bug - the warning is applicable to subprocess.call and subprocess.check_call (which use Popen.wait), but not to subprocess.check_output (which uses Popen.communicate). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Where are bugs with the web site reported?
I have encountered this weird issue on Chrome for Android where scrolling up just a little causes the page to dart to the top. I was going to report it in the bug tracker, but I didn't see a label for the web site itself. Worst part is, this is stopping me from reading the humor page! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where are bugs with the web site reported?
On 7/16/2015 12:11 PM, Ryan Gonzalez wrote: I have encountered this weird issue on Chrome for Android where scrolling up just a little causes the page to dart to the top. I was going to report it in the bug tracker, but I didn't see a label for the web site itself. Worst part is, this is stopping me from reading the humor page! Sounds more like a bug in Chrome than on the site, unless it is repeatable using other browsers, or unless the site has Chrome-specific code. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where are bugs with the web site reported?
It's a known issue -- which I thought was fixed recently. I would have responded sooner, but I couldn't remember where website bugs are to be reported and figured someone would chime in with the link. I *don't* think it's bugs.python.org, though I could be wrong. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where are bugs with the web site reported?
On Thu, Jul 16, 2015 at 10:11 PM, Ryan Gonzalez wrote: > I have encountered this weird issue on Chrome for Android where scrolling up > just a little causes the page to dart to the top. I was going to report it > in the bug tracker, but I didn't see a label for the web site itself. > > Worst part is, this is stopping me from reading the humor page! Hi, Already reported at https://github.com/python/pythondotorg/issues/531 --Berker ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where are bugs with the web site reported?
On Thu, 16 Jul 2015 12:24:45 -0700, Glenn Linderman wrote: > On 7/16/2015 12:11 PM, Ryan Gonzalez wrote: > > I have encountered this weird issue on Chrome for Android where > > scrolling up just a little causes the page to dart to the top. I was > > going to report it in the bug tracker, but I didn't see a label for > > the web site itself. > > > > Worst part is, this is stopping me from reading the humor page! > > Sounds more like a bug in Chrome than on the site, unless it is > repeatable using other browsers, or unless the site has Chrome-specific > code. python.org bugs are *not* reported on bugs.python.org. I don't remember where they are reported...it's on github somewhere I think. The fact that it isn't obvious may be a good candidate for a bug report :) --David ___ Python-Dev mailing list Python-Dev@python.org 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
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 misremembered) assert methods silently did nothing. With this fix in place several failing tests were revealed in code bases! As for assret, it's the common misspelling people have told me about. It seems a ridiculous thing for people to get worked up about, but people enjoy getting worked up. Michael > 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 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 supported in a sense that it also triggers >AttributeError and is not silently ignored like a mocked user >attribute. > >I disagree >>> >>> I must admit I don't use mock so don't quite understand what is going on >>> in this bug report. But I don't imagine that anything good will come out >>> of treating*one* typo differently from all the other possible typos. >>> Why should "assret" be treated differently from other easy-to-make typos >>> like "asert", "assrt", "asset"? Or "assort", which is not only a >>> standard and common English word, but "e" and "o" are right next to each >>> other on Dvorak keyboards, making it an easy typo to make. >>> >>> Surely this is an obvious case where the Zen should apply. "Special >>> cases aren't special enough..." -- either all such typos raise >>> AttributeError, or they are all silent. >> >> I agree with Steven that it doesn't seem correct to not raise AttributeError here. >> >> For what it's worth, I have a life long sleep disorder and am a tarrable (<-- like this) speller because of it. I still don't want spell, or grammar, checkers to not report my mistakes. And I don't recall ever making the particular error of using "assret" in place of "assert". I'd be more likely to mispell it as "assirt" if I wasn't already so familiar with "assert". >> >> If people do misspell it, I think they do learn not to in after it happens a few times. >> >> Regards, >>Ron >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com > > > > -- > Christie Wilson -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org 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
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 beginning. I'm not planning I disagree it's a bad api. It's part of why mock was so easy to use and part of why it was so successful. With the new check for non-existent assert methods it's no longer dangerous and so doesn't need fixing. So -1 from me. Michael > on writing the new thing I sketched, though it should be straight > forward if someone wishes to do so. I'll probably file a ticket in the > tracker asking for it once this thread quiesces. > > -Rob > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org 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
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. With this fix in place several failing tests were revealed in code bases! This is good. :) As for assret, it's the common misspelling people have told me about. It seems a ridiculous thing for people to get worked up about, but people enjoy getting worked up. It's the only exercise some of us get. ;) On the serious side, Python is not a DWIM language, and making accommodations for a misspelling feels very DWIMish. As I said in an earlier email part of writing good tests is double-checking that a test is failing (and for the right reasons). And yes, I am guilty of writing bad tests, and getting bit by it, and no, I still don't want the testing framework (or any part of Python) guessing what I meant. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org 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
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 > > misremembered) assert methods silently did nothing. > > > > With this fix in place several failing tests were revealed in code bases! > > This is good. :) It's good that bugs were found. That does not argue for making an alias in the library, though; it better argues for those projects adding a linter check for the common misspellings. > > As for assret, it's the common misspelling people have told me > > about. It seems a ridiculous thing for people to get worked up > > about, but people enjoy getting worked up. Advocating for a clean API is ridiculous? That's a disturbing attitude to hear from a Python standard library contributor. > On the serious side, Python is not a DWIM language, and making > accommodations for a misspelling feels very DWIMish. As I said in an > earlier email part of writing good tests is double-checking that a > test is failing (and for the right reasons). And yes, I am guilty of > writing bad tests, and getting bit by it, and no, I still don't want > the testing framework (or any part of Python) guessing what I meant. +1. These checks are a good thing, but they belong in a linter tool not as aliases in the API. -- \ “You say “Carmina”, and I say “Burana”, You say “Fortuna”, and | `\I say “cantata”, Carmina, Burana, Fortuna, cantata, Let's Carl | _o__)the whole thing Orff.” —anonymous | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org 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
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. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where are bugs with the web site reported?
R. David Murray wrote: python.org bugs are *not* reported on bugs.python.org. I don't remember where they are reported...it's on github somewhere I think. The fact that it isn't obvious may be a good candidate for a bug report :) But... which bug tracker should it be reported to? :-) -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where are bugs with the web site reported?
Response from the Chrome devs: This site has JS that reacts to the viewport resize event from top controls showing by scrolling to the top. I guess the intent might be to scroll to the top when the phone rotates, and it overtriggers here. I don't think there's a short-term fix, but this seems like an interesting case to keep in mind while evolving viewport resize behaviors. On Thu, Jul 16, 2015 at 2:24 PM, Glenn Linderman wrote: > On 7/16/2015 12:11 PM, Ryan Gonzalez wrote: > > I have encountered this weird issue on Chrome for Android where scrolling > up just a little causes the page to dart to the top. I was going to report > it in the bug tracker, but I didn't see a label for the web site itself. > > Worst part is, this is stopping me from reading the humor page! > > > Sounds more like a bug in Chrome than on the site, unless it is repeatable > using other browsers, or unless the site has Chrome-specific code. > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > > -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ ___ Python-Dev mailing list Python-Dev@python.org 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
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 think there's any serious reason to complain. By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. Your position seems to be, then, that any complaint about additions to an API can be dismissed out of hand. I hope that's not what you mean, but I can't see what else you could be saying. -- \ “Of all classes the rich are the most noticed and the least | `\ studied.” —John Kenneth Galbraith, _The Age of Uncertainty_, | _o__) 1977 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org 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
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 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. > > > > > > With this fix in place several failing tests were revealed in code bases! > > > > This is good. :) > > It's good that bugs were found. That does not argue for making an alias > in the library, though; it better argues for those projects adding a > linter check for the common misspellings. > > > > As for assret, it's the common misspelling people have told me > > > about. It seems a ridiculous thing for people to get worked up > > > about, but people enjoy getting worked up. > > Advocating for a clean API is ridiculous? That's a disturbing attitude > to hear from a Python standard library contributor. > > > On the serious side, Python is not a DWIM language, and making > > accommodations for a misspelling feels very DWIMish. As I said in an > > earlier email part of writing good tests is double-checking that a > > test is failing (and for the right reasons). And yes, I am guilty of > > writing bad tests, and getting bit by it, and no, I still don't want > > the testing framework (or any part of Python) guessing what I meant. > > +1. > > These checks are a good thing, but they belong in a linter tool not as > aliases in the API. +1 > -- > \ “You say “Carmina”, and I say “Burana”, You say “Fortuna”, and | > `\I say “cantata”, Carmina, Burana, Fortuna, cantata, Let's Carl | > _o__)the whole thing Orff.” —anonymous | +1 000 000 ijs ___ Python-Dev mailing list Python-Dev@python.org 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
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 purity. Unless you have been actually *bitten* by > > those checks I don't think there's any serious reason to complain. > > By definition, advocating to not add cruft to an API is going to be in > advance of being bitten by those additions. This sounds very much like FUD to me. I specifically talked about being *actually* bitten by it, not speculating that you may one day be bitten by it without even giving any specifics as to why you think that, except some vague stance on purity. On the other hand, the maintainer mentioned there were concrete cases where some people's test suites were *helped* by the change. You may of course continue this theoretical argument, but I doubt doing so will sway anyone's opinion. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org 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
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 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. > > > > I think removing them is a bit too strong. There's software out there > > that would like to have cross-version-compatible test suites. > > Which they can do using 'mock'. You mean the backported version? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org 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
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, and not > >>> mocked attributes. > >> > >> Yes, and thats ugly. OTOH it caught hundreds of useless tests in > >> OpenStack when this got ported into mock 1.1.0. > > > > ... which I guess counts as strong evidence that this *is* a common > > typo, at least in certain contexts. > > For clarity: None of the caught failures were assret as far as I know. > They were things like assert_called_onec_with, or assert_called. 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). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org 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
> 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 thing is a joke. I do not want to read mistyped code from other developers and try to guess whether it will work properly or not. On Fri, Jul 17, 2015 at 11:18 AM, Antoine Pitrou wrote: > 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, and not >> >>> mocked attributes. >> >> >> >> Yes, and thats ugly. OTOH it caught hundreds of useless tests in >> >> OpenStack when this got ported into mock 1.1.0. >> > >> > ... which I guess counts as strong evidence that this *is* a common >> > typo, at least in certain contexts. >> >> For clarity: None of the caught failures were assret as far as I know. >> They were things like assert_called_onec_with, or assert_called. > > 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). > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/xr.lists%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org 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
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 doesn't do anything. So, in both cases, it *doesn't* work properly. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org 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
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 AttributeError (because it starts with "assert_"), or it doesn't do anything. So, in both cases, it *doesn't* work properly. Yes, but in the case of "assrt_*" it won't work properly and won't not work properly. And neither should "assret_*". -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org 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
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 mock > >> backport). > > > > Right - the bad API goes back to the very beginning. I'm not planning > > > I disagree it's a bad api. It's part of why mock was so easy to use and part of why it was so successful. With the new check for non-existent assert methods it's no longer dangerous and so doesn't need fixing. Could you help me understand how the presence of assert... on the mock vs in the mock module affected ease of use? -Rob ___ Python-Dev mailing list Python-Dev@python.org 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
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 "assret_*". I still don't know why anyone thinks restoring that would be a worthwhile use of a maintainers' time (or why they thinking arguing in favour of such a capability is a worthwhile use of theirs). None of the perspectives presented in this thread are new, although the apparent obsession over such a minor detail has made it abundantly clear that this kind of helper simply isn't worth the distraction it creates for maintainers, *regardless* of whether or not it helps end users. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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
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 questionable at least. I actually still hope > that the whole thing is a joke. > > I do not want to read mistyped code from other developers and try to > guess whether it will work properly or not. *Any* operation starting with "assret_*" on a Mock object will throw AttributeError in 3.5+. The only way to get it to *work* is to spell it properly. 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. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
