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

[s.krah]

 Ein Sa, 18 Jul 2015 15:35:05 + Stephen J. Turnbull 
 hat geschrieben  

s.krah writes: 
 
 >> Sorry, that amounts to twisting my words. 
 
> Let's not play the dozens here. That just extends the thread to no 
point.

Indeed.  I'll just filter you from now on.


Stefan Krah 
 



___
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] GetFinalPathNameByHandleW - what is the minimum windows version python-3.5 will support ?

[Vitaly Murashev]

 I've just found out that that on Windows internal implementation of 
python35.dll in posixmodule.c
uses winapi function GetFinalPathNameByHandleW

By the way from MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85%29.aspx

Minimum supported client
  Windows Vista [desktop apps only]

Minimum supported server
  Windows Server 2008 [desktop apps only]

Does it mean, that Python-3.5 doesn't support any windows versions prior 
"Windows Vista" and "Windows Server 2008" ?

Best regards,
Vitaly Murashev___
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] GetFinalPathNameByHandleW - what is the minimum windows version python-3.5 will support ?

[Tim Golden]

On 19/07/2015 13:10, Vitaly Murashev wrote:

I've just found out that that on Windows internal implementation of
python35.dll in posixmodule.c
uses winapi function GetFinalPathNameByHandleW

By the way from MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85%29.aspx

Minimum supported client
   Windows Vista [desktop apps only]

Minimum supported server
   Windows Server 2008 [desktop apps only]

Does it mean, that Python-3.5 doesn't support any windows versions prior
"Windows Vista" and "Windows Server 2008" ?


In essence: yes.

Python's support for Windows is outlined in PEP 11:

  https://www.python.org/dev/peps/pep-0011/#microsoft-windows

which establishes that Python drops support for a Windows platform when 
Microsoft does. WinXP (somewhat noisily) finished support last year:


  http://windows.microsoft.com/en-gb/windows/end-support-help

while Server 2003 -- more quietly; I had to go and look -- came out of 
extended support this month:


  https://support.microsoft.com/en-us/lifecycle?p1=3198

Since Python 3.5 will come out after both of those platforms have 
finished support, there's no guarantee that it will run without error on 
those systems.


Obviously, all earlier releases of Python -- including the 
long-term-supported 2.7 should continue to work. Any otherwise 
undocumented failure to work on older platforms should be raised as a bug.


TJG
___
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/16/2015 07:48 PM, Antoine Pitrou wrote:

On Fri, 17 Jul 2015 11:35:53 +1200
Alexander  wrote:

>
>I do not want to read mistyped code from other developers and try to
>guess whether it will work properly or not.



You don't have to guess anything. If it's mistyped, either it raises
AttributeError (because it starts with "assert_"), or it doesn't do
anything. So, in both cases, it*doesn't*  work properly.


I had to look at the source to figure out what this thread was really all 
about.


Basically it looks to me the purpose of adding "assret" is to add an "alias 
check" for "unsafe" methods.  It doesn't actually add an "alias".  It 
allows a developer to use a valid alias to avoid conflicting with methods 
starting with assert that will still work with the mock module.


The mock module says that when "unsafe" flag is set to True, it will not 
raise AssertionError for methods beginning with "assert" and "assret".  It 
doesn't specify what "unsafe" means, and why you would want to do that.


So first do this...

* Document "unsafe" in mock module.

I presume "unsafe" in this case means the method will not fail if an 
optimise flag is used because an assert in an assert method will not fail.


The problem I see is checking for "assert" by name convention is dubious to 
start with.  An method that begins with assert may not actually use 
"assert", and one's that don't may possibly use it.


A better way is to have a function in the inspect module that will return 
True if a function uses the "assert" keyword.


That is trickier than it sounds, because the optimize flag causes the 
asserts to be removed.  So it may require setting a flag on a function if 
it's source contained "assert".


With a reliable test for "assert", the check for an naming convention alias 
is not needed.



If I've still not quite got the gist of this issue, the please correct me.

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

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

[Ethan Furman]

On 07/18/2015 05:13 PM, Nick Coghlan wrote:


