
<html>

 <head>

  <meta content="text/html; charset=ISO-8859-1"

   http-equiv="Content-Type">

 </head>

 <body bgcolor="#FFFFFF" text="#000000">

  <br>

  On 06/06/2012 09:05 AM, Larry Hastings wrote:<br>

  <blockquote cite="mid:4FCF7FDC.2080000@hastings.org" type="cite">

   <blockquote cite="mid:4FCF7965.5070102@pearwood.info" type="cite">Is


    there a use-case for is_implemented?</blockquote>

   <br>

   Yes, see issue

   <meta http-equiv="content-type" content="text/html;

    charset=ISO-8859-1">

   14626.<br>

  </blockquote>

  <br>

  I should add, there are already some places in the standard library

  where is_implemented would be relevant.&nbsp; The "mode" argument to

  os.mkdir comes immediately to mind; on Windows it is accepted but

  ignored.&nbsp; A counter-example would be os.symlink, which takes an

  extra parameter on Windows that's&nbsp; *not even accepted* on other

  platforms.<br>

  <br>

  I am utterly convinced that, when faced with these sorts of

  platform-specific API differences, the first step towards sanity is

  to have the API accept a consistent signature everywhere.&nbsp; What you

  do after that is up for debate--in most cases where the parameter

  causes a significant semantic change, I think specifying it with a

  non-default value should throw a NotImplementedError.&nbsp; (With the

  specific case of os.mkdir on Windows, I can agree with silently

  ignoring the mode; it's not like the hapless Windows programmer

  could react and take a useful alternative approach.)<br>

  <br>

  Parameter objects exposing is_implemented allows LBYL in these

  situations, rather than having to react to NotImplementedError.<br>

  <br>

  <br>

  <i>/arry</i><br>

 </body>

</html>