Re: "CPython"

varied! LOL! -Original Message- From: David J W To: Avi Gross Cc: python-list@python.org Sent: Fri, Jun 24, 2022 11:57 am Subject: Re: "CPython" The main motivation for a Python virtual machine in Rust is to strengthen my knowledge with Rust which currently has some g

Re: "CPython"

ot; would be left intact rather than mangled, even if > the name itself happens to be totally meaningless. So may I suggest > something like """rustic-python""" ? > > > > -----Original Message- > From: David J W > To: python-list@python

Re: "CPython"

-Original Message- From: David J W To: python-list@python.org Sent: Thu, Jun 23, 2022 10:29 am Subject: Re: "CPython" >> Let's say they reimplement "reference python" CPython in Rust. What is >> better? Change the "reference python" CPython name to

Re: "CPython"

>> Let's say they reimplement "reference python" CPython in Rust. What is >> better? Change the "reference python" CPython name to RPython, for >> example, or let it as CPython? >The C implementation would still be called CPython, and the new >implementation might be called RPython, or

Re: "CPython"

On 22/06/22 4:42 am, MRAB wrote: On 2022-06-21 03:52, Avi Gross via Python-list wrote: This leads to the extremely important question of what would an implementation of Python, written completely in C++, be called? C++Python CPython++ C+Python+ DPython SeaPython? SeeSeaSiPython CincPython?

Re: "CPython"

On Tuesday, June 21, 2022 at 2:09:27 PM UTC+1, Grant Edwards wrote: > On 2022-06-21, Chris Angelico wrote: > > > Not sure why it's strange. The point is to distinguish "CPython" from > > "Jython" or "Brython" or "PyPy" or any of the other implementations. > > Yes, CPython has a special place

Re: "CPython"

On 2022-06-21 at 17:04:45 +, Avi Gross via Python-list wrote: > My problem with that idea is, believe it or not, that it is too negative. > What you meant to be seen as a dash is a minus sign to me. And both C and C++ > not only have both a pre and post autoincrement variable using ++x and

Re: "CPython"

who kept improving C thought the ++ concept was best removed! -Original Message- From: Greg Ewing To: python-list@python.org Sent: Tue, Jun 21, 2022 3:53 am Subject: Re: "CPython" On 21/06/22 2:56 pm, Paulo da Silva wrote: > Let's say they reimplement "reference pytho

Re: "CPython"

On 2022-06-21 03:38, Paulo da Silva wrote: Às 02:33 de 21/06/22, Chris Angelico escreveu: On Tue, 21 Jun 2022 at 11:13, Paulo da Silva wrote: Às 20:01 de 20/06/22, Paulo da Silva escreveu: Às 18:19 de 20/06/22, Stefan Ram escreveu: The same personality traits that make people react

Re: "CPython"

On Tue, 21 Jun 2022 19:53:51 +1200, Greg Ewing declaimed the following: >Although if it were called RPython, no doubt a new debate would >flare up over whether the "R" stands for "Rust" or "Reference"... Or does RPython refer to a Python integrated into the R statistics system?

Re: "CPython"

On Tue, 21 Jun 2022 01:53:38 +0100, Paulo da Silva declaimed the following: >I still find very strange, to not say weird, that a compiler or >interpreter has a name based in the language it was written. But, again, >is just my opinion and nothing more. > The whole purpose for that

Re: "CPython"

On 2022-06-21 03:52, Avi Gross via Python-list wrote: This leads to the extremely important question of what would an implementation of Python, written completely in C++, be called? C++Python CPython++ C+Python+ DPython SeaPython? SeeSeaSiPython CincPython? FYI, there's a language called D,

Re: "CPython"

On 21/06/22 8:37 pm, Christian Gollwitzer wrote: Am 20.06.22 um 22:47 schrieb Roel Schroeven: "CPython is a descendant of Pyscript built on Pyodide, a port of CPython, or a Python distribution for the browser and Node.js that is based on Webassembly and Emscripten." To me, this sentence is