However, from the core developer side [...]


Participants  Core Dev? Position on "assret"
-----   
Dima Tismek   no-1
Xavier Morel  no-1
Florian Bruhinno ?
Mark Lawrence no?
Stephen J. Turnbull   no-.5 (?)
Alexander no-1
David Mertz   no-1
Ron Adam  no?
Christie Wilson   no+1 (?)
Ben Finneyno-1
Isaac Schwabacher no-1
MRAB  ?*-0 (?)

Michael Foord yes   +1
Antoine Pitrouyes   +1
Victor Stinneryes   +1 (?)
Nick Coghlan  yes   +1
Paul Mooreyes   +0
A.M. Kuchling yes   -0
Robert Collinsyes   -1
Brett Canon   yes   -.5 (?)
Berker Peksağ yes   -.5 (?)
Steven D'Aprano   yes   -1
Barry Warsaw  yes   -.5 (?)
Ethan Furman  yes   -1

Looks like this thread was pretty evenly split between core devs and non-core 
devs.

Looks like a definite majority of non-core devs, and at least a slight majority of core 
devs, think "assret" should be removed.

Apparently you do not speak for all core devs on this issue, so please don't 
pretend that you do.

Oh, and just a small tidbit of info -- it took longer to research and write this email 
than it did to write the patch to remove "assret" checking [1].

Seems to me a lot of fuss could have been avoided by just acknowledging that a 
mistake may have been made, and asking for patches if anybody cared enough 
about it.

--
~Ethan~


[1] http://bugs.python.org/issue24656
___
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/18/2015 01:11 AM, Victor Stinner wrote:


For the discussion on "assret", I'm surprised how much people replied. The mock 
maintainer,
 Michael Foord, replied: it was an explicit request from users...


Users ask for lots of things that don't make it into the stdlib.

--
~Ethan~
___
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/19/2015 02:22 AM, s.krah wrote:

 Ein Sa, 18 Jul 2015 15:35:05 + *Stephen J. Turnbull hat geschrieben 


s.krah writes:



Sorry, that amounts to twisting my words.


Let's not play the dozens here.  That just extends the thread to no point.


Indeed.  I'll just filter you from now on.


You may as well filter me too, then, because you are acting like an ass and I'm 
saying so.

--
~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/19/2015 11:52 AM, Ethan Furman wrote:

Seems to me a lot of fuss could have been avoided by just acknowledging
that a mistake may have been made, and asking for patches if anybody cared
enough about it.


I'm not sure it's a mistake, but it may not be the best way to do what the 
"alias check" does.   That is, check for "unsafe" methods that may use 
"assert" in methods that start with assert or assret.  It's a name 
convention check only.


The use of "assret" may be because a developer used it in place of assert 
for a large project to avoid overwriting inherited methods accidentally and 
asked for it.  (that was suggested in this thread at one point.)  But I'm 
not able to confirm that.  It does sound reasonable though.  The check for 
it doesn't auto correct anything or alter anything outside of how the mock 
responds to existing methods. So it's not as bad as it sounds.  (But not as 
good either.)


A possibly better alternative is to have a different way to check if 
functions and methods use "assert".  Then the check by name convention 
(which is not dependable anyway) isn't needed.


Possibly adding a function, uses_assert(...), to the inspect module would 
be good.   To allow that to work, may need a flag set on function objects 
if they contain assert even if the module is compiled in optimise mode. 
(Is it doable?  Or maybe there is another way?)


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

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

[Terry Reedy]

On 7/19/2015 11:52 AM, Ethan Furman wrote:

On 07/18/2015 05:13 PM, Nick Coghlan wrote:


However, from the core developer side [...]


Participants  Core Dev? Position on "assret"
-----   
Dima Tismek   no-1
Xavier Morel  no-1
Florian Bruhinno ?
Mark Lawrence no?
Stephen J. Turnbull   no-.5 (?)
Alexander no-1
David Mertz   no-1
Ron Adam  no?
Christie Wilson   no+1 (?)
Ben Finneyno-1
Isaac Schwabacher no-1
MRAB  ?*-0 (?)

