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

Ron Adam ron3200 at gmail.com
Sun Jul 19 17:17:10 CEST 2015



On 07/16/2015 07:48 PM, Antoine Pitrou wrote:
> On Fri, 17 Jul 2015 11:35:53 +1200
> Alexander<xr.lists at 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
























More information about the Python-Dev mailing list