Re: "CPython"

Am 20.06.22 um 22:47 schrieb Roel Schroeven: indication that www.analyticsinsight.net is wrong on that point. Frankly that website seems very low quality in general. In that same article they say: "CPython is a descendant of Pyscript built on Pyodide, a port of CPython, or a Python

Re: "CPython"

tOn Tue, 21 Jun 2022 02:52:28 + (UTC), Avi Gross declaimed the following: > >I don't even want to think fo what sound a C# Python would make. A musical hiss on a frequency of 277.183Hz (for the C# above middle-C) -- Wulfraed Dennis Lee Bieber AF6VN

Re: "CPython"

On 21/06/22 9:27 pm, Paul Rubin wrote: What? I never heard of such a dispute. The PSF got after someone about it? Sheesh. Upon further research, it seems it wasn't the *Python* trademark that was at issue. From the Jython FAQ page: 1.2 How does Jython relate to JPython? Jython is the

Re: "CPython"

Il 21/06/2022 04:56, Paulo da Silva ha scritto: Às 03:20 de 21/06/22, MRAB escreveu: On 2022-06-21 02:33, Chris Angelico wrote: On Tue, 21 Jun 2022 at 11:13, Paulo da Silva wrote: Às 20:01 de 20/06/22, Paulo da Silva escreveu: > Às 18:19 de 20/06/22, Stefan Ram escreveu: [snip] After

Re: "CPython"

On 21/06/22 2:56 pm, Paulo da Silva wrote: Let's say they reimplement "reference python" CPython in Rust. What is better? Change the "reference python" CPython name to RPython, for example, or let it as CPython? The C implementation would still be called CPython, and the new implementation

Re: "CPython"

On 21/06/22 2:52 pm, Avi Gross wrote: This leads to the extremely important question of what would an implementation of Python, written completely in C++, be called? (Pronounced with a comical stutter) "C-p-p-python!") -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

On 21/06/22 2:38 pm, Paulo da Silva wrote: Notice that they are, for example, Jython and not JPython. Jython *was* originally called JPython, but that was judged to be a trademark violation and they were made to change it. I don't know how MicroPython has escaped the same fate to date. --

Re: "CPython"

On 6/20/22, Paulo da Silva wrote: > > Yes, but that does not necessarily means that the C has to refer to the > language of implementation. It may well be a "core" reference to > distinguish that implementation from others with different behaviors. If the reference implementation and API ever

Re: "CPython"

On 2022-06-21, Chris Angelico wrote: > Not sure why it's strange. The point is to distinguish "CPython" from > "Jython" or "Brython" or "PyPy" or any of the other implementations. > Yes, CPython has a special place because it's the reference > implementation and the most popular, but the one

Re: "CPython"

On Tue, 21 Jun 2022 at 13:12, Paulo da Silva wrote: > > Às 03:20 de 21/06/22, MRAB escreveu: > > On 2022-06-21 02:33, Chris Angelico wrote: > >> On Tue, 21 Jun 2022 at 11:13, Paulo da Silva > >> wrote: > >>> > >>> Às 20:01 de 20/06/22, Paulo da Silva escreveu: > >>> > Às 18:19 de 20/06/22,

Re: "CPython"

On Tue, 21 Jun 2022 at 12:53, Avi Gross via Python-list wrote: > > I don't even want to think fo what sound a C# Python would make. Probably about 277 Hz... ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

Às 03:20 de 21/06/22, MRAB escreveu: On 2022-06-21 02:33, Chris Angelico wrote: On Tue, 21 Jun 2022 at 11:13, Paulo da Silva wrote: Às 20:01 de 20/06/22, Paulo da Silva escreveu: > Às 18:19 de 20/06/22, Stefan Ram escreveu: >>    The same personality traits that make people react >>    to

Re: "CPython"