Michael Foord yes   +1
Antoine Pitrouyes   +1
Victor Stinneryes   +1 (?)
Nick Coghlan  yes   +1
Paul Mooreyes   +0
A.M. Kuchling yes   -0
Robert Collinsyes   -1
Brett Canon   yes   -.5 (?)
Berker Peksağ yes   -.5 (?)
Steven D'Aprano   yes   -1
Barry Warsaw  yes   -.5 (?)
Ethan Furman  yes   -1


  Terry Reedy   yes   -1


Looks like this thread was pretty evenly split between core devs and
non-core devs.

Looks like a definite majority of non-core devs, and at least a slight
majority of core devs, think "assret" should be removed.

Apparently you do not speak for all core devs on this issue, so please
don't pretend that you do.


To be fair, I think Nick was speaking from the viewpoint of a core-dev 
who volunteers to review, edit, and commit a patch, and spends at least 
an hour doing so.  I do not believe he was pretending to speak for us 
collectively as post-commit reviewers.



Oh, and just a small tidbit of info -- it took longer to research and
write this email than it did to write the patch to remove "assret"
checking [1].

Seems to me a lot of fuss could have been avoided by just acknowledging
that a mistake may have been made, and asking for patches if anybody
cared enough about it.


I agree, and considered posting something nearly identical, but I was 
not ready to volunteer a patch.


Given that the issue is one of only partial reversion, and that a new 
patch would therefore be needed, I also think that some fuss would have 
been avoided if one of the initial objectors had done what you did, or 
volunteered to write a new patch, or had at least acknowledged that 
someone other than Michael could and should write the proposed new patch.


To me, the important issue is this: none of the people listed above are 
'stupid', and little of what we say seriously is 'stupid'.  Ditto for 
similar adjectives.  We should therefore give each other the benefit of 
the doubt (more than currently) when responding.


Bad: the patch (or in this case, a portion of it) is stupid.

Good (or certainly much better): I do not understand the rationale, or 
consider it inadequate.  It makes me queasy.  It looks like a step 
toward uglifying Python.


Bad: the objections to the patch are stupid.

Good (or certainly much better): this blank>


--
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] GetFinalPathNameByHandleW - what is the minimum windows version python-3.5 will support ?

[Terry Reedy]

On 7/19/2015 9:51 AM, Tim Golden wrote:



On 19/07/2015 13:10, Vitaly Murashev wrote:

I've just found out that that on Windows internal implementation of
python35.dll in posixmodule.c
uses winapi function GetFinalPathNameByHandleW

By the way from MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85%29.aspx


Minimum supported client
   Windows Vista [desktop apps only]

Minimum supported server
   Windows Server 2008 [desktop apps only]

Does it mean, that Python-3.5 doesn't support any windows versions prior
"Windows Vista" and "Windows Server 2008" ?


There was a similar question on python-list about 3.5.0b3 not installing 
on XP.  This is at least the second of what will be many similar questions.



In essence: yes.

Python's support for Windows is outlined in PEP 11:

   https://www.python.org/dev/peps/pep-0011/#microsoft-windows

which establishes that Python drops support for a Windows platform when
Microsoft does. WinXP (somewhat noisily) finished support last year:

   http://windows.microsoft.com/en-gb/windows/end-support-help


I knew this part.


while Server 2003 -- more quietly; I had to go and look -- came out of
extended support this month:

   https://support.microsoft.com/en-us/lifecycle?p1=3198


I was not aware of this.


Since Python 3.5 will come out after both of those platforms have
finished support, there's no guarantee that it will run without error on
those systems.


I think this line in the PEP, "Because of this policy, no further 
Windows releases need to be listed in this PEP. " is false economy. 
Your research on server 2003 should be recorded. (The presence of a 3.5 
Server 2003 buildbot, even though not working, might lead one to the 
opposite answer.) Even if users ignore the PEP, people answering 
questions (like me) try to use it to get definitive answers.


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

[Florian Bruhin]

