Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #26501

Re: On-topic: alternate Python implementations

Path csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path <python@mrabarnett.plus.com>
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; 'subject:Python': 0.05; '(python': 0.05; 'compiler': 0.05; 'cpython': 0.05; 'memory.': 0.05; 'parameter': 0.07; 'pypy': 0.07; 'python': 0.09; 'garbage': 0.09; 'generators': 0.09; 'imports': 0.09; 'leaks': 0.09; 'occasionally': 0.09; 'references.': 0.09; 'runtime': 0.09; 'sake': 0.09; 'target:': 0.09; 'throw': 0.09; 'extension': 0.13; 'cases': 0.15; "(it's": 0.16; 'example?': 0.16; 'from:addr:mrabarnett.plus.com': 0.16; 'from:addr:python': 0.16; 'from:name:mrab': 0.16; 'gotos': 0.16; 'least.': 0.16; 'message- id:@mrabarnett.plus.com': 0.16; 'programmers.': 0.16; 'relied': 0.16; 'said.': 0.16; 'unreachable': 0.16; 'wrote:': 0.17; 'mechanism': 0.17; 'stefan': 0.17; 'variables': 0.17; '>>>': 0.18; 'code,': 0.18; 'memory': 0.18; '(or': 0.18; 'code.': 0.20; 'translate': 0.20; 'holds': 0.20; 'written': 0.20; 'regardless': 0.21; 'are.': 0.22; 'closely': 0.22; 'struct': 0.22; 'subject:skip:i 10': 0.22; 'purposes': 0.23; 'statement': 0.23; 'idea': 0.24; 'paul': 0.24; 'header:In-Reply-To:1': 0.25; 'header :User-Agent:1': 0.26; 'compiled': 0.27; 'embedded': 0.27; 'label': 0.27; 'fixed': 0.28; 'all.': 0.28; '>>>>': 0.29; 'received:192.168.1.3': 0.29; 'though.': 0.29; 'writes:': 0.29; 'no,': 0.29; 'reset': 0.29; 'maybe': 0.29; 'worked': 0.30; 'function': 0.30; 'stuff': 0.30; 'code': 0.31; 'could': 0.32; 'real-time': 0.33; 'handle': 0.33; 'problem': 0.33; 'to:addr :python-list': 0.33; 'requirements': 0.33; 'that,': 0.34; 'project': 0.34; 'done': 0.34; 'something': 0.35; 'there': 0.35; 'really': 0.36; 'created': 0.36; 'but': 0.36; 'depends': 0.36; 'totally': 0.36; "didn't": 0.36; 'useful': 0.36; 'anything': 0.36; "i'll": 0.36; 'does': 0.37; 'uses': 0.37; 'systems,': 0.37; 'previous': 0.37; 'quite': 0.37; 'well.': 0.37; 'subject:: ': 0.38; 'store': 0.38; 'mean': 0.38; 'some': 0.38; 'instead': 0.39; 'to:addr:python.org': 0.39; 'received:192': 0.39; 'called': 0.39; 'received:192.168': 0.40; 'subject:-': 0.40; 'end': 0.40; 'your': 0.60; 'most': 0.61; 'dedicated': 0.61; 'kind': 0.61; 'back': 0.62; 'provide': 0.62; 'choose': 0.65; 'state,': 0.65; 'forward': 0.66; 'header:Reply-To:1': 0.68; 'advantages': 0.71; 'state.': 0.71; 'unusual': 0.71; 'reply-to:no real name:2**0': 0.72; 'counts': 0.81; 'away,': 0.84; 'entry,': 0.84; 'experiment': 0.84; 'forward,': 0.84; 'hardly': 0.84; 'reply-to:addr:python.org': 0.84; 'leak': 0.91; 'tricky': 0.91; 'besides,': 0.93; 'tied': 0.93
X-CM-Score 0.00
X-CNFS-Analysis v=2.0 cv=W6e6pGqk c=1 sm=1 a=0nF1XD0wxitMEM03M9B4ZQ==:17 a=DKcI9XZsuF4A:10 a=tYftGGHQbGsA:10 a=ihvODaAuJD4A:10 a=OUOv7kDek9cA:10 a=8nJEP1OIZ-IA:10 a=EBOSESyhAAAA:8 a=8AHkEIZyAAAA:8 a=I4T8wDYJbLbuFFCTejIA:9 a=wPNLvfGTeEIA:10 a=0nF1XD0wxitMEM03M9B4ZQ==:117
X-AUTH mrabarnett:2500
Date Sat, 04 Aug 2012 20:24:53 +0100
From MRAB <python@mrabarnett.plus.com>
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version 1.0
To python-list@python.org
Subject Re: On-topic: alternate Python implementations
References <501cbdf8$0$29978$c3e8da3$5496439d@news.astraweb.com> <mailman.2924.1344062061.4697.python-list@python.org> <501cff63$0$29978$c3e8da3$5496439d@news.astraweb.com> <mailman.2930.1344079082.4697.python-list@python.org> <7x1ujmabs9.fsf@ruckus.brouhaha.com> <mailman.2940.1344099318.4697.python-list@python.org> <7x1ujm1pwu.fsf@ruckus.brouhaha.com> <jvjrqr$sqk$1@dough.gmane.org>
In-Reply-To <jvjrqr$sqk$1@dough.gmane.org>
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.12
Precedence list
Reply-To python-list@python.org
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.2946.1344108293.4697.python-list@python.org> (permalink)
Lines 80
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1344108293 news.xs4all.nl 6840 [2001:888:2000:d::a6]:40153
X-Complaints-To abuse@xs4all.nl
Xref csiph.com comp.lang.python:26501