Às 02:33 de 21/06/22, Chris Angelico escreveu: On Tue, 21 Jun 2022 at 11:13, Paulo da Silva wrote: Às 20:01 de 20/06/22, Paulo da Silva escreveu: Às 18:19 de 20/06/22, Stefan Ram escreveu: The same personality traits that make people react to troll postings might make them spread

Re: "CPython"

- From: Paulo da Silva To: python-list@python.org Sent: Mon, Jun 20, 2022 8:53 pm Subject: Re: "CPython" Às 20:01 de 20/06/22, Paulo da Silva escreveu: > Às 18:19 de 20/06/22, Stefan Ram escreveu: >>    The same personality traits that make people react >>    to troll postin

Re: "CPython"

On 2022-06-21 02:33, Chris Angelico wrote: On Tue, 21 Jun 2022 at 11:13, Paulo da Silva wrote: Às 20:01 de 20/06/22, Paulo da Silva escreveu: > Às 18:19 de 20/06/22, Stefan Ram escreveu: >>The same personality traits that make people react >>to troll postings might make them spread

Re: "CPython"

On Tue, 21 Jun 2022 at 11:13, Paulo da Silva wrote: > > Às 20:01 de 20/06/22, Paulo da Silva escreveu: > > Às 18:19 de 20/06/22, Stefan Ram escreveu: > >>The same personality traits that make people react > >>to troll postings might make them spread unconfirmed > >>ideas about the

Re: "CPython"

Às 20:01 de 20/06/22, Paulo da Silva escreveu: Às 18:19 de 20/06/22, Stefan Ram escreveu:    The same personality traits that make people react    to troll postings might make them spread unconfirmed    ideas about the meaning of "C" in "CPython".    The /core/ of CPython is written in C.   

Re: "CPython"

On 21/06/2022 10.02, Chris Angelico wrote: > On Tue, 21 Jun 2022 at 08:01, dn wrote: >> >> On 21/06/2022 09.47, Roel Schroeven wrote: >> ... >> >>> So we have an untrustworthy site that's the only one to claim that >>> CPython is short for Core Python, and we have an official site that says >>>

Re: "CPython"

On Tue, 21 Jun 2022 at 08:01, dn wrote: > > On 21/06/2022 09.47, Roel Schroeven wrote: > ... > > > So we have an untrustworthy site that's the only one to claim that > > CPython is short for Core Python, and we have an official site that says > > CPython is so named because it's written in C. Hm,

Re: "CPython"

On Tue, 21 Jun 2022 at 07:48, Roel Schroeven wrote: > > Paulo da Silva schreef op 20/06/2022 om 21:01: > > Às 18:19 de 20/06/22, Stefan Ram escreveu: > > >The same personality traits that make people react > > >to troll postings might make them spread unconfirmed > > >ideas about the

Re: "CPython"

On 21/06/2022 09.47, Roel Schroeven wrote: ... > So we have an untrustworthy site that's the only one to claim that > CPython is short for Core Python, and we have an official site that says > CPython is so named because it's written in C. Hm, which one to believe? ...and so you can C that the

Re: "CPython"

Paulo da Silva schreef op 20/06/2022 om 21:01: Às 18:19 de 20/06/22, Stefan Ram escreveu: >The same personality traits that make people react >to troll postings might make them spread unconfirmed >ideas about the meaning of "C" in "CPython". > >The /core/ of CPython is written

Re: "CPython"

On Tue, 21 Jun 2022 at 06:31, Stefan Ram wrote: > > Paulo da Silva writes: > >Do you have any credible reference to your assertion "The "C" in > >"CPython" stands for C."? > > Whether a source is considered "credible" is something > everyone must decide for themselves. > > I can say that

Re: "CPython"

On Mon, 20 Jun 2022 20:01:51 +0100, Paulo da Silva declaimed the following: >Not so "unconfirmed"! >Look at this article, I recently read: >https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/ > >There is a sentence in ther that begins with "CPython,