* Ron Adam  [2015-07-19 11:17:10 -0400]:
> I had to look at the source to figure out what this thread was really all
> about.
> 
> Basically it looks to me the purpose of adding "assret" is to add an "alias
> check" for "unsafe" methods.  It doesn't actually add an "alias".  It allows
> a developer to use a valid alias to avoid conflicting with methods starting
> with assert that will still work with the mock module.
> 
> The mock module says that when "unsafe" flag is set to True, it will not
> raise AssertionError for methods beginning with "assert" and "assret".  It
> doesn't specify what "unsafe" means, and why you would want to do that.
> 
> So first do this...
> 
> * Document "unsafe" in mock module.

The issue is that Mock objects (if not using spec/autospec) allow
*any* method to be called, and return another mock:

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


But they *also* have some special methods to check if they have been
called:

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

But if you do a typo, the test silently doesn't fail (because it's returning a
new mock instead of checking if it has been called):

>>> m.assert_called()


With the patch, everything starting with "assert" or "assret" (e.g. my
example above) raises an AttributeError so these kind of issues can't
happen.

The thing people are discussing about is whether this should also
happen if you do "m.assret_called_with()" (i.e. if this is a common
enough typo to warrant a special exception), or if *only* things
starting with assert_* are checked.

The merged patch also treats "assret_*" as a typo, and some people
think this is a wart/unnecessary/harmful and only "assert_*" should
raise an AttributionError, i.e. the patch should be amended/reverted.

> I presume "unsafe" in this case means the method will not fail if an
> optimise flag is used because an assert in an assert method will not fail.
> 
> The problem I see is checking for "assert" by name convention is dubious to
> start with.  An method that begins with assert may not actually use
> "assert", and one's that don't may possibly use it.
> 
> A better way is to have a function in the inspect module that will return
> True if a function uses the "assert" keyword.
> 
> That is trickier than it sounds, because the optimize flag causes the
> asserts to be removed.  So it may require setting a flag on a function if
> it's source contained "assert".
> 
> With a reliable test for "assert", the check for an naming convention alias
> is not needed.
> 
> 
> If I've still not quite got the gist of this issue, the please correct me.

This has nothing to do with the assert *keyword* or optimization -
only with the behaviour of mock and its "assert_*" methods.

I hope this clears things up!

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/


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

[Ethan Furman]

On 07/19/2015 11:11 AM, Terry Reedy wrote:


Given that the issue is one of only partial reversion, and that a new patch 
would
therefore be needed, I also think that some fuss would have been avoided if one 
of
the initial objectors had done what you did, or volunteered to write a new 
patch,
 or had at least acknowledged that someone other than Michael could and should 
write
 the proposed new patch.


