Re: [Python-Dev] Freeze exception for http://bugs.python.org/issue23661 ?

[Stephen J. Turnbull]

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 which
 > aspects a new RM was keeping, and which they wanted to try doing
 > differently.

It may be overkill, but my take would be a BCP PEP that summarizes
consensus best practice as well as option rules for releases, and then
each release would have its own PEP briefly describing any deviations
from the BCP, including both "I use variant A" and "I'm experimenting
with practice Alpha".  The former should be explained in the BCP, the
rationale for the latter in the release PEP.

___
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] Freeze exception for http://bugs.python.org/issue23661 ?

[Nick Coghlan]

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
>  > easier to find in the PEPs, and it would also make it clear which
>  > aspects a new RM was keeping, and which they wanted to try doing
>  > differently.
>
> It may be overkill, but my take would be a BCP PEP that summarizes
> consensus best practice as well as option rules for releases, and then
> each release would have its own PEP briefly describing any deviations
> from the BCP, including both "I use variant A" and "I'm experimenting
> with practice Alpha".  The former should be explained in the BCP, the
> rationale for the latter in the release PEP.

That would be the developer's guide, rather than a new PEP:
https://docs.python.org/devguide/devcycle.html

Unfortunately, I forgot that page existed earlier that, otherwise I
would have linked to it in my original reply.

Assuming the release managers agree explicitly referencing those
definitions from the release PEPs would be a good idea, I figure the
actual formatting of the additions would be their call.