Re: "CPython"

Às 18:19 de 20/06/22, Stefan Ram escreveu: The same personality traits that make people react to troll postings might make them spread unconfirmed ideas about the meaning of "C" in "CPython". The /core/ of CPython is written in C. CPython is the /canonical/ implementation of

RE: cpython and python and visual studio 2019

Never mind. I figured it out myself. It's not documented very well. From: jsch...@sbcglobal.net Sent: Thursday, June 9, 2022 11:17 AM To: 'python-list@python.org' Subject: cpython and python and visual studio 2019 I contacted Visual Studio 2019 support about this and they referred

Re: Cpython: when to incref before insertdict

On Sun, 6 Mar 2022 at 03:20, Inada Naoki wrote: > In general, when reference is borrowed from a caller, the reference is > available during the API. > But merge_dict borrows reference of key/value from other dict, not caller. > [...] > Again, insertdict takes the reference. So _PyDict_FromKeys()

Re: Cpython: when to incref before insertdict

On Sat, Mar 5, 2022 at 11:22 PM Marco Sulla wrote: > > I noticed that some functions inside dictobject.c that call insertdict > or PyDict_SetItem do an incref of key and value before the call, and a > decref after it. An example is dict_merge. First of all, insertdict and PyDict is totally

Re: CPython / Decimal and bit length of value.

Il 03/09/2021 22:09, Nacnud Nac ha scritto: Hi, Is there a quick way to get the number of bits required to store the value in a Decimal class? What obvious thing am I missing? I'm working with really large integers, say, in the order of 5_000_000 of ASCII base 10 digits. It seems the function

Re: CPython compiled failed in macOS

You may need to clean your source tree. "make distclean" or "git clean -fx". 2019年5月22日(水) 13:34 Windson Yang : > > version: macOS 10.14.4, Apple LLVM version 10.0.1 (clang-1001.0.46.4). > > I cloned the CPython source code from GitHub then compiled it which used to > work quite well. However, I

Re: cpython version

On Sun, Aug 13, 2017 at 10:59 PM, Gilmeh Serda wrote: > On Sat, 12 Aug 2017 10:24:06 -0400, Larry Martell wrote: > >> now I have prospective client that refuses to run linux, even in a VM. >> So I am tying to get my app running on Windows Server 2016, piece by

Re: cpython version

On Sat, Aug 12, 2017 at 10:09 AM, Chris Angelico wrote: > On Sat, Aug 12, 2017 at 10:24 PM, Larry Martell > wrote: >> On Sat, Aug 12, 2017 at 8:22 AM, Larry Martell >> wrote: >>> For the first time in my 30+ year career I am,

Re: cpython version

On Sat, Aug 12, 2017 at 10:24 PM, Larry Martell wrote: > On Sat, Aug 12, 2017 at 8:22 AM, Larry Martell > wrote: >> For the first time in my 30+ year career I am, unfortunately, working >> on Windows. A package I need, rpy2, comes in various

Re: cpython version

On Sat, Aug 12, 2017 at 8:22 AM, Larry Martell wrote: > For the first time in my 30+ year career I am, unfortunately, working > on Windows. A package I need, rpy2, comes in various flavors for > different cpython versions: > > rpy2‑2.7.8‑cp27‑none‑win32.whl >

Re: CPython Class variable exposed to Python is altered.

Le 12/04/17 à 11:47, Peter Otten a écrit : Vincent Vande Vyvre wrote: No, no warning. For the truth, this code is copy-pasted from the doc. https://docs.python.org/3.5//extending/newtypes.html#adding-data-and-methods-to-the-basic-example But the example expects objects (the big O), not

Re: CPython Class variable exposed to Python is altered.

Vincent Vande Vyvre wrote: > Le 12/04/17 à 10:51, Peter Otten a écrit : >> Vincent Vande Vyvre wrote: >> >>> Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit : Hi, Learning CPython, I've made this simple exercice, a module test which contains an object Test. The