I was waiting for somebody to say "Patches welcome" -- so far every patch I have submitted (or reviewed and enhanced) for other parts of Python have been rejected (and I fully expect this one to be as 
well :(  -- I'm just waiting for Raymond to chime in and give it the coup de grâce).


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

[Brett Cannon]

On Sun, Jul 19, 2015 at 8:58 AM Ethan Furman  wrote:

> On 07/19/2015 02:22 AM, s.krah wrote:
> >  Ein Sa, 18 Jul 2015 15:35:05 + *Stephen J. Turnbull hat
> geschrieben 
> >> s.krah writes:
>
> >>> Sorry, that amounts to twisting my words.
> >>
> >> Let's not play the dozens here.  That just extends the thread to no
> point.
> >
> > Indeed.  I'll just filter you from now on.
>
> You may as well filter me too, then, because you are acting like an ass
> and I'm saying so.


Is the name calling really necessary? Couldn't you have just as easily said
that you disapproved of Stephen K's attitude without calling him an ass?
Same goes for Stephen K's comment where he could have stated he was simply
going to ignore Stephen T and be less snippy about it. There are ways to
get the point across just as strongly without resorting to this sort of
stuff.

This whole thread has shown two problems we have on this list. One is the
occasional name calling and bad attitude that we let slide in the name of
blowing off steam or something. We are all adults here and can get the
point across that we disapprove of something without resorting to
playground antics. Plus emails can be delayed until cooler heads prevail.
It's this kind of thing that leads to the need of a CoC for this list and
contributing in general so that people can feel okay saying they thought a
comment was out of line without retaliation for it.

The other problem is letting threads drag on needlessly. The longer a
thread drags on, the greater the chance someone is going to say something
they regret. It can also lead to some people like Antoine feeling like
their time is being wasted and become frustrated. I think in this instance
debate should have been cut sooner when no clear consensus was being
reached to force a reversal of the patch and then have someone say politely
that a core dev who is the listed expert on a module made a call and if
someone disliked it they could produce a patch and propose it on the issue
tracker to see if they could change someone's mind (I believe both Nick and
Ethan have made the same point). Our niceness can be to a fault when no one
is willing to step up and simply say "this thread is in a stalemate and
nothing new is being added, please move it to the issue tracker if you wish
to discuss further where you can propose a patch" and we just be good about
telling people to move the discussion to the issue tracker if they keep
replying.

There is absolutely no reason we can't keep discussions cordial, friendly,
and on-point on this list and prevent this sort of debacle from occurring
again.
___
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 19/07/2015 22:06, Brett Cannon wrote:



On Sun, Jul 19, 2015 at 8:58 AM Ethan Furman mailto:et...@stoneleaf.us>> wrote:

On 07/19/2015 02:22 AM, s.krah wrote:
 >  Ein Sa, 18 Jul 2015 15:35:05 + *Stephen J. Turnbull hat
geschrieben 
 >> s.krah writes:

 >>> Sorry, that amounts to twisting my words.
 >>
 >> Let's not play the dozens here.  That just extends the thread to
no point.
 >
 > Indeed.  I'll just filter you from now on.

You may as well filter me too, then, because you are acting like an
ass and I'm saying so.


Is the name calling really necessary? Couldn't you have just as easily
said that you disapproved of Stephen K's attitude without calling him an
ass? Same goes for Stephen K's comment where he could have stated he was
simply going to ignore Stephen T and be less snippy about it. There are
ways to get the point across just as strongly without resorting to this
sort of stuff.

This whole thread has shown two problems we have on this list. One is
the occasional name calling and bad attitude that we let slide in the
name of blowing off steam or something. We are all adults here and can
get the point across that we disapprove of something without resorting
to playground antics. Plus emails can be delayed until cooler heads
prevail. It's this kind of thing that leads to the need of a CoC for
this list and contributing in general so that people can feel okay
saying they thought a comment was out of line without retaliation for it.

The other problem is letting threads drag on needlessly. The longer a
thread drags on, the greater the chance someone is going to say
something they regret. It can also lead to some people like Antoine
feeling like their time is being wasted and become frustrated. I think
in this instance debate should have been cut sooner when no clear
consensus was being reached to force a reversal of the patch and then
have someone say politely that a core dev who is the listed expert on a
module made a call and if someone disliked it they could produce a patch
and propose it on the issue tracker to see if they could change
someone's mind (I believe both Nick and Ethan have made the same point).
Our niceness can be to a fault when no one is willing to step up and
simply say "this thread is in a stalemate and nothing new is being
added, please move it to the issue tracker if you wish to discuss
further where you can propose a patch" and we just be good about telling
people to move the discussion to the issue tracker if they keep replying.

There is absolutely no reason we can't keep discussions cordial,
friendly, and on-point on this list and prevent this sort of debacle
from occurring again.



+infinity

--
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] GetFinalPathNameByHandleW - what is the minimum windows version python-3.5 will support ?

[Chris Angelico]

On Mon, Jul 20, 2015 at 4:31 AM, Terry Reedy  wrote:
> I think this line in the PEP, "Because of this policy, no further Windows
> releases need to be listed in this PEP. " is false economy. Your research on
> server 2003 should be recorded. (The presence of a 3.5 Server 2003 buildbot,
> even though not working, might lead one to the opposite answer.) Even if
> users ignore the PEP, people answering questions (like me) try to use it to
> get definitive answers.

Also, if it comes to that, Server 2003 should probably get mentioned
here, which is where I'd go looking:

https://docs.python.org/dev/whatsnew/3.5.html#unsupported-operating-systems

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

