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
On 14 July 2015 at 17:19, Stephen J. Turnbull step...@xemacs.org 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
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
On 14 July 2015 at 22:53, Xavier Morel python-...@masklinn.net wrote:
On 2015-07-14, at 14:39 , Nick Coghlan ncogh...@gmail.com wrote:
On 14 July 2015 at 22:06, Dima Tisnek dim...@gmail.com wrote:
Thus the question, how far should Python go to detect possible
erroneous user behaviour?
On 2015-07-14, at 14:39 , Nick Coghlan ncogh...@gmail.com wrote:
On 14 July 2015 at 22:06, Dima Tisnek dim...@gmail.com 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
On 14 July 2015 at 22:06, Dima Tisnek dim...@gmail.com 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
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 a
On 14 July 2015 at 14:51, Florian Bruhin m...@the-compiler.org wrote:
* Steven D'Aprano st...@pearwood.info [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()
On Tue, Jul 14, 2015 at 11:51 PM, Florian Bruhin m...@the-compiler.org 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
On Tue, Jul 14, 2015 at 5:06 AM, Dima Tisnek dim...@gmail.com 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
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
On 2015-07-14 14:09, Nick Coghlan wrote:
On 14 July 2015 at 22:53, Xavier Morel python-...@masklinn.net wrote:
On 2015-07-14, at 14:39 , Nick Coghlan ncogh...@gmail.com wrote:
On 14 July 2015 at 22:06, Dima Tisnek dim...@gmail.com wrote:
Thus the question, how far should Python go to detect
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 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 case.
* Steven D'Aprano st...@pearwood.info [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
On Tue, Jul 14, 2015 at 5:00 PM, Steven D'Aprano st...@pearwood.info 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
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
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 ron3...@gmail.com wrote:
On 07/14/2015 09:41 AM, Steven D'Aprano wrote:
On
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
On 7/14/2015 8:39 AM, Nick Coghlan wrote:
On 14 July 2015 at 22:06, Dima Tisnek dim...@gmail.com 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
On Tue, Jul 14, 2015 at 11:39 AM Matthew Keeter matt.j.kee...@gmail.com
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
On 15 July 2015 at 09:41, A.M. Kuchling a...@amk.ca 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
On 07/14/2015 02:53 PM, Robert Collins wrote:
On 15 July 2015 at 09:41, A.M. Kuchling a...@amk.ca 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
On 14 July 2015 at 20:27, Robert Collins robe...@robertcollins.net 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
On 15 July 2015 at 02:06, Paul Moore p.f.mo...@gmail.com wrote:
On 14 July 2015 at 14:51, Florian Bruhin m...@the-compiler.org wrote:
* Steven D'Aprano st...@pearwood.info [2015-07-14 23:41:56 +1000]:
...
With the patch, an AttributeError is raised if you call something
starting with assert or
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.
On 15 July 2015 at 07:39, Paul Moore p.f.mo...@gmail.com wrote:
On 14 July 2015 at 20:27, Robert Collins robe...@robertcollins.net 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,
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
On 15 July 2015 at 10:05, Ethan Furman et...@stoneleaf.us 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
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
On 15 July 2015 at 08:58, Berker Peksağ berker.pek...@gmail.com 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
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 complicated
On 15 July 2015 at 15:00, Stephen J. Turnbull step...@xemacs.org 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,
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 a...@amk.ca 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
On Tue, Jul 14, 2015 at 3:22 PM Robert Collins robe...@robertcollins.net
wrote:
On 15 July 2015 at 10:05, Ethan Furman et...@stoneleaf.us 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
On 15 July 2015 at 05:44, Matthew Keeter matt.j.kee...@gmail.com 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
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 deserves
On Wed, Jul 15, 2015 at 1:22 AM, Robert Collins
robe...@robertcollins.net wrote:
On 15 July 2015 at 10:05, Ethan Furman et...@stoneleaf.us 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
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
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 is
On 15 July 2015 at 12:07, Steven D'Aprano st...@pearwood.info 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
On 15 July 2015 at 12:59, Nick Coghlan ncogh...@gmail.com 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
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 to
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
On Tue, 14 Jul 2015 10:22:05 -, Andrew Robinson andr...@r3dsolutions.com
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
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
46 matches
Mail list logo
