On 15 July 2015 at 12:07, Steven D'Aprano wrote:
> On Wed, Jul 15, 2015 at 10:59:50AM +1000, Nick Coghlan wrote:
>
>> Remember folks, "Why wasn't I consulted?!?!?!?" is one of the more
>> obnoxious behavours we can inflict on fellow open source maintainers
>> giving us the gift of their time and e
Robert Collins writes:
> I rejected an argument that just because some APIs are are
> intrinsically able to be misused, that we should not try to write
> better APIs.
Well, at least to me what you wrote was inconsistent with that
explanation of what you wanted to express:
>> What I am doing
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
On 15 July 2015 at 15:00, Stephen J. Turnbull wrote:
> Robert Collins writes:
>
> > What I am doing is rejecting the argument that because we can't fix
> > every mis-use users might make, we therefore should not fix the cases
> > where we can fix it.
>
> This involves a value judgment, every ti
Robert Collins writes:
> What I am doing is rejecting the argument that because we can't fix
> every mis-use users might make, we therefore should not fix the cases
> where we can fix it.
This involves a value judgment, every time a new fix is proposed, as
to whether it's a mis-use that deserv
On Wed, Jul 15, 2015 at 10:59:50AM +1000, Nick Coghlan wrote:
> Remember folks, "Why wasn't I consulted?!?!?!?" is one of the more
> obnoxious behavours we can inflict on fellow open source maintainers
> giving us the gift of their time and energy.
Nick makes a good point, but it's more complicat
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
On 15 July 2015 at 05:44, Matthew Keeter wrote:
> One more data point:
> On the Python side, exec has documentation
> (https://docs.python.org/3/library/functions.html#exec)
> that nicely reflects what’s going on in the frame code (where globals must
> be a dict but locals can be
> any mapping obj
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
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
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
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
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
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
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
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.
One more data point:
On the Python side, exec has documentation
(https://docs.python.org/3/library/functions.html#exec)
that nicely reflects what’s going on in the frame code (where globals must be a
dict but locals can be
any mapping object).
I’ll file a bug to see what people think about loose
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
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
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
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
On Tue, Jul 14, 2015 at 11:39 AM Matthew Keeter
wrote:
> The docs for PyRun_String say that both globals and locals should be
> dictionaries [1].
>
> However, digging into the source [2] shows me that locals doesn’t need to
> be a dictionary;
> it just needs to implement the mapping protocol. Is
The docs for PyRun_String say that both globals and locals should be
dictionaries [1].
However, digging into the source [2] shows me that locals doesn’t need to be a
dictionary;
it just needs to implement the mapping protocol. Is it a bad idea to rely on
this fact?
(Context: I’m plugging a cu
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
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
On Tue, 14 Jul 2015 10:22:05 -, Andrew Robinson
wrote:
> I'm trying to cross compile C-python 2.7.10 for an embedded system. (Eg:
> a Kobo reader).
> But there appears to be some bugs that do not allow the latest
> maintenance release of Python to correctly cross compile on an x86-64
> bui
Hi.
I'm trying to cross compile C-python 2.7.10 for an embedded system. (Eg:
a Kobo reader).
But there appears to be some bugs that do not allow the latest
maintenance release of Python to correctly cross compile on an x86-64
build system, for a 32 bit arm system.
I have researched the probl
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
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
>
> 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
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
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
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
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
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
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
* 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
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
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
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
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
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 "
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
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
On 14 July 2015 at 17:19, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > I wonder: should we start putting some of these process details for
> > the different phases in the release PEPs themselves? Larry sent a good
> > summary to python-committers for 3.5 a while back, but they'd be
>
Nick Coghlan writes:
> I wonder: should we start putting some of these process details for
> the different phases in the release PEPs themselves? Larry sent a good
> summary to python-committers for 3.5 a while back, but they'd be
> easier to find in the PEPs, and it would also make it clear w
46 matches
Mail list logo