As an example though, given Larry's approach of calling out his
experiments as Sphinx notes, it would likely be sufficient to just say
"See the `development lifecycle guide
`__ for
committer expectations during the different development stages".

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] How far to go with user-friendliness

[Dima Tisnek]

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

Google search for "assret" site:github.com yields 9 hits in total, of which:
1 (cliques.c) is a variable with intended spelling;
1 issue with a warning about the variable above
1 typo in a readme file
2 comments
1 email address
3 references to this very Python change

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?

Shouldn't linters and IDEs take care of this anyway?

d.
___
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

[Nick Coghlan]

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
(so it's an easy typo to make), and transposing them doesn't change
the overall shape of the word (so it's a hard typo to detect).

If you get the "a" or "t" out of position you change the shape of the
word so typos involving those are easier to detect visually, while "s"
and "e" are on different keyboard rows so typos at that point in the
word are less likely in the first place.

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 allow the typo'ed
prefix.

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

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

[Xavier Morel]

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 "r" and "e" are right next to each other on a QWERTY keyboard
> (so it's an easy typo to make), and transposing them doesn't change
> the overall shape of the word (so it's a hard typo to detect).

> If you get the "a" or "t" out of position you change the shape of the
> word so typos involving those are easier to detect visually, while "s"
> and "e" are on different keyboard rows so typos at that point in the
> word are less likely in the first place.

"sasert" fits these rules though.

___
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

[Nick Coghlan]

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 detect assrte, sasert, saster
>>> and assrat?
>>
>> Because "r" and "e" are right next to each other on a QWERTY keyboard
>> (so it's an easy typo to make), and transposing them doesn't change
>> the overall shape of the word (so it's a hard typo to detect).
>
>> If you get the "a" or "t" out of position you change the shape of the
>> word so typos involving those are easier to detect visually, while "s"
>> and "e" are on different keyboard rows so typos at that point in the
>> word are less likely in the first place.
>
> "sasert" fits these rules though.

That changes one of the end letters, and human word recognition is
generally pretty good at picking up changes to the first and last
letter. It's the ones in the middle that can be a problem, especially
when they're all the same height like "sser". And that's with typical
word recognition capabilities - my understanding is that for folks
that actually have dyslexia, discrepancies in letter order are even
harder to detect.

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 reasonable rationale for "Why this
particular typo?" and not all the other possible ways of transposing
adjacent letters in "assert".

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

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

[Steven D'Aprano]

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.


-- 
Steve
___
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

[MRAB]

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 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
(so it's an easy typo to make), and transposing them doesn't change
the overall shape of the word (so it's a hard typo to detect).



If you get the "a" or "t" out of position you change the shape of the
word so typos involving those are easier to detect visually, while "s"
and "e" are on different keyboard rows so typos at that point in the
word are less likely in the first place.


"sasert" fits these rules though.


That changes one of the end letters, and human word recognition is
generally pretty good at picking up changes to the first and last
letter. It's the ones in the middle that can be a problem, especially
when they're all the same height like "sser". And that's with typical
word recognition capabilities - my understanding is that for folks
that actually have dyslexia, discrepancies in letter order are even
harder to detect.

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 reasonable rationale for "Why this
particular typo?" and not all the other possible ways of transposing
adjacent letters in "assert".


What about "aasert"?

___
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

[Barry Warsaw]

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.

Cheers,
-Barry
___
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

[Florian Bruhin]

* 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 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.

Without using spec/autospec, a mock (by design) supports calling any
method on itself, which returns another mock:

>>> m = mock.Mock()
>>> m.eggs()

>>> m.bacon()


However, it also has some special methods to see if it has been
called:

>>> m.assert_called_with()
[...]
AssertionError: Expected call: mock()
Not called

Now because of that, if you do a typo, you won't notice in a test:

>>> m.assert_caled_with()


With the patch, an AttributeError is raised if you call something
starting with assert or assret instead.

Florian

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


pgpNFVsIA898p.pgp
Description: PGP signature
___
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

[Chris Angelico]

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 methods... ISTM
the problem is this collision of usage on attribute lookup - on the
one hand, it's conjuring mock method calls, and on the other, it's
implementing methods of its own.

ChrisA
___
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

[Steven D'Aprano]

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 reasonable rationale for "Why this
> particular typo?" and not all the other possible ways of transposing
> adjacent letters in "assert".

I've read this thread and the bug report and I'm not sure about this 
reasonable rationale. It seems like an utterly arbitrary choice to 
single out a single typo for special treatment while ignoring other 
equivalent typos, equally easy to make and equally difficult to spot. 
You even mentioned people with dyslexia yourself. As I understand it, 
dyslexics would find assert and assery equally hard to distinguish as 
assret versus assert, and t and y are next to each other on the same row 
of QWERTY keyboards.

BTW, am I missing something? The issue tracker says that the patch was 
accepted and a new "unsafe" keyword argument was added over a year ago, 
but that doesn't seem to be documented anywhere here:

https://docs.python.org/3/library/unittest.mock.html


-- 
Steve
___
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

[Paul Moore]

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
>> > 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.
>
> Without using spec/autospec, a mock (by design) supports calling any
> method on itself, which returns another mock:
>
> >>> m = mock.Mock()
> >>> m.eggs()
> 
> >>> m.bacon()
> 
>
> However, it also has some special methods to see if it has been
> called:
>
> >>> m.assert_called_with()
> [...]
> AssertionError: Expected call: mock()
> Not called
>
> Now because of that, if you do a typo, you won't notice in a test:
>
> >>> m.assert_caled_with()
> 
>
> With the patch, an AttributeError is raised if you call something
> starting with assert or assret instead.

In retrospect, this seems like a mistake in the design. Much like
namedtuple, mocks should carefully separate "actual" methods from
mocked ones (in the case of namedtuple, from tuple element names). If
Guido would let us use the time machine, I'd argue that maybe the
special methods should be _assert_called_with (or something similar).

Given that it's way too late to take that path, I can see the value of
trying to detect common errors. Particularly as the result of failing
to do so is an apparently-passing test.

In effect, this patch is "reserving" all attributes starting with
"assert" or "assret" as actual methods of the mock object, and not
mocked attributes.

Reserving "assert" seems fair.
Reserving "assret" seems odd, as people say why just this
mis-spelling? Is there any specific evidence that this typo happens
more often "in the wild" than any other? Given that the original issue
was raised by Michael Foord (the author of mock), I'd be inclined to
assume that he'd encountered evidence to that effect.

So ultimately I'm +1 on reserving "assert" (given that a more radical
fix isn't possible) and +0 on adding "assret" (simply on the basis
that someone more knowledgeable than me says it makes sense).

Paul
___
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

[Berker Peksağ]

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 particular reason *not* to do it
>> when it's possible to construct a reasonable rationale for "Why this
>> particular typo?" and not all the other possible ways of transposing
>> adjacent letters in "assert".
>
> I've read this thread and the bug report and I'm not sure about this
> reasonable rationale. It seems like an utterly arbitrary choice to
> single out a single typo for special treatment while ignoring other
> equivalent typos, equally easy to make and equally difficult to spot.
> You even mentioned people with dyslexia yourself. As I understand it,
> dyslexics would find assert and assery equally hard to distinguish as
> assret versus assert, and t and y are next to each other on the same row
> of QWERTY keyboards.
>
> BTW, am I missing something? The issue tracker says that the patch was
> accepted and a new "unsafe" keyword argument was added over a year ago,
> but that doesn't seem to be documented anywhere here:
>
> https://docs.python.org/3/library/unittest.mock.html

It's new in Python 3.5:
https://docs.python.org/3.5/library/unittest.mock.html#unittest.mock.Mock

"unsafe: By default if any attribute starts with assert or assret will
raise an AttributeError. Passing unsafe=True will allow access to
these attributes."

--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] How far to go with user-friendliness

[Senthil Kumaran]

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 is the BDFL of mock and felt alright with the change.

The sad part is once introduced and released, deprecation takes more time.
___
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

[Ron Adam]

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/archive%40mail-archive.com

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

[Christie Wilson]

>
> 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 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
___
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]

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


This is ridiculous.


With the patch, an AttributeError is raised if you call something
starting with assert or assret instead.



In effect, this patch is "reserving" all attributes starting with
"assert" or "assret" as actual methods of the mock object, and not
mocked attributes.

Reserving "assert" seems fair.


Agreed.


Reserving "assret" seems odd, as people say why just this
mis-spelling?


Refuse the temptation to guess.  Imagine that English is not the only language 
people use, and assret is either an actual word or logical abbreviation in some 
other language -- we just broke their tests.

Part of writing tests is making sure they fail (and for the right reason) -- 
proper testing of the tests would reveal such a typo.

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

[Ron Adam]

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 about a 
self fulfilling cause.  ie.. it will become a common error if it works in 
some places, but not others, while it's really not that common at the 
present time.


On the plus side.. having it in only one module, and only one place, 
probably won't be "that" bad or even that noticeable.  But maybe it can be 
a motivating factor for not doing similar things in other places.


Cheers,
   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/archive%40mail-archive.com

[Python-Dev] Cross compiling C-python 2.7.10 maintenance release for ARM on 64 bit x86_64 systems.

[Andrew Robinson]

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 problem, and there are apparently two different bugs;
1'st -- the Makefile doesn't disable PYTHONPATH for the arm libraries, 
and the x86 64 bit platform will attempt to link to the arm libraries 
during the compile process producing an wrong elf class error.


I found some online examples of cross compiling older versions of python 
which suggest adding a '-' before "PYTHONPATH' to prevent that from 
happening.  When I do that, it does compile -- but:


2'nd -- If I build python 2.7.10 with the above change, and with no 
debugging information or switches; it builds fine, but the resulting 
binary segfaults randomly on the Kobo reader, and will not import 
libraries without segfaulting.


If I build it with all available debugging information (-g3 -ggdb 
-gdwarf 4), the random segfaulting stops -- and instead, python raises 
an exception any time I attempt to import a library.


---
Python 2.7.10 (default, Jun 29 2015, 23:00:31)
[GCC 4.8.1 20130401 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
Traceback (most recent call last):
  File "", line 1, in 
ImportError: /mnt/user/lib/python2.7/lib-dynload/math.so: undefined 
symbol: Py_InitModule4

[40857 refs]
>>>
-

The symbol is indeed missing when I check with nm, and from what little 
information I can find online -- this appears to have something to do 
with a 32 bit vs. 64 bit incompatibility; eg: even though it's compiling 
for 32 bits ARM -- it still seems to be trying to use symbols associated 
with 64 bit processing.


I attempted to compile a 32 bit python interpreter on the build system, 
to make PYTHON_FOR_BUILD, and PGEN_FOR_BUILD ; but it didn't rectify the 
problem.


What is the proper way to cross compile 2.7.10 for 32 bit arm, on a 
x86_64 bit platform  / what am I doing wrong ?


-- 


Supplimentary information:

I'm using the linaro-gcc compiler from the kobolabs git repository, () 
eg: an arm-linux-gnueabihf-gcc on a 64 bit Slackware 14.1 machine with 
multilib x86 gcc available on the build system.


I have a separate 8GB partition with the Kobo kernel source code, 
stdlibs, etc. all installed from the github source and compiled to a 
target directory stored in an environment variable called ${DEVICEROOT} 
; All files found on the KOBO reader are located under ${DEVICEROOT} on 
the BUILD machine, and the arm GCC processor uses -I 
${DEVICEROOT}/usr/include and other appropriate paths so that GCC finds 
them naturally.


The following bash script shows the steps I used to compile Python with 
-- and it is followed by another bash script which sets up the compile 
environment variables, so you can see how the compiler environment is 
configured.


I have no problem compiling C source code in general using the Kobo 
compiler tools, and have compiled gnuplot, and bash, and several other 
packages with absolutely no problems.  It is only python which is not 
compiling correctly.


-- 



set -x

# A parser generator and build system version of python are supposed to be
# needed to run parts of the cross compilation;  I do see python used in 
the

# Makefile, but no references to a buid version of PGEN are defined,
# so I don't know if PGEN gets used or not -- but I build it anyway...
# As this is what receipies on the web say to do...

make distclean
(
. /etc/profile.d/32dev.sh
export LIBDIRSUFFIX=""
./configure # --build=x86_64-unknown-linux-gnu 
--host=i486-unknown-linux-gnu #(uncomment to build 32bit)


make Parser/pgen python
mv python python_for_build
mv Parser/pgen Parser/pgen_for_build
make distclean
)

# fix setup.py to handle installing to the target system's fake install
# directory found on the build system at $DEVICEROOT.

# We want utf-8, unicode terminal handling -- so make sure python compiles
# with ncursesw substituted for curses.

CURSESFLAGS=`pkg-config --cflags ncursesw`

# Configure python to be built
CFLAGS="${CFLAGS} ${CURSESFLAGS} -g3 -ggdb -gdwarf-4" ./configure 
--host=${CROSSTARGET} --build=i486-unknown-linux-gnu --enable-unicode 
--enable-shared --with-pydebug --prefix=/mnt/user --disable-ipv6 
--without-pymalloc ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no 
ac_cv_have_long_long_format=yes PYTHON_FOR_BUILD=${PWD}/python_for_build 
PGEN_FOR_BUILD=${PWD}/Parser/pgen_for_build


# Fix a bug in the Makefile
#

Re: [Python-Dev] Cross compiling C-python 2.7.10 maintenance release for ARM on 64 bit x86_64 systems.

[R. David Murray]

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 
> build system, for a 32 bit arm system.

To my understanding we don't yet fully support this (though we'd like
to), because we don't have a buildbot that regularly does cross compiles.
There are open issues in the tracker, perhaps you can vet and/or submit
some patches.[*]  Or contribute a buildbot?

--David

[8} See eg http://bugs.python.org/issue5404; I'm guessing there are others.
___
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

[Terry Reedy]

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 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 allow the typo'ed
prefix.


I strongly disagree that there is no compelling argument for reversal. 
Part of the reason for beta is so we have time to evaluate whether an 
enhancement is even a good idea. Many of us think special-casing 
'assret' is an awful one. This idea never got consensus or even majority 
approval.


1. It is false that 'assret' is necessarily a typo. Someone might quite 
legitimately use it as an attribute. Aside from the fact that it might 
be an *intentional* misspelling to avoid a clash with 'assert', I found 
the following on Google.

a. It appears to be both a (person) name (Turkey?) and a username.
b. It can be a contraction, abbreviation, or pair of acronym: ass-et 
ret-ention, ass-istant ret-ired (?), and something in connection with 
high-pressure oil lines.  Python usage is not restricted to 
English-speaking geeks.


2. It gives the impression that 'assret' is a legitimate alias for 
'assert'.  See 
https://stackoverflow.com/questions/31382895/any-core-real-reference-to-assret-as-alias-to-assert

This may have been what prompted Dima to go look on Google.

If the doc is revised to counter this impression, then I predict that 
this will join the list of Python warts and reasons to ridicule Python.


3. It violates Python design principles. 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.


--
Terry Jan Reedy

___
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

[Georg Brandl]

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 allow the typo'ed
> prefix.

I'd like to request installing "phyton" as a symlink to "python" in the
next version.

Georg

___
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] cpython: locals dictionary in PyRun_String

[Matthew Keeter]

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 custom object into locals that uses __getitem__ to 
track lookups.)

Thanks,
Matt

[1] https://docs.python.org/3.4/c-api/veryhigh.html#c.PyRun_StringFlags
[2] 
https://github.com/python/cpython/blob/master/Objects/frameobject.c#L628-L629___
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] cpython: locals dictionary in PyRun_String

[Brett Cannon]

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 it a bad idea to rely
> on this fact?
>
> (Context: I’m plugging a custom object into locals that uses __getitem__
> to track lookups.)
>

As you pointed out in the code, that's in the frame creation code and not
directly the PyRun_StringFlags code, so technically there is a chance for
us to insert a PyDict_CheckExact() call before hitting the code you linked
to.

As to whether we could loosen the documented restrictions so they are
guaranteed, it would be best to file an issue at bugs.python.org requesting
the restriction be officially loosened and if people are amenable then a
test to make sure no one accidentally breaks the API promise.
___
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

[Robert Collins]

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 mistake in the design. Much like
> namedtuple, mocks should carefully separate "actual" methods from
> mocked ones (in the case of namedtuple, from tuple element names). If
> Guido would let us use the time machine, I'd argue that maybe the
> special methods should be _assert_called_with (or something similar).

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.

> Given that it's way too late to take that path, I can see the value of
> trying to detect common errors. Particularly as the result of failing
> to do so is an apparently-passing test.

We can add a new API and gradually deprecate the old one. With the
presence of 'mock' as a rolling backport, this can be used by folk on
Python 3.3 and 3.4 so they don't get locked into one release of Python
or another.

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

> Reserving "assert" seems fair.
> Reserving "assret" seems odd, as people say why just this
> mis-spelling? Is there any specific evidence that this typo happens
> more often "in the wild" than any other? Given that the original issue
> was raised by Michael Foord (the author of mock), I'd be inclined to
> assume that he'd encountered evidence to that effect.
>
> So ultimately I'm +1 on reserving "assert" (given that a more radical
> fix isn't possible) and +0 on adding "assret" (simply on the basis
> that someone more knowledgeable than me says it makes sense).

Since assret is solely a 'you may not use this' case, I think we can
remove the check for that quite trivially, at any point we want to.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
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

[Rob Cliffe]

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 to work with a language full of 
nitpicky exceptions and special cases.  (Don't ask.)

Rob Cliffe
___
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

[Paul Moore]

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 who makes limited use of mock, and therefore whose opinion
shouldn't carry too much weight, I like this option.

>> Given that it's way too late to take that path, I can see the value of
>> trying to detect common errors. Particularly as the result of failing
>> to do so is an apparently-passing test.
>
> We can add a new API and gradually deprecate the old one. With the
> presence of 'mock' as a rolling backport, this can be used by folk on
> Python 3.3 and 3.4 so they don't get locked into one release of Python
> or another.

You're right - I hadn't thought of this approach.

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

Paul
___
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

[Robert Collins]

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.

-Rob



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
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] cpython: locals dictionary in PyRun_String

[Matthew Keeter]

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 loosening the restrictions in 
the C API (which will make it
match exec’s documented restrictions).

Thanks,
Matt

On Jul 14, 2015, at 2:47 PM, Brett Cannon  wrote:

> 
> 
> 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 it a bad idea to rely on 
> this fact?
> 
> (Context: I’m plugging a custom object into locals that uses __getitem__ to 
> track lookups.)
> 
> As you pointed out in the code, that's in the frame creation code and not 
> directly the PyRun_StringFlags code, so technically there is a chance for us 
> to insert a PyDict_CheckExact() call before hitting the code you linked to.
> 
> As to whether we could loosen the documented restrictions so they are 
> guaranteed, it would be best to file an issue at bugs.python.org requesting 
> the restriction be officially loosened and if people are amenable then a test 
> to make sure no one accidentally breaks the API promise. 

___
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

[A.M. Kuchling]

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.  For example, you might re-use the
same method name:

   def test_connection(self):
   # Never executed
   ...

   ... 200 lines and 10 other test methods later ...

   def test_connection(self):
   ...

Or misuse assertRaises:

   with self.assertRaises(TypeError):
   1 + "a"
   # Second statement never reached
   [] + 'b'

I don't think unittest can protect its users from such things.

--amk
___
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

[Robert Collins]

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 tests that succeed but
> are not testing what you think.  For example, you might re-use the
> same method name:
>
>def test_connection(self):
># Never executed
>...
>
>... 200 lines and 10 other test methods later ...
>
>def test_connection(self):
>...
>
> Or misuse assertRaises:
>
>with self.assertRaises(TypeError):
>1 + "a"
># Second statement never reached
>[] + 'b'
>
> 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 :).

http://sweng.the-davies.net/Home/rustys-api-design-manifesto

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
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]

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 there are other failure modes for writing tests that succeed but
are not testing what you think.  For example, you might re-use the
same method name:

def test_connection(self):
# Never executed
...

... 200 lines and 10 other test methods later ...

def test_connection(self):
...

Or misuse assertRaises:

with self.assertRaises(TypeError):
1 + "a"
# Second statement never reached
[] + 'b'

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 you're not suggesting that supporting misspellings, and thereby ruling 
out the proper use of an otherwise fine variable name, is at the good end of 
that scale?

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

[Robert Collins]

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 you're not suggesting that supporting misspellings, and thereby
> ruling out the proper use of an otherwise fine variable name, is at the good
> end of that scale?

I'm not supporting the misspelling thing - see my suggestion earlier
in this thread to move the mock assertions to standalone functions,
removing the bug in that area *entirely* and eventually removing the
check for method names starting with assert from mock entirely.

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.

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.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
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

[MRAB]

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 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.  For example, you might re-use the
same method name:

def test_connection(self):
# Never executed
...

... 200 lines and 10 other test methods later ...

def test_connection(self):
...

Or misuse assertRaises:

with self.assertRaises(TypeError):
1 + "a"
# Second statement never reached
[] + 'b'

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 you're not suggesting that supporting misspellings, and thereby ruling 
out the proper use of an otherwise fine variable name, is at the good end of 
that scale?


Somewhat OT, but did you know that the Unicode "Line_Break" property
has "Inseparable" as one of its possible values, and that "Inseperable"
is a permitted alias of it? 

___
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

[Brett Cannon]

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 usability, and we should
> >> try to be up the good end of that :).
> >
> >
> > I hope you're not suggesting that supporting misspellings, and thereby
> > ruling out the proper use of an otherwise fine variable name, is at the
> good
> > end of that scale?
>
> I'm not supporting the misspelling thing - see my suggestion earlier
> in this thread to move the mock assertions to standalone functions,
> removing the bug in that area *entirely* and eventually removing the
> check for method names starting with assert from mock entirely.
>
> 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.
>
> 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.
>

+1 from me
___
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

[Berker Peksağ]

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, and we should
>>> try to be up the good end of that :).
>>
>>
>> I hope you're not suggesting that supporting misspellings, and thereby
>> ruling out the proper use of an otherwise fine variable name, is at the good
>> end of that scale?
>
> I'm not supporting the misspelling thing - see my suggestion earlier
> in this thread to move the mock assertions to standalone functions,
> removing the bug in that area *entirely* and eventually removing the
> check for method names starting with assert from mock entirely.
>
> 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.
>
> 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.

+1, but I think we need to get Larry's approval for the steps 2 and 3
because 3.5 is in feature-freeze mode.

--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] How far to go with user-friendliness

[Mark Lawrence]

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 move the PendingDeprecation to Deprecated
  - in 3.7 remove the Mock.assert* functions and the check for method
names beginning with assert entirely.

-Rob


+1 from me as not even Baldrick could do better, see 
https://en.wikipedia.org/wiki/Baldrick :)


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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] cpython: locals dictionary in PyRun_String

[Nick Coghlan]

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 object).

I was about to post about that. exec used to also require that locals
be exactly a dictionary, so my suspicion is that we simply missed
updating the PyRun_SimpleString docs when the constraint was removed
from the underlying frame execution code.

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

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

[Nick Coghlan]

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 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.
>
> +1, but I think we need to get Larry's approval for the steps 2 and 3
> because 3.5 is in feature-freeze mode.

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).

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. If we're putting folks at
risk of losing data or otherwise having their systems compromised,
then by all means yell loudly, but for anything less, remember:

* it's almost certainly not urgent
* tolerating the occasional design decision we dislike won't ruin our lives
* a red bikeshed will still shelter our bikes, even if we'd have preferred blue
* it's just software, so we can put a blue wrapper around the red
bikeshed if we prefer it

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] Why wasn't I consulted [was How far to go with user-friendliness]

[Steven D'Aprano]

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 than that.

OpenSource is not just a family of licences. It is also a social 
movement, a culture, even a brand. We spend a lot of effort trying to 
get people to care, not just intellectually but also emotionally, and 
then when they react emotionally we're dismissive and tell them they're 
being obnoxious. Maybe they are, but if so, that's the price you pay for 
having people care.


-- 
Steve
___
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] Consenting adults considered beneficial [was: How far to go with user-friendliness]

[Stephen J. Turnbull]

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 fixing or a permitted-to-
consenting-adults behavior.  IMO, it's a bad idea to institutionalize
that kind of bikeshedding, especially when such "fixes" involve
overriding user choices that are permitted everywhere else.

Arbitrary choices that *some* users want to be protected from ("stop
me before I 'assret' again!") belong in linters, not in Python or the
stdlib.

To be frank, I think you have the Pythonic approach exactly backwards
here (though I am no authority on Pythonicity).  ISTM that in general
Python takes the attitude that if a particular "mis-use" seems to be
common, then we should figure out what it is about Python that
encourages that "mistake", or makes an otherwise arbitrary user choice
into a "mistake", and fix Python -- not restrict users.

Of course that's not always possible, but that's the first choice
AIUI.
___
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] Consenting adults considered beneficial [was: How far to go with user-friendliness]

[Robert Collins]

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 time a new fix is proposed, as
> to whether it's a mis-use that deserves fixing or a permitted-to-
> consenting-adults behavior.  IMO, it's a bad idea to institutionalize
> that kind of bikeshedding, especially when such "fixes" involve
> overriding user choices that are permitted everywhere else.

I'm thoroughly confused by this.

> Arbitrary choices that *some* users want to be protected from ("stop
> me before I 'assret' again!") belong in linters, not in Python or the
> stdlib.

I agree with this.

> To be frank, I think you have the Pythonic approach exactly backwards
> here (though I am no authority on Pythonicity).  ISTM that in general
> Python takes the attitude that if a particular "mis-use" seems to be
> common, then we should figure out what it is about Python that
> encourages that "mistake", or makes an otherwise arbitrary user choice
> into a "mistake", and fix Python -- not restrict users.
>
> Of course that's not always possible, but that's the first choice
> AIUI.

And these two paragraphs confuse me again.

Lets be really specific here.

Mock today has the following behaviour:
x = Mock()
x.foo()
x.bar()
...

all will just work and are mock methods that magically appear on demand.

And it includes some methods:
x.assert_called_with()

which are not mock methods, can't be mocked, and if you make a typo
you got *no* signal back to say that you'd messed up, until the patch
that added assert_ and assret_ prefix checking was added.

Which part of that API is Pythonic?

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.

I then gave an plan, for this case, which appears to have been
enthusiastically recieved by a bunch of long-time Python devs.

In what way is that unPythonic behaviour or design?

Confusedly-yrs.
Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
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

[Robert Collins]

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 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/archive%40mail-archive.com

Re: [Python-Dev] Consenting adults considered beneficial [was: How far to go with user-friendliness]

[Stephen J. Turnbull]

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

As far as I can tell, that sentence says it is permissible to "fix"
*user mis-use* of APIs, not the Python *APIs themselves*, and in
context it seemed to imply we *should* "fix" user code (perhaps by
invalidating it, as this feature in mock does), although you didn't
think that appropriate in this case.  So I completely misread your
intention despite the fact that we are in violent agreement.  I'm
sorry.

BTW, I changed Subject: precisely because I have no quarrel in
principle with the path you proposed to dealing with this issue in
mock, but lack the knowledge to comment on the practical feasibility
or desirability of your proposal.
___
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] Why wasn't I consulted [was How far to go with user-friendliness]

[Nick Coghlan]

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 energy.
>
> Nick makes a good point, but it's more complicated than that.
>
> OpenSource is not just a family of licences. It is also a social
> movement, a culture, even a brand. We spend a lot of effort trying to
> get people to care, not just intellectually but also emotionally, and
> then when they react emotionally we're dismissive and tell them they're
> being obnoxious. Maybe they are, but if so, that's the price you pay for
> having people care.

Aye, there's definitely a balance to be struck (and *me* telling folks
not to be passionate about topics they care about would be the height
of hypocrisy).

The kinds of questions I'm encouraging folks to ask themselves to help
calibrate our degree of concern are:

* What change are we asking for?
* What will the practical end user benefit of that change be?
* What will the near term maintainer cost of that change be?
* What will the long term maintainer benefit of that change be?

Those are the questions other people are going to want answers to
anyway, so it makes sense to ask them of ourselves first.

In the case of partially reverting this change to Mock objects, the answers are:

* "Restoring support for 'assret_*' methods on Mock objects"
* "End users will be able to access their 'assret_*' methods on Mock objects"
* "Maintainers would need to modify the check itself and the related
tests and documentation"
* "Maintainers won't have to explain why 'assret_*' methods are
blocked and other 'assert_*' typos aren't"

Thus, the case for spending *any* time on reversion is incredibly
weak, even if folks agree with the premise that blocking *any* typos
at all is undesirable.

Robert's suggestion is different, as it focuses on addressing the near
term concern with a solution that genuinely improves the API design:

* "Move Mock assertions from methods to module functions"
* "End users will gain from clear structural separation between
Mock'ed methods and Mock assertions, such that method name typos don't
result in silently ignoring test failures"
* "Maintainers would need to design the new API and device a
recommended transition plan for end users that accounts for end users
wanting to support multiple Python versions"
* "Once the migration from the old API to the new API is deemed
complete, maintainers should eventually find that the improved
separation of concerns between Mock'ed methods and Mock assertions
makes the module easier to maintain"

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