Show key headers only | View raw


On 04/08/2012 20:06, Stefan Behnel wrote:
> Paul Rubin, 04.08.2012 20:18:
>> Stefan Behnel writes:
>>>> C is pretty poor as a compiler target: how would you translate Python
>>>> generators into C, for example?
>>> Depends. If you have CPython available, that'd be a straight forward
>>> extension type.
>>
>> Calling CPython hardly counts as compiling Python into C.
>
> CPython is written in C, though. So anything that CPython does can be done
> in C. It's not like the CPython project used a completely unusual way of
> writing C code.
>
> Besides, I find your above statement questionable. You will always need
> some kind of runtime infrastructure when you "compile Python into C", so
> you can just as well use CPython for that instead of reimplementing it
> completely from scratch. Both Cython and Nuitka do exactly that, and one of
> the major advantages of that approach is that they can freely interact with
> arbitrary code (Python or not) that was written for CPython, regardless of
> its native dependencies. What good would it be to throw all of that away,
> just for the sake of having "pure C code generation"?
>
>
>>> For the yielding, you can use labels and goto. Given that you generate
>>> the code, that's pretty straight forward as well.
>>
>> You're going to compile the whole Python program into a single C
>> function so that you can do gotos inside of it?  What happens if the
>> program imports a generator?
>
> No, you are going to compile only the generator function into a function
> that uses gotos, maybe with an additional in-out struct parameter that
> holds its state. Then, on entry, you read the label (or its ID) from the
> previous state, reset local variables and jump to the label. On exit, you
> store the state back end return. Cython does it that way. Totally straight
> forward, as I said.
>
>
>>>> How would you handle garbage collection?
>>> CPython does it automatically for us at least.
>>
>> You mean you're going to have all the same INCREF/DECREF stuff on every
>> operation in compiled data?  Ugh.
>
> If you don't like that, you can experiment with anything from a dedicated
> GC to transactional memory.
>
>
>>> Lacking that, you'd use one of the available garbage collection
>>> implementations,
>>
>> What implementations would those be?  There's the Boehm GC which is
>> useful for some purposes but not really suitable at large scale, from
>> what I can tell.  Is there something else?
>
> No idea - I'll look it up when I need one. Last I heard, PyPy had a couple
> of GCs to choose from, but I don't know how closely the are tied into its
> infrastructure.
>
>
>>> or provide none at all.
>>
>> You're going to let the program just leak memory until it crashes??
>
> Well, it's not like CPython leaks memory until it crashes, now does it? And
> it's written in C. So there must be ways to handle this also in C.
>
> Remember that CPython didn't even have a GC before something around 2.0,
> IIRC. That worked quite ok in most cases and simply left the tricky cases
> to the programmers. It really depends on what your requirements are. Small
> embedded systems, time critical code and real-time systems are often much
> better off without garbage collection. It's pure convenience, after all.
>
[snip]
CPython relied entirely on reference counting, so memory could leak you 
if inadvertently created a cycle of memory references. That problem was
fixed when a mark-and-sweep mechanism was added (it's called
occasionally to collect any unreachable cycles).

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