Re: CPython Class variable exposed to Python is altered.

Le 12/04/17 à 10:51, Peter Otten a écrit : Vincent Vande Vyvre wrote: Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit : Hi, Learning CPython, I've made this simple exercice, a module test which contains an object Test. The object Test has an attribute name, fixed at instanciation. So, I

Re: CPython Class variable exposed to Python is altered.

Vincent Vande Vyvre wrote: > Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit : >> Hi, >> >> Learning CPython, I've made this simple exercice, a module test which >> contains an object Test. >> >> The object Test has an attribute name, fixed at instanciation. >> >> So, I try my code with a

Re: CPython Class variable exposed to Python is altered.

Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit : Hi, Learning CPython, I've made this simple exercice, a module test which contains an object Test. The object Test has an attribute name, fixed at instanciation. So, I try my code with a script: ---

Re: CPython 2.7: Weakset data changing size during internal iteration

On Fri, 01 Jun 2012 20:24:30 -0700, Temia Eszteri wrote: On 02 Jun 2012 03:05:01 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I doubt that very much. If you are using threads, it is more likely your code has a race condition where you are modifying a weak set at the same

Re: CPython 2.7: Weakset data changing size during internal iteration

On 03 Jun 2012 16:20:11 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: And should I have known this from your initial post? I did discuss the matter with Terry Reedy, actually, but I guess since the newsgroup-to-mailing list mirror is one-way, there's no actual way you could've

Re: CPython 2.7: Weakset data changing size during internal iteration

On 6/1/2012 7:40 PM, Temia Eszteri wrote: Given that len(weakset) is defined (sensibly) as the number of currently active members, it must count. weakset should really have .__bool__ method that uses any() instead of sum(). That might reduce, but not necessarily eliminate your problem. Think

Re: CPython 2.7: Weakset data changing size during internal iteration

On 6/1/2012 11:23 AM, Temia Eszteri wrote: I've got a bit of a problem - my project uses weak sets in multiple areas, the problem case in particular being to indicate what objects are using a particular texture, if any, so that its priority in OpenGL can be adjusted to match at the same time as

Re: CPython 2.7: Weakset data changing size during internal iteration

On Fri, 01 Jun 2012 18:42:22 -0400, Terry Reedy tjre...@udel.edu wrote: I gather that the .references attribute is sometimes/always a weakset. To determine its boolean value, it computes its length. For regular sets, this is sensible as .__len__() returns a pre-computed value. Indeed. Back

Re: CPython 2.7: Weakset data changing size during internal iteration

On Fri, 01 Jun 2012 08:23:44 -0700, Temia Eszteri wrote: I've got a bit of a problem - my project uses weak sets in multiple areas, the problem case in particular being to indicate what objects are using a particular texture, if any, so that its priority in OpenGL can be adjusted to match at

Re: CPython 2.7: Weakset data changing size during internal iteration

