<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 2015-05-05 17:57, Ludovic Gasc wrote:<br>
    <blockquote
cite="mid:CAON-fpHD630jYDyYtA3YFFWNBNf1+3H6-k3wmk8cUW36F1VYTg@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra">For example, we may detect if it's
          async or not if you have: result = await response.payload()
          or result = response.payload()</div>
        <div class="gmail_extra">The issue I see with that and certainly
          already explained during PEP492 discussions, is that it will
          be difficult for the developer to spot where he is forgotten
          await keyword, because he won't have errors.</div>
        <div class="gmail_extra"><br>
        </div>
      </div>
    </blockquote>
    <br>
    Thank you for your email!<br>
    <br>
    I've been following quite a bit of the PEP492 discussions, but not
    sure if I have missed something. If there is something about await
    outside async def that goes further than "It is a SyntaxError to use
    await outside of an async def function (like it is a SyntaxError to
    use yield outside of def function.)", which is directly from the
    PEP, I've missed that. A link or pointer would be helpful.<br>
    <br>
    In any case, I think I understand the problem you are referring to,
    but is that any different from forgetting a postfix "_s" in the
    approach you mention below?<br>
    <br>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <blockquote
cite="mid:CAON-fpHD630jYDyYtA3YFFWNBNf1+3H6-k3wmk8cUW36F1VYTg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">Moreover, in the use cases where async
          is less efficient that sync, it should be interesting to be
          possible, maybe with a context manager to define a block of
          code where all await are in fact sync (without to use event
          loop). But, even if a talentuous low-developper find a
          solution to implement this idea, because I'm not sure it's
          technically possible, in fact it will more easier even for
          end-developers to use the sync library version of this need.</div>
      </div>
    </blockquote>
    <br>
    Surely that is possible, although may of course be hard to implement
    :). I think this is related to this earlier suggestion by Joshua
    Bartlett (which I do like):<br>
    <br>
<a class="moz-txt-link-freetext" href="https://mail.python.org/pipermail/python-ideas/2013-January/018519.html">https://mail.python.org/pipermail/python-ideas/2013-January/018519.html</a><br>
    <br>
    However, I don't think it solves *this* problem. It would just
    become a more verbose version of what I suggested.<br>
    <br>
    <blockquote
cite="mid:CAON-fpHD630jYDyYtA3YFFWNBNf1+3H6-k3wmk8cUW36F1VYTg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">FYI, I've made an yocto library for my
          company where I need to be sync for some use cases and async
          for some other use cases.</div>
        <div class="gmail_extra">For the sync and async public API where
          the business logic behind most functions are identical, I've
          followed the same pattern as in Python-LDAP: <a
            moz-do-not-send="true"
href="http://www.python-ldap.org/doc/html/ldap.html#sending-ldap-requests">http://www.python-ldap.org/doc/html/ldap.html#sending-ldap-requests</a></div>
        <div class="gmail_extra">I've postfixed all sync functions by
          "_s".</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">For a more complex library, it may
          possible to have two differents classes with explicit names.</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">At least to me, it's enough to work
          efficiently, explicit is better than implicit ;-)</div>
        <br>
      </div>
    </blockquote>
    <br>
    In my mind, this is not at all about explicit vs. implicit. It is
    mostly about letting the coroutines know what kind of context they
    are being run from. Anyway, I'm pretty sure there are plenty of
    people in the Python community who don't think efficiency is enough,
    but that is a matter of personal preference. I want everything, and
    that's why I'm using Python ;). <br>
    <br>
    -- Koos<br>
    <br>
  </body>
</html>