On-topic: alternate Python implementations Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-04 06:15 +0000
  Re: On-topic: alternate Python implementations Chris Angelico <rosuav@gmail.com> - 2012-08-04 16:34 +1000
    Re: On-topic: alternate Python implementations Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-04 10:54 +0000
      Re: On-topic: alternate Python implementations Stefan Krah <stefan-usenet@bytereef.org> - 2012-08-04 13:18 +0200
        Re: On-topic: alternate Python implementations Paul Rubin <no.email@nospam.invalid> - 2012-08-04 08:59 -0700
          Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-04 18:55 +0200
            Re: On-topic: alternate Python implementations Paul Rubin <no.email@nospam.invalid> - 2012-08-04 11:18 -0700
              Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-04 21:06 +0200
                Re: On-topic: alternate Python implementations Paul Rubin <no.email@nospam.invalid> - 2012-08-04 13:43 -0700
                Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-04 23:24 +0200
              Re: On-topic: alternate Python implementations MRAB <python@mrabarnett.plus.com> - 2012-08-04 20:24 +0100
          Re: On-topic: alternate Python implementations Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-05 00:54 +0000
            Re: On-topic: alternate Python implementations Paul Rubin <no.email@nospam.invalid> - 2012-08-04 18:38 -0700
              Re: On-topic: alternate Python implementations Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-05 02:19 +0000
                Re: On-topic: alternate Python implementations John Nagle <nagle@animats.com> - 2012-08-06 22:57 -0700
              Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-05 07:37 +0200
            Re: On-topic: alternate Python implementations Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-04 23:09 -0400
      Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-04 13:32 +0200
  Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-04 08:40 +0200
    Re: On-topic: alternate Python implementations Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-04 07:49 +0000
      Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-04 11:10 +0200
        Re: On-topic: alternate Python implementations Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-08-04 14:51 +0200
          Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-04 15:53 +0200
            Re: On-topic: alternate Python implementations Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-08-08 10:29 +0200
          Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-04 16:03 +0200
      Re: On-topic: alternate Python implementations Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-04 11:05 +0100
      Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-04 12:59 +0200
      Re: On-topic: alternate Python implementations Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-04 19:24 +0100
        Re: On-topic: alternate Python implementations Temia Eszteri <lamialily@cleverpun.com> - 2012-08-04 11:34 -0700
        Re: On-topic: alternate Python implementations Ben Finney <ben+python@benfinney.id.au> - 2012-08-06 01:21 +1000
      Re: On-topic: alternate Python implementations Zero Piraeus <schesis@gmail.com> - 2012-08-04 14:42 -0400
      Re: On-topic: alternate Python implementations Zero Piraeus <schesis@gmail.com> - 2012-08-04 14:56 -0400
      Re: On-topic: alternate Python implementations Ethan Furman <ethan@stoneleaf.us> - 2012-08-05 07:27 -0700
  Re: On-topic: alternate Python implementations Tim Roberts <timr@probo.com> - 2012-08-04 13:07 -0700
  Re: On-topic: alternate Python implementations jwp <james.pye@gmail.com> - 2012-08-04 15:05 -0700
  Re: On-topic: alternate Python implementations Jürgen A. Erhard <jae+python@jaerhard.com> - 2012-08-05 01:25 +0200
  Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-05 07:46 +0200
  Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-05 09:51 +0200
  Re: On-topic: alternate Python implementations Jürgen A. Erhard <jae+python@jaerhard.com> - 2012-08-05 14:28 +0200
  Re: On-topic: alternate Python implementations alex23 <wuwei23@gmail.com> - 2012-08-05 20:40 -0700
    Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-06 08:21 +0200
  Re: On-topic: alternate Python implementations Stefan Behnel <stefan_ml@behnel.de> - 2012-08-06 08:46 +0200
  Alternate Python extensions (was alternate Python implementations) rusi <rustompmody@gmail.com> - 2012-08-06 21:23 -0700
    Re: Alternate Python extensions (was alternate Python implementations) Stefan Behnel <stefan_ml@behnel.de> - 2012-08-07 07:09 +0200

csiph-web