On 02 Jun 2012 03:05:01 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I doubt that very much. If you are using threads, it is more likely your code has a race condition where you are modifying a weak set at the same time another thread is trying to iterate over it (in this

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

On Thu, 2012-05-17 at 11:13 +1000, Chris Angelico wrote: On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote: A record is an interesting critter -- it is given life either from the user or from the disk-bound data; its fields can then change, but those changes are not

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

On Wed, May 16, 2012 at 3:33 PM, Ethan Furman et...@stoneleaf.us wrote: Just hit a snag: In cPython the deterministic garbage collection allows me a particular optimization when retrieving records from a dbf file -- namely, by using weakrefs I can tell if the record is still in memory and

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

On 17 May 2012 07:33, Ethan Furman et...@stoneleaf.us wrote: Just hit a snag: In cPython the deterministic garbage collection allows me a particular optimization when retrieving records from a dbf file -- namely, by using weakrefs I can tell if the record is still in memory and active, and

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

Ian Kelly wrote: On Wed, May 16, 2012 at 3:33 PM, Ethan Furman et...@stoneleaf.us wrote: Just hit a snag: In cPython the deterministic garbage collection allows me a particular optimization when retrieving records from a dbf file -- namely, by using weakrefs I can tell if the record is still

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

Tim Delaney wrote: On 17 May 2012 07:33, Ethan Furman wrote: Just hit a snag: In cPython the deterministic garbage collection allows me a particular optimization when retrieving records from a dbf file -- namely, by using weakrefs I can tell if the record is still in memory and active, and if

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote: A record is an interesting critter -- it is given life either from the user or from the disk-bound data;  its fields can then change, but those changes are not reflected on disk until .write_record() is called;  I do this

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

On 17 May 2012 11:13, Chris Angelico ros...@gmail.com wrote: On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote: A record is an interesting critter -- it is given life either from the user or from the disk-bound data; its fields can then change, but those changes are

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

Chris Angelico wrote: On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote: A record is an interesting critter -- it is given life either from the user or from the disk-bound data; its fields can then change, but those changes are not reflected on disk until .write_record()

Re: CPython thread starvation

On 4/28/2012 1:04 PM, Paul Rubin wrote: Roy Smithr...@panix.com writes: I agree that application-level name cacheing is wrong, but sometimes doing it the wrong way just makes sense. I could whip up a simple cacheing wrapper around getaddrinfo() in 5 minutes. Depending on the environment

Re: CPython thread starvation

In article 7xipgj8vxh@ruckus.brouhaha.com, Paul Rubin no.email@nospam.invalid wrote: Roy Smith r...@panix.com writes: I agree that application-level name cacheing is wrong, but sometimes doing it the wrong way just makes sense. I could whip up a simple cacheing wrapper around

Re: CPython thread starvation

In article 7xy5pgqwto@ruckus.brouhaha.com, Paul Rubin no.email@nospam.invalid wrote: John Nagle na...@animats.com writes: I may do that to prevent the stall. But the real problem was all those DNS requests. Parallizing them wouldn't help much when it took hours to grind through

Re: CPython thread starvation

Sprinkle time.sleep(0) liberally throughout your code where you think natural processing breaks should be. Even in while loops. It's lame but is the only way to make Python multithreading task switch fairly. Your compute intensive tasks need a time.sleep(0) in their loops. This prevents

Re: CPython thread starvation

On Sat, Apr 28, 2012 at 11:46 PM, Danyel Lawson danyellaw...@gmail.com wrote: The DNS lookup is one of those things that may make sense to run as a separate daemon process that listens on a socket. Yeah, it does. One that listens on port 53, TCP and UDP, perhaps. :) You've just recommended

Re: CPython thread starvation

I'm glad I thought of it. ;) But the trick is to use port 5353 and set a really short timeout on responses in the config for the DNS cache. On Sat, Apr 28, 2012 at 10:15 AM, Chris Angelico ros...@gmail.com wrote: On Sat, Apr 28, 2012 at 11:46 PM, Danyel Lawson danyellaw...@gmail.com wrote:

Re: CPython thread starvation

On Sun, Apr 29, 2012 at 12:27 AM, Danyel Lawson danyellaw...@gmail.com wrote: I'm glad I thought of it. ;) But the trick is to use port 5353 and set a really short timeout on responses in the config for the DNS cache. I don't think false timeouts are any better than true ones, if you actually

Re: CPython thread starvation

Roy Smith r...@panix.com writes: I agree that application-level name cacheing is wrong, but sometimes doing it the wrong way just makes sense. I could whip up a simple cacheing wrapper around getaddrinfo() in 5 minutes. Depending on the environment (both technology and bureaucracy),

Re: CPython thread starvation

On 4/27/2012 20:54, John Nagle wrote: I have a multi-threaded CPython program, which has up to four threads. One thread is simply a wait loop monitoring the other three and waiting for them to finish, so it can give them more work to do. When the work threads, which read web pages and then parse

