Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'debugging': 0.07; 'modify': 0.07; 'namespace': 0.09; 'seemed': 0.09; 'wrapper': 0.09; 'cc:addr:python-list': 0.11; 'python': 0.11; 'def': 0.12; '**kwds)': 0.16; '**kwds):': 0.16; '__builtin__': 0.16; 'buffering,': 0.16; 'builtins': 0.16; 'builtins.': 0.16; 'from:addr:pobox.com': 0.16; 'from:addr:skip': 0.16; "function's": 0.16; 'implied.': 0.16; 'mode,': 0.16; "mode='r',": 0.16; 'newline,': 0.16; 'open(file,': 0.16; 'tracing': 0.16; 'appropriate': 0.16; 'sender:addr:gmail.com': 0.17; 'looked': 0.18; 'warranties': 0.19; 'written': 0.21; 'seems': 0.21; '>>>': 0.22; 'import': 0.22; 'cc:addr:python.org': 0.22; "shouldn't": 0.24; 'skip': 0.24; 'cc:2**0': 0.24; 'cc:no real name:2**0': 0.24; "i've": 0.25; 'header:In-Reply-To:1': 0.27; 'function': 0.29; "doesn't": 0.30; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'program,': 0.31; 'code': 0.31; 'concern.': 0.31; 'stuff': 0.32; 'option': 0.32; 'open': 0.33; 'entirely': 0.33; 'not.': 0.33; 'totally': 0.33; 'skip:_ 10': 0.34; 'except': 0.35; 'something': 0.35; 'etc': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'doing': 0.36; 'should': 0.36; 'wrong': 0.37; 'expressed': 0.37; 'expected': 0.38; 'skip:o 20': 0.38; 'handle': 0.38; 'though,': 0.39; 'sure': 0.39; 'major': 0.40; 'most': 0.60; 'skip:n 10': 0.64; 'more': 0.64; 'great': 0.65; 'to:addr:gmail.com': 0.65; 'believe': 0.68; 'production': 0.68; 'beats': 0.84; 'etc,': 0.84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2889HCU25w/dDubjad+4asRmRKSw8sBFFeia06zNMng=; b=eQJruL666mLnrEZtxR729UIJDyS57rx8Ea41zUhDJBAP9I15du3rZDO5xOoDkD9K5S WH7R9BctgN2PEtM84oC8vjA//YtGncg0aVXRE57LsilrSSLptWRJGBxFPkG97DeWMjEK SdM1dsZ8mDfa5U/TMXw1LOgiZpQR05yLGbQPFwZ3lJ3vmBAutOcEokVSESCpVsx1vjIy TcRmZt0tK6KmQHHv9yrQr3MdbtUdA0T4wbxhvWpVo9jyCYDP7ZRSfA29I1A5zYRmzCi9 TSFQMYE5Kovsytvh2GQ2Lf7MXcbS0cqLDuaqy6cohRxclnUHSm0COHB6qS/pP3On0qf7 DdFw== MIME-Version: 1.0 X-Received: by 10.50.41.34 with SMTP id c2mr13951247igl.57.1372671152547; Mon, 01 Jul 2013 02:32:32 -0700 (PDT) Sender: skip.montanaro@gmail.com In-Reply-To: <694830e3-080c-4e66-90e2-6cbab53be071@googlegroups.com> References: <694830e3-080c-4e66-90e2-6cbab53be071@googlegroups.com> Date: Mon, 1 Jul 2013 04:32:32 -0500 X-Google-Sender-Auth: tuhU1UH_4pEjS9O0hk3WV6z3CEM Subject: Re: settrace doesn't trace builtin functions From: Skip Montanaro To: skunkwerk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: python-list@python.org X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 65 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1372671160 news.xs4all.nl 15885 [2001:888:2000:d::a6]:46623 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:49537 > I've been using the settrace function to write a tracer for my program,= which is working great except that it doesn't seem to work for built-in fu= nctions, like open('filename.txt'). This doesn't seem to be documented, so= I'm not sure if I'm doing something wrong or that's the expected behavior. I believe that's expected behavior. Stuff written in Python is traced. C functions are not. It's been a whole lot of years since I looked at that code though, so I might be misremembering. > The other option I considered was monkey-patching the open function throu= gh a wrapper ... but that seemed very brittle to me. For debugging purposes, practicality beats purity. I trust you won't be tracing in a production environment, so fragility shouldn't be a major concern. Monkey patching seems entirely appropriate to me. Python 2.x: >>> open >>> import __builtin__ >>> open is __builtin__.open True >>> _open =3D __builtin__.open >>> def open(name, mode=3DNone, buffering=3DNone): ... return _open(name, mode, buffering) ... >>> __builtin__.open =3D open >>> open is __builtin__.open True >>> open Python 3.x: >>> import builtins >>> open >>> open is builtins.open True >>> _open =3D builtins.open >>> def open(file, mode=3D'r', buffering=3D-1, encoding=3DNone, ... errors=3DNone, newline=3DNone, closefd=3DTrue, opener=3DNone): ... return _open(file, mode, buffering, encoding, errors, newline, closefd, opener) ... >>> _open >>> builtins.open =3D open >>> open You can, of course, do this for more builtins. Presuming you can get a handle on a function's namespace and modify it, you should be able to perform the same trick for most functions or methods written in C. >>> sys._settrace =3D sys.settrace >>> def settrace(*args, **kwds): ... return sys._settrace(*args, **kwds) ... >>> sys.settrace =3D sys._settrace Totally untested. No warranties expressed or implied. YMMV... etc, etc Skip