Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #26501
| Date | 2012-08-04 20:24 +0100 |
|---|---|
| From | MRAB <python@mrabarnett.plus.com> |
| Subject | Re: On-topic: alternate Python implementations |
| References | (3 earlier) <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> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.2946.1344108293.4697.python-list@python.org> (permalink) |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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