Re: CPython thread starvation

John Nagle na...@animats.com writes: I know that the CPython thread dispatcher sucks, but I didn't realize it sucked that bad. Is there a preference for running threads at the head of the list (like UNIX, circa 1979) or something like that? I think it's left up to the OS thread scheduler,

Re: CPython thread starvation

On 27/04/2012 23:30, Dennis Lee Bieber wrote: Oh, continuation thought... If the workers are calling into C-language operations, unless those operations release the GIL, it doesn't matter what the OS or Python thread switch timings are. The OS may interrupt the thread (running

Re: CPython thread starvation

On Apr 27, 2:54 pm, John Nagle na...@animats.com wrote:      I have a multi-threaded CPython program, which has up to four threads.  One thread is simply a wait loop monitoring the other three and waiting for them to finish, so it can give them more work to do.  When the work threads, which

Re: CPython thread starvation

On 4/27/2012 6:25 PM, Adam Skutt wrote: On Apr 27, 2:54 pm, John Naglena...@animats.com wrote: I have a multi-threaded CPython program, which has up to four threads. One thread is simply a wait loop monitoring the other three and waiting for them to finish, so it can give them more work

Re: CPython thread starvation

On Sat, Apr 28, 2012 at 1:35 PM, John Nagle na...@animats.com wrote: On CentOS, getaddrinfo() at the glibc level doesn't always cache locally (ref https://bugzilla.redhat.com/show_bug.cgi?id=576801).  Python doesn't cache either. How do you manage your local cache? The Python getaddrinfo

Re: CPython thread starvation

John Nagle na...@animats.com writes: The code that stored them looked them up with getaddrinfo(), and did this while a lock was set. Don't do that!! Added a local cache in the program to prevent this. Performance much improved. Better to release the lock while the getaddrinfo is

Re: CPython thread starvation

On 4/27/2012 9:20 PM, Paul Rubin wrote: John Naglena...@animats.com writes: The code that stored them looked them up with getaddrinfo(), and did this while a lock was set. Don't do that!! Added a local cache in the program to prevent this. Performance much improved. Better to

Re: CPython thread starvation

John Nagle na...@animats.com writes: I may do that to prevent the stall. But the real problem was all those DNS requests. Parallizing them wouldn't help much when it took hours to grind through them all. True dat. But building a DNS cache into the application seems like a kludge. Unless

Re: CPython thread starvation

On 4/27/2012 9:55 PM, Paul Rubin wrote: John Naglena...@animats.com writes: I may do that to prevent the stall. But the real problem was all those DNS requests. Parallizing them wouldn't help much when it took hours to grind through them all. True dat. But building a DNS cache into

Re: CPython on the Web

On 1/3/2011 11:13 PM, azakai wrote: On Jan 3, 10:11 pm, John Naglena...@animats.com wrote: On 1/1/2011 11:26 PM, azakai wrote: Hello, I hope this will be interesting to people here: CPython running on the web, http://syntensity.com/static/python.html That isn't a new implementation of

Re: CPython on the Web

On Jan 3, 4:55 pm, azakai alonmozi...@gmail.com wrote: But through a combination of optimizations on the side of Emscripten (getting all LLVM optimizations to work when compiling to JS) and on the side of the browsers (optimizing accesses on typed arrays in JS, etc.), then I hope the code will

Re: CPython on the Web

On Jan 4, 1:11 am, John Nagle na...@animats.com wrote: On 1/1/2011 11:26 PM, azakai wrote: Hello, I hope this will be interesting to people here: CPython running on the web, http://syntensity.com/static/python.html That isn't a new implementation of Python, but rather CPython 2.7.1,

Re: CPython on the Web

On 01/04/2011 12:38 PM, gry wrote: On Jan 4, 1:11 am, John Nagle na...@animats.com wrote: On 1/1/2011 11:26 PM, azakai wrote: Hello, I hope this will be interesting to people here: CPython running on the web, http://syntensity.com/static/python.html

