Re: [Python-Dev] How far to go with user-friendliness
Ein Sa, 18 Jul 2015 15:35:05 + Stephen J. Turnbull lt;step...@xemacs.orggt; hat geschrieben s.krah writes: gt;gt; Sorry, that amounts to twisting my words. gt; 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 ?
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 ?
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] GetFinalPathNameByHandleW - what is the minimum windows version python-3.5 will support ?
On Mon, Jul 20, 2015 at 4:31 AM, Terry Reedy tjre...@udel.edu 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
On 07/19/2015 02:33 PM, Florian Bruhin wrote: * Ron Adamron3...@gmail.com [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() Mock name='mock.assert_called()' id='140277467876152' 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
On Sun, Jul 19, 2015 at 8:58 AM Ethan Furman 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. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 19/07/2015 22:06, Brett Cannon wrote: On Sun, Jul 19, 2015 at 8:58 AM Ethan Furman et...@stoneleaf.us 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] How far to go with user-friendliness
On 07/16/2015 07:48 PM, Antoine Pitrou wrote: On Fri, 17 Jul 2015 11:35:53 +1200 Alexanderxr.li...@gmail.com 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
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 ron3...@gmail.com [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() Mock name='mock.foo()' id='140277502245632' 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() Mock name='mock.assert_called()' id='140277467876152' 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
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
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): I think Nick already tried to fill in 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] How far to go with user-friendliness
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] GetFinalPathNameByHandleW - what is the minimum windows version python-3.5 will support ?
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
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
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
