Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Chris Angelico Newsgroups: comp.lang.python Subject: Re: Cannot step through asynchronous iterator manually Date: Sun, 31 Jan 2016 09:06:52 +1100 Lines: 29 Message-ID: References: <56AD122F.2030904@gmail.com> <56AD31E7.50407@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: news.uni-berlin.de 0KWbRj7w/z3m9VS88dozkABQKn04bNfqKMdI5TmKacqw== Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'received:209.85.223': 0.03; 'alias': 0.07; 'column': 0.07; 'exception.': 0.07; 'cc:addr :python-list': 0.09; 'fetch': 0.09; 'rows,': 0.09; 'throw': 0.09; 'underlying': 0.09; 'violates': 0.09; 'jan': 0.11; 'result.': 0.15; "(you're": 0.16; '2016': 0.16; 'count,': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'functions.)': 0.16; 'query.': 0.16; 'received:209.85.223.173': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'row': 0.16; 'succeeds,': 0.16; 'wrote:': 0.16; 'result,': 0.18; 'cc:2**0': 0.20; 'cc:addr:python.org': 0.20; 'algorithm': 0.20; 'not,': 0.22; '31,': 0.22; 'occurs': 0.22; 'am,': 0.23; 'decide': 0.23; 'select': 0.23; '(or': 0.23; 'second': 0.24; 'header:In-Reply- To:1': 0.24; "doesn't": 0.26; 'rest': 0.26; 'chris': 0.26; 'message-id:@mail.gmail.com': 0.27; 'there.': 0.30; 'query': 0.30; 'supposed': 0.31; 'another': 0.32; "can't": 0.32; 'run': 0.33; 'michael': 0.33; 'true.': 0.33; 'handle': 0.34; 'received:google.com': 0.35; 'done': 0.35; 'mix': 0.35; 'received:209.85': 0.36; 'pm,': 0.36; 'subject:: ': 0.37; 'two': 0.37; 'received:209': 0.38; 'whatever': 0.39; 'where': 0.40; 'still': 0.40; 'some': 0.40; 'your': 0.60; 'matter': 0.63; 'is.': 0.63; 'more': 0.63; 'information': 0.63; 'wish': 0.71; 'groups.': 0.72; 'chrisa': 0.84; 'to:none': 0.91; 'results,': 0.91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=zVam5eOnQHF/JSVrwJ1084FBxGIxyR3FzGpeMyjB1ps=; b=WQSncBlUOWMQS1PxubozjTZYQJG4XGVn1hm676AQsmKvaiY5WQyK7oyMXOK94X3VYW FOVHSReiwKWVTbSQmMv6ZYGMXzHjiwhraGzWLPYo6O6B69z+8yUmR5qDLHlf1N6P2Oai ipBwPfhcfFXxnJQ9IDLkVcG5wbLR+ryES8kHSGG0Wz8UcGLXFo0jPo4SxH8eo5gsTh9c cqFRZHwXkIxtzb42m2nm3hUjzcwjaFH2vG9V6lEkCtZodOcsFC8/hf5vO5Zh4dZFyPl1 1iO2h6JvFNs08VsZgr6od/XTyPMXzIRn8E5liRVt/8VTT/5SH6Cvh5L3K4tDg01Gmmdx OduA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=zVam5eOnQHF/JSVrwJ1084FBxGIxyR3FzGpeMyjB1ps=; b=lP4H4XAovHD0dusTb+bbyTuyetYUUHSB/t753A971+KYUn5sgKYabkyz39VKdEMaZP zsLBmdUp+xjfPnsV0XLbUrRW3uh6fy4LUvlOvW/LG3dUtSU+hqksZKhsLzCuUX5fT7VN FZPxibA9AXbWEn336l5sNNhB7HOZ+1xBOSOxCAkVS1FWZa1x8qz7Ha435FeGRZZJNNnf EyIFEZu2S3hCHcHUPKDp4lHYFAKI7QGQmWUi6QxB1KBGnvgjzI8wrcGGFVKQCgg6ukz6 h+wdfzFD3Ahb4XZOXDL0QXxijvqpaN9z4LhTClrFWbDCarBWAMbcVHw6+NOkazc4GvCb GHtw== X-Gm-Message-State: AG10YOTVucwbt7eAc4eSfo8aTvPO3Bf4pX3IUO55yenzFzd8SL0SzspzPZn35lQ0JfBXJ/y3ZJoCPOAxpVIZog== X-Received: by 10.107.47.162 with SMTP id v34mr15256734iov.19.1454191612505; Sat, 30 Jan 2016 14:06:52 -0800 (PST) In-Reply-To: <56AD31E7.50407@gmail.com> X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.20+ Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com comp.lang.python:102317 On Sun, Jan 31, 2016 at 8:57 AM, Michael Torrie wrote: > On 01/30/2016 02:19 PM, Chris Angelico wrote: >> where the ... is the full original query. In other words, the whole >> query has to be run twice - once to assert that there's exactly one >> result, and then a second time to get that result. The existing >> algorithm ("try to fetch a row - if it fails error; then try to fetch >> another - if it succeeds, error") doesn't need to fetch more than two >> results, no matter how big the query result is. > > Actually it occurs to me this doesn't have to be true. The same > information he needs to know can be done with one query and only 1 result. > > SELECT count(some_id_field),field1,field2,field3 FROM wherever WHERE > conditions > > If the first column (or whatever you decide to alias it as) contains a > count, and the rest of the information is still there. If count is 1, > then the row is what you want and you can do whatever you wish with it. > If not, throw your exception. That actually violates the SQL spec. Some servers will accept it, others won't. (You're not supposed to mix column functions and non-column functions.) It also can't cope with 'group by' queries, as it'll count the underlying rows, not the groups. I also suspect it can't handle join queries. The original approach is still the most general, and IMO the best. ChrisA