Re: CPython on the Web

On Jan 2, 5:55 pm, Gerry Reno gr...@verizon.net wrote: I tried printing sys.path and here is the output: ['', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7/', '/usr/local/lib/python2.7/plat-linux2', '/usr/local/lib/python2.7/lib-tk', '/usr/local/lib/python2.7/lib-old',

Re: CPython on the Web

azakai alonmozi...@gmail.com writes: Hello, I hope this will be interesting to people here: CPython running on the web, http://syntensity.com/static/python.html That isn't a new implementation of Python, but rather CPython 2.7.1, compiled from C to JavaScript using Emscripten and LLVM. For

Re: CPython on the Web

On 01/03/2011 03:10 PM, azakai wrote: On Jan 2, 5:55 pm, Gerry Reno gr...@verizon.net wrote: I tried printing sys.path and here is the output: ['', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7/', '/usr/local/lib/python2.7/plat-linux2', '/usr/local/lib/python2.7/lib-tk',

Re: CPython on the Web

On 01/03/2011 03:13 PM, Diez B. Roggisch wrote: A fun hack. Have you bothered to compare it to the PyPy javascript backend - perfomance-wise, that is? Diez I don't think that exists anymore. Didn't that get removed from PyPy about 2 years ago? Regards, Gerry --

Re: CPython on the Web

Gerry Reno gr...@verizon.net writes: On 01/03/2011 03:13 PM, Diez B. Roggisch wrote: A fun hack. Have you bothered to compare it to the PyPy javascript backend - perfomance-wise, that is? Diez I don't think that exists anymore. Didn't that get removed from PyPy about 2 years ago?

Re: CPython on the Web

On 01/03/2011 05:55 PM, Diez B. Roggisch wrote: Gerry Reno gr...@verizon.net writes: On 01/03/2011 03:13 PM, Diez B. Roggisch wrote: A fun hack. Have you bothered to compare it to the PyPy javascript backend - perfomance-wise, that is? Diez I don't think that exists

Re: CPython on the Web

On Jan 2, 4:58 pm, pyt...@bdurham.com wrote: Azakai/Gerry, Errors when using Firefox 3.6.3: firefox 3.6.13 openbsd i386 4.8 -current error console has some errors: editor not defined module not define too much recursion nothing interested happened on the web page, but wonderful project

Re: CPython on the Web

On Jan 3, 12:13 pm, de...@web.de (Diez B. Roggisch) wrote: A fun hack. Have you bothered to compare it to the PyPy javascript backend - perfomance-wise, that is? Gerry already gave a complete and accurate answer to the status of this project in comparison to PyPy and pyjamas. Regarding

Re: CPython on the Web

On Jan 3, 12:23 pm, Gerry Reno gr...@verizon.net wrote: On 01/03/2011 03:10 PM, azakai wrote: On Jan 2, 5:55 pm, Gerry Reno gr...@verizon.net wrote: I tried printing sys.path and here is the output: ['', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7/',

Re: CPython on the Web

FireFox 3.6.13 on MacOS X Tiger (10.4.11) fails: Error: too much recursion Error: Modules is not defined Source File: http://synthensity.com/static/python.html /Jean On Jan 2, 11:26 pm, Wolfgang Strobl ne...@mystrobl.de wrote: azakai alonmozi...@gmail.com: On Jan 2, 4:58 pm,

Re: CPython on the Web

FYI, The example http://syntensity.com/static/python.html works fine in Safari 4.1.3 on MacOS X Tiger (10.4.11). /Jean On Jan 3, 5:59 pm, azakai alonmozi...@gmail.com wrote: On Jan 3, 12:23 pm, Gerry Reno gr...@verizon.net wrote: On 01/03/2011 03:10 PM, azakai wrote: On Jan 2,

  1   2   >