Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!xlned.com!feeder1.xlned.com!news2.euro.net!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.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'else:': 0.03; 'received:209.85.223': 0.03; 'interpreter': 0.04; 'subject:Python': 0.05; 'compiler': 0.05; 'that?': 0.05; 'interpreter.': 0.07; 'line:': 0.07; 'referring': 0.07; 'x86': 0.07; 'python': 0.09; 'compilers.': 0.09; 'referenced': 0.09; 'runtime': 0.09; 'subject:Why': 0.09; 'subject:create': 0.09; '"hello': 0.16; 'better?': 0.16; 'compilers': 0.16; 'literals,': 0.16; 'objects?': 0.16; 'runtime.': 0.16; 'subject: \n ': 0.16; 'to:name:python list': 0.16; 'later': 0.16; 'string': 0.17; 'wrote:': 0.17; 'basically': 0.17; 'integer': 0.17; 'string,': 0.17; 'typing': 0.17; '(in': 0.18; 'email addr:gmail.com>': 0.20; 'import': 0.21; 'thanks.': 0.21; 'constant': 0.22; 'defined': 0.22; '>': 0.23; 'random': 0.24; 'header:In-Reply- To:1': 0.25; 'object,': 0.27; 'possible,': 0.27; 'message- id:@mail.gmail.com': 0.27; 'subject:like': 0.29; 'url:mailman': 0.29; 'convert': 0.29; 'skip:& 10': 0.29; 'figure': 0.30; 'code': 0.31; '(and': 0.32; 'url:python': 0.32; 'could': 0.32; 'url:listinfo': 0.32; 'doubt': 0.33; 'problem': 0.33; 'to:addr :python-list': 0.33; "can't": 0.34; 'received:google.com': 0.34; 'pm,': 0.35; 'subject:?': 0.35; 'received:209.85': 0.35; 'something': 0.35; 'but': 0.36; 'url:org': 0.36; 'skip:{ 10': 0.36; 'enough': 0.36; 'does': 0.37; 'two': 0.37; 'why': 0.37; 'received:209': 0.37; 'subject:: ': 0.38; 'object': 0.38; 'some': 0.38; 'to:addr:python.org': 0.39; 'help': 0.40; 'url:mail': 0.40; 'is.': 0.62; 'between': 0.63; 'different': 0.63; 'information': 0.63; 'believe': 0.69; 'soon': 0.70; 'lose': 0.71; '2013': 0.84; 'dict,': 0.84 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=RbZ8ejqgG6+f9I9nZZYSNn4gPzf71FVPTBkJVGvTdlw=; b=mE/wTegMU0l5pnuvgoPBOP/8u1dDK+QmDm6pelp5iiryc3a+teLq5RTPoXeofGgJVF gpqtQ+5zL5buI46P7RRNoZsyeZTmH4bdqY05/NlXwtepMmfUodyO3dEGa+E1suGEsMWa woCnOKkXiuAb3rJ1ZQmKkYTPGKMf7Cs+5LmyNYquwnXUljvlUxFmFImLAHuhIrM1zbVw Q1tfhZRjMISj2iDaBd/6mThf7FaVixXegwU3D4Ntu9wqA+mjXiftW0BU61cwQsZePARe RK/Oykiir4P1x4gH4f8IMxSNXRhvcWldOdoH/NgLty+mTkpWR1bhKovoyjArkn2ig+yU FouA== X-Received: by 10.60.3.71 with SMTP id a7mr17183399oea.35.1362443273010; Mon, 04 Mar 2013 16:27:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.3.71 with SMTP id a7mr17183396oea.35.1362443272867; Mon, 04 Mar 2013 16:27:52 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 16:27:52 -0800 Subject: Re: Why is it impossible to create a compiler than can compile Python to machinecode like C? From: Benjamin Kaplan To: Python List Content-Type: multipart/alternative; boundary=e89a8f839d514e6ac504d7228b58 X-Gm-Message-State: ALoCoQlQjY961S6nKC7/BGF4muXLXOliDEZDZ+3uuoEAkutI1B2II1dBXj8PkAi/Z+iT87LhWcw4uaBbBgDR0+YYBouF4JfVjNppGFc1hrNwDu9FUicRHK0PWgdMkClCyX8pDVbvokNOItXsS4Pp+hN17bzkR4HNNQ== X-Junkmail-Whitelist: YES (by domain whitelist at mpv1.tis.cwru.edu) 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: 117 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1362443657 news.xs4all.nl 6884 [2001:888:2000:d::a6]:36749 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:40490 --e89a8f839d514e6ac504d7228b58 Content-Type: text/plain; charset=UTF-8 On Mar 4, 2013 3:02 PM, "CM" wrote: > > > > The main issue is that python has dynamic typing. The type of object > > that is referenced by a particular name can vary, and there's no way > > (in general) to know at compile time what the type of object "foo" is. > > > > That makes generating object code to manipulate "foo" very difficult. > > Could you help me understand this better? For example, if you > have this line in the Python program: > > foo = 'some text' > bar = {'apple':'fruit'} > > If the interpreter can determine at runtime that foo is a string > and bar is a dict, why can't the compiler figure that out at > compile time? Or is the problem that if later in the program > you have this line: > > foo = 12 > > now foo is referring to an integer object, not a string, and > compilers can't have two names referring to two different > types of objects? Something like that? > > I in no way doubt you that this is not possible, I just don't > understand enough about how compiling works to yet "get" > why dynamic typing is a problem for compilers. > > Thanks. > -- > http://mail.python.org/mailman/listinfo/python-list In the case of literals, the compiler can figure out type information (and I believe it does do some constant folding). But as soon as you let something else get in between you and the constant, you lose all guarantees. import random if random.random() <0.5 : spam = 3 else: spam = "hello world" Then you get into monkey patching and dealing with types that may not be defined at compile time. The only way a python compiler could convert that to x86 assembly is if generated code that would look up the type information at runtime. You'd basically be outputting a python interpreter. --e89a8f839d514e6ac504d7228b58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 4, 2013 3:02 PM, "CM" <cmpython@gmail.com> wrote:
>
>
> > The main issue is that python has dynamic typing. =C2=A0The type = of object
> > that is referenced by a particular name can vary, and there's= no way
> > (in general) to know at compile time what the type of object &quo= t;foo" is.
> >
> > That makes generating object code to manipulate "foo" v= ery difficult.
>
> Could you help me understand this better? =C2=A0For example, if you > have this line in the Python program:
>
> foo =3D 'some text'
> bar =3D {'apple':'fruit'}
>
> If the interpreter can determine at runtime that foo is a string
> and bar is a dict, why can't the compiler figure that out at
> compile time? =C2=A0Or is the problem that if later in the program
> you have this line:
>
> foo =3D 12
>
> now foo is referring to an integer object, not a string, and
> compilers can't have two names referring to two different
> types of objects? =C2=A0Something like that?
>
> I in no way doubt you that this is not possible, I just don't
> understand enough about how compiling works to yet "get"
> why dynamic typing is a problem for compilers.
>
> Thanks.
> --
> http:/= /mail.python.org/mailman/listinfo/python-list

In the case of literals, the compiler can figure out type information (a= nd I believe it does do some constant folding). But as soon as you let some= thing else get in between you and the constant, you lose all guarantees.

import random

if random.random() <0.5 :
=C2=A0=C2=A0=C2=A0 spam =3D 3
else:
=C2=A0=C2=A0=C2=A0 spam =3D "hello world"

Then you get into monkey patching and dealing with types that may not be= defined at compile time. The only way a python compiler could convert that= to x86 assembly is if generated code that would look up the type informati= on at runtime. You'd basically be outputting a python interpreter.

--e89a8f839d514e6ac504d7228b58--