[Ron Adam]

On 07/19/2015 02:33 PM, Florian Bruhin wrote:

* Ron Adam  [2015-07-19 11:17:10 -0400]:

>I had to look at the source to figure out what this thread was really all
>about.


And it seems I don't quite get it still, but I am trying.



>Basically it looks to me the purpose of adding "assret" is to add an "alias
>check" for "unsafe" methods.  It doesn't actually add an "alias".  It allows
>a developer to use a valid alias to avoid conflicting with methods starting
>with assert that will still work with the mock module.
>
>The mock module says that when "unsafe" flag is set to True, it will not
>raise AssertionError for methods beginning with "assert" and "assret".  It
>doesn't specify what "unsafe" means, and why you would want to do that.
>
>So first do this...
>
> * Document "unsafe" in mock module.


I still think documenting the purpose of "unsafe", rather than just the 
effect it has is important.


From the confusion in this thread, (including my own), it's clear the 
documentation does need some attention.



There are only two places where it mentions "unsafe" in the docs...

The class signature...

"""
class unittest.mock.Mock(spec=None, side_effect=None, return_value=DEFAULT, 
wraps=None, name=None, spec_set=None, unsafe=False, **kwargs)

"""


And in the section below that.

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

"""

But that doesn't explain the purpose or why these are unsafe or why it 
should throw an AttributeError.   Or what to do with that AttributeError.




But if you do a typo, the test silently doesn't fail (because it's returning a
new mock instead of checking if it has been called):


Do you mean silently passes?



 >>> m.assert_called()
 

With the patch, everything starting with "assert" or "assret" (e.g. my
example above) raises an AttributeError so these kind of issues can't
happen.


I get that part.  It's checking for a naming convention for some purpose.

What purpose?

   "To raise an AttributeError"  ... but why?



The thing people are discussing about is whether this should also
happen if you do "m.assret_called_with()" (i.e. if this is a common
enough typo to warrant a special exception), or if*only*  things
starting with assert_* are checked.

The merged patch also treats "assret_*" as a typo, and some people
think this is a wart/unnecessary/harmful and only "assert_*" should
raise an AttributionError, i.e. the patch should be amended/reverted.


I think it would be easy enough to revert, It' just a few line in the 
source and docs.  No big deal there.


It's not clear why getting an AttributeError for methods beginning with 
assert is needed, and how that exception is to be used.   (Should it Bubble 
up, or should it be caught and handled?)


Is it just a way to prevent mocks of mocks?  Maybe there is a better way of 
doing that?





>If I've still not quite got the gist of this issue, the please correct me.

This has nothing to do with the assert*keyword*  or optimization -
only with the behaviour of mock and its "assert_*" methods.

I hope this clears things up!


It clears up that it's not associated with the assert keyword.


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

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

[Ben Finney]

Nick Coghlan  writes:

> Sorry, I crossed a line there - I know everyone posting to this thread
> is doing so with the best interests of Python at heart.

Thanks for saying so, I was mulling a similar post but yours came first.

> The *problem* with threads like this one is that they end up feeling
> like punishment for being accommodating to the wishes of contributors
> on minor design details.

From this questioner's perspective, threads like this also end up
feeling like an escalating dismissal (“this is just *not important*, and
no discussion will be entered into”) of salient user concerns regarding
the APIs on the standard library.

Neither of those impressions, I'm sure, was intended by any party to
this thread.

> Potential core developers are also likely to be put off by the
> prospect of "you too can volunteer to be micromanaged by a large
> community mailing list, doesn't that sound like fun?"

Requests for principled justification can be very easily misread as
blame. The mere absence of that intention is not enough to quell
suspicion; neither is the suspicion of it enough to respond as though
that is the intent.

We all need to remember that tendency, and take better care in
expressing ourselves.

For what it's worth: of course I think I speak for everyone here in
saying that I greatly appreciate the work of core contributors in
implementing CPython and the standard library, and continuing effort to
maintain it.

Thank you all.

-- 
 \“What if the Hokey Pokey IS what it's all about?” —anonymous |
  `\   |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com