Good debugger for CPython 3.2?

What's a good debugger for CPython 3.2? I'd prefer to use it on Linux Mint 13, and I'd be happy with something based on X11 or curses. I tried winpdb, but it was cranky that Linux didn't have a spawn callable. Why they didn't use the portable subprocess module escapes m

Re: PyPy, is it a 1:1 replacement for CPython?

On 7/20/2012 11:52 PM, Alec Taylor wrote: ask on PyPy's list But yes, it is designed as a 1:1 replacement of CPython It is a replacement for some late 2.x versions but not, at present, for Python 3. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list

Re: PyPy, is it a 1:1 replacement for CPython?

some C extension modules, but the PyPy-C boundary is a bit of a slowish hack called cpyext. They're working on a new CFFI module/library that hopes to work nicely with tailor-made modules, which, curiously enough, requires a C compiler at runtime. I gather they've got it running on

Re: PyPy, is it a 1:1 replacement for CPython?

On Sat, 21 Jul 2012 13:35:21 +1000, Simon Cropper wrote: > Hi, > > Can you use PyPy as a direct replacement for the normal python or is it > a specialized compiler that can only work with libraries that are > manipulated to operate within its constraints (if it has any). PyPy should work perfect

Re: PyPy, is it a 1:1 replacement for CPython?

ask on PyPy's list But yes, it is designed as a 1:1 replacement of CPython On Sat, Jul 21, 2012 at 1:35 PM, Simon Cropper wrote: > Hi, > > Can you use PyPy as a direct replacement for the normal python or is it a > specialized compiler that can only work with libraries that are

PyPy, is it a 1:1 replacement for CPython?

Hi, Can you use PyPy as a direct replacement for the normal python or is it a specialized compiler that can only work with libraries that are manipulated to operate within its constraints (if it has any). Are there any issues with using PyPy? For example, if programs are created under PyPy a

Re: when "normal" parallel computations in CPython will be implemented at last?

John Nagle wrote: > >It would be "un-Pythonic" to have real concurrency in Python. >You wouldn't be able to patch code running in one thread from >another thread. Some of the dynamic features of Python >would break. If you want fine-grained concurrency, you need >controlled isolation betwee

Re: when "normal" parallel computations in CPython will be implemented at last?

Dan Stromberg, 01.07.2012 21:28: > On Sun, Jul 1, 2012 at 11:58 AM, Thomas Jollans wrote: >> On 07/01/2012 08:44 PM, Dan Stromberg wrote: >>> IronPython, sadly, lacks a python standard library. >> >> Beg pardon? >> >> https://github.com/IronLanguages/main/tree/master/External.LCA_RESTRICTED/Languag

Re: when "normal" parallel computations in CPython will be implemented at last?

On 7/1/2012 10:51 AM, dmitrey wrote: hi all, are there any information about upcoming availability of parallel computations in CPython without modules like multiprocessing? I mean something like parallel "for" loops, or, at least, something without forking with copying huge amounts o

Re: when "normal" parallel computations in CPython will be implemented at last?

Thomas Jollans wrote: >There is, of course, Stackless Python. >http://stackless.com/ Stackless Python doesn't really address the original poster's problem as the GIL still effectively limits Python code running in one thread at a time. Ross Ridge -- l/

Re: when "normal" parallel computations in CPython will be implemented at last?

On 07/01/2012 09:28 PM, Dan Stromberg wrote: > > > On Sun, Jul 1, 2012 at 11:58 AM, Thomas Jollans > wrote: > > On 07/01/2012 08:44 PM, Dan Stromberg wrote: > > IronPython, sadly, lacks a python standard library. > > > Beg pardon? > > > https://githu

Re: when "normal" parallel computations in CPython will be implemented at last?

On Sun, Jul 1, 2012 at 11:58 AM, Thomas Jollans wrote: > On 07/01/2012 08:44 PM, Dan Stromberg wrote: > > IronPython, sadly, lacks a python standard library. > > > Beg pardon? > > > https://github.com/IronLanguages/main/tree/master/External.LCA_RESTRICTED/Languages/IronPython/27/Lib > Perhaps thi

Re: when "normal" parallel computations in CPython will be implemented at last?

occasional topic on the python-dev > mailing list. No one has managed it yet.""" There's also this, recently written by one of CPython's core devs: http://python-notes.boredomandlaziness.org/en/latest/python3/questions_and_answers.html#but-but-surely-fixing-the-gil

Re: when "normal" parallel computations in CPython will be implemented at last?

On 07/01/2012 08:44 PM, Dan Stromberg wrote: > IronPython, sadly, lacks a python standard library. Beg pardon? https://github.com/IronLanguages/main/tree/master/External.LCA_RESTRICTED/Languages/IronPython/27/Lib -- http://mail.python.org/mailman/listinfo/python-list

Re: when "normal" parallel computations in CPython will be implemented at last?

On 07/01/2012 07:51 PM, dmitrey wrote: > hi all, > are there any information about upcoming availability of parallel > computations in CPython without modules like multiprocessing? I mean > something like parallel "for" loops, or, at least, something without > forking wit

Re: when "normal" parallel computations in CPython will be implemented at last?

If something happens with this for CPython, it'll likely come from Pypy developers first. They seem to be interested in doing things in a way that is (or can be made) compatible with CPython. If you want to help them along, they're taking donations to fund the work, or you could donat

when "normal" parallel computations in CPython will be implemented at last?

hi all, are there any information about upcoming availability of parallel computations in CPython without modules like multiprocessing? I mean something like parallel "for" loops, or, at least, something without forking with copying huge amounts of RAM each time and possibility

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

On 03 Jun 2012 16:20:11 GMT, Steven D'Aprano 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 known. :/ Sigh, another problem out

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 > 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

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 i

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

On 02 Jun 2012 03:05:01 GMT, Steven D'Aprano 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 case, to >determine it's length), a

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

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

On Fri, 01 Jun 2012 18:42:22 -0400, Terry Reedy 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 when I was using

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 i

CPython 2.7: Weakset data changing size during internal iteration

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 it being (de)referenced by any explicit calls.

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 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

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

Chris Angelico wrote: On Thu, May 17, 2012 at 9:01 AM, Ethan Furman 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 thi

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

On 17 May 2012 11:13, Chris Angelico wrote: > On Thu, May 17, 2012 at 9:01 AM, Ethan Furman 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 unt

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

On Thu, May 17, 2012 at 9:01 AM, Ethan Furman 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 > because I am fr

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!)

Ian Kelly wrote: On Wed, May 16, 2012 at 3:33 PM, 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

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

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,

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

On Wed, May 16, 2012 at 3:33 PM, 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

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

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 so not hit the disk to get the data; with PyPy (and

Re: CPython thread starvation

In article <7xipgj8vxh@ruckus.brouhaha.com>, Paul Rubin wrote: > Roy Smith 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. Dep

Re: CPython thread starvation

On 4/28/2012 1:04 PM, Paul Rubin wrote: Roy Smith 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

Re: CPython thread starvation

Roy Smith 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), getting a cach

Re: CPython thread starvation

On Sun, Apr 29, 2012 at 12:27 AM, Danyel Lawson 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 know the true ones. Bu

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 wrote: > On Sat, Apr 28, 2012 at 11:46 PM, Danyel Lawson > wrote: >> The DNS lookup is one of those things

Re: CPython thread starvation

On Sat, Apr 28, 2012 at 11:46 PM, Danyel Lawson 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 installing a separate ca

Re: CPython thread starvation

ertain time if they don't see their response. Requires hand/algorithmic tweaking for this to work correctly across different machines. On Fri, Apr 27, 2012 at 2:54 PM, John Nagle wrote: >    I have a multi-threaded CPython program, which has up to four > threads.  One thread is sim

Re: CPython thread starvation

In article <7xy5pgqwto@ruckus.brouhaha.com>, Paul Rubin wrote: > John Nagle 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 bui

Re: CPython thread starvation

On 4/27/2012 9:55 PM, Paul Rubin wrote: John Nagle 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 seem

Re: CPython thread starvation

John Nagle 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 the number of

Re: CPython thread starvation

On 4/27/2012 9:20 PM, Paul Rubin wrote: John Nagle 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

Re: CPython thread starvation

John Nagle 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 running, if you can

Re: CPython thread starvation

On Sat, Apr 28, 2012 at 1:35 PM, John Nagle 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 function doesn't

Re: CPython thread starvation

On 4/27/2012 6:25 PM, Adam Skutt wrote: On Apr 27, 2:54 pm, 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

Re: CPython thread starvation

On Apr 27, 2:54 pm, 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 re

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 C

Re: CPython thread starvation

John Nagle 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

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

CPython thread starvation

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 them, are compute-bound, I&#x

SSL connection issue with Windows CPython

Hi all, I've written a Python API for the Windows Azure Service Management web- service. Requests against the web-service are HTTPS with a client certificate used for authentication. This works fine with CPython (tested with 2.6 and 2.7) on Linux, but something is amiss with the SSL conne

Re: Python language changes that first shipped in something besides CPython?

Terry Reedy writes: > For that type of feature, I am pretty sure the answer is no. There are > developers from other implementations that have cpython commit rights > and they have contributed new tests. Modules? I have never seen 'We > first did this with xpython on the t

Re: Python language changes that first shipped in something besides CPython?

On 3/8/2011 4:39 PM, Larry Hastings wrote: Adding to my previous response, extended slices and ellipses were added for numerical python, but that is cpython extension, not alternative. The 3.x memoryview came from there too, I believe. -- Terry Jan Reedy -- http://mail.python.org/mailman

Re: Python language changes that first shipped in something besides CPython?

On 3/8/2011 4:39 PM, Larry Hastings wrote: I'm doing a talk at PyCon about changes to the Python language. I'm wondering: are there any Python language changes that first shipped in an implementation of Python besides CPython? The sort of answer I'm looking for: "set liter

Python language changes that first shipped in something besides CPython?

I'm doing a talk at PyCon about changes to the Python language. I'm wondering: are there any Python language changes that first shipped in an implementation of Python besides CPython? The sort of answer I'm looking for: "set literals first shipped in Jython 2.2, si

Re: the C header file when extending CPython

Yingjie Lan wrote: > I am wondering when extending Python (CPython), what should be put into > the C header file? Any guidelines? You don't even need to write a header file at all. There are no Python- specific requirements to put anything into a header file, though you might want t

the C header file when extending CPython

Hi, I am wondering when extending Python (CPython), what should be put into the C header file? Any guidelines? Thanks, Yingjie -- http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

On 01/04/2011 12:38 PM, gry wrote: > On Jan 4, 1:11 am, John Nagle 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, >>> &

Re: CPython on the Web

On Jan 4, 1:11 am, John Nagle 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 implement

Re: CPython on the Web

entually run quite fast, even > comparably to C. This is a very cool idea. It's quite fascinating to view the Javascript "machine code" for a complete CPython interpreter. I'm sure with a little work you'll be able to improve its performance, but I think "comparab

Re: CPython on the Web

On 1/3/2011 11:13 PM, azakai wrote: On Jan 3, 10:11 pm, John Nagle 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

Re: CPython on the Web

On Jan 3, 10:11 pm, John Nagle 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 implement

Re: CPython on the Web

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, compiled from C to JavaScript using Emscripten and LLVM. For

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 wrote: > On Jan 3, 12:23 pm, Gerry Reno wrote: > > > > > > > On 01/03/2011 03:10 PM, azakai wrote: > > > > On Jan 2, 5:55 pm, Gerry Reno wrote:

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 wrote: > azakai : > > >On Jan 2, 4:58 pm, pyt...@bdurham.com wrote: > >> Azakai/Gerry,

Re: CPython on the Web

On Jan 3, 12:23 pm, Gerry Reno wrote: > On 01/03/2011 03:10 PM, azakai wrote: > > > > > > > > > > > On Jan 2, 5:55 pm, Gerry Reno 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/

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 perfo

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 projec

Re: CPython on the Web

On 01/03/2011 05:55 PM, Diez B. Roggisch wrote: > Gerry Reno 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

Re: CPython on the Web

Gerry Reno 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? Ah,

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 -- http://mail.pyth

Re: CPython on the Web

On 01/03/2011 03:10 PM, azakai wrote: > On Jan 2, 5:55 pm, Gerry Reno 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

Re: CPython on the Web

azakai 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 Ems

Re: CPython on the Web

On Jan 2, 5:55 pm, Gerry Reno 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', > '/usr/local/lib/lib-dyn

Re: CPython on the Web

azakai : >On Jan 2, 4:58 pm, pyt...@bdurham.com wrote: >> Azakai/Gerry, >> >> > Errors when using Firefox 3.6.3: >> >> I'm running Firefox 3.6.1.3 and the interpreter is running fine. I guess that meant FIrefox 3.6.13 (without the last dot), the current stable version. I'm using Firefox 3.6.13 (

Re: CPython on the Web

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', '/usr/local/lib/lib-dynload'] Now, those paths must be on your machine

Re: CPython on the Web

On Jan 2, 4:58 pm, pyt...@bdurham.com wrote: > Azakai/Gerry, > > > Errors when using Firefox 3.6.3: > > I'm running Firefox 3.6.1.3 and the interpreter is running fine. > > I'm on Windows 7 Pro 64-bit. > > Malcolm Thanks for the info. To be honest I'm surprised it works there. I guess the error Ge

Re: CPython on the Web

On Jan 2, 3:14 pm, Gerry Reno wrote: > On 01/02/2011 05:53 PM, azakai wrote: > > > On Jan 2, 1:01 pm, Gerry Reno wrote: > > >> Ok, visiting this page: > > >>http://syntensity.com/static/python.html > > >> I do not see anything happen when I click 'execute' button.  I'm running > >> Firefox 3.6.3.

Re: CPython on the Web

Azakai/Gerry, > Errors when using Firefox 3.6.3: I'm running Firefox 3.6.1.3 and the interpreter is running fine. I'm on Windows 7 Pro 64-bit. Malcolm -- http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

On 01/02/2011 05:53 PM, azakai wrote: > On Jan 2, 1:01 pm, Gerry Reno wrote: > >> Ok, visiting this page: >> >> http://syntensity.com/static/python.html >> >> I do not see anything happen when I click 'execute' button. I'm running >> Firefox 3.6.3. >> >> > I've only tested with Firefox 4.

Re: CPython on the Web

running in a sandboxed manner. > > And what is the build toolchain that you need if you want to convert > your modules to be importable with this "CPython on the Web"? > Note that loading modules isn't implemented yet, but I'll work on it soon. The toolchain will

Re: CPython on the Web

On 01/02/2011 02:26 AM, 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, > compiled from C to JavaS

Re: CPython on the Web

On Jan 2, 5:52 am, "Octavian Rasnita" wrote: > > Then, how can the Python programs run on the "desktop"? > I suspect that the Python code is somehow translated to Javascript in order > to run on the browser. Am I right? To clarify, in this demo, CPython itself

Re: CPython on the Web

On Jan 2, 5:42 am, pyt...@bdurham.com wrote: > > 1. Are there plans to support IE 7 or 8? I think it might run slowly there, but otherwise sure, it should run - the code is intended to be valid JavaScript (if it isn't, that's a bug). Currently though a minor issue prevents it from running on IE, I

Re: CPython on the Web

From: "Katie T" Subject: Re: CPython on the Web > On Sun, Jan 2, 2011 at 7:26 AM, azakai wrote: >> The idea is that by compiling CPython itself, all the features of the >> language are immediately present, and at the latest version, unlike >> writing a new impl

Re: CPython on the Web

Azakai, WOW! That's incredible!! Thank you for sharing your work with the community. 1. Are there plans to support IE 7 or 8? 2. I'm not sure what you mean by non-static modules? Can we use modules such as json, pickle/cPickle, StringIO/cStringIO? 3. Is there a virtual file system we can take a

Re: CPython on the Web

On Sun, Jan 2, 2011 at 7:26 AM, azakai wrote: > The idea is that by compiling CPython itself, all the features of the > language are immediately present, and at the latest version, unlike > writing a new implementation which takes time and tends to lag behind. > As to why run it on th

CPython on the Web

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 more details on the conversion pr

Re: CPython Signal Handler Check for SIGKILL

On Mon, 19 Jul 2010 20:06:16 +0200, Antoine Pitrou wrote: > So, in short, Python doesn't check SIGKILL by itself. It's just > forbidden by the underlying C standard library, Actually, it's forbidden by the kernel. The C library just passes along the error to Python, which just passes it to the ap

Re: CPython Signal Handler Check for SIGKILL

Yes, yes, thank you both. That is exactly what I didn't understand, I knew it was some how linked to the C library and wasn't exactly being handled or decided at the Python layer, I just didn't understand the C part good enough. I have found the CPython source code that checks. I s

Re: CPython Signal Handler Check for SIGKILL

Hello, > I am not asking about the signals, I understand them, > I am asking about the registration of the SIGNAL handler and how it knows > that you are trying to register SIGKILL, you get an error like this. > > ./signal-catcher.py > Traceback (most recent call last): > File "./signal-catch

Re: CPython Signal Handler Check for SIGKILL

On 07/19/2010 07:28 PM, Scott McCarty wrote: > All, I just want to understand the C/Python piece better because I am > writing a tutorial on signals and I am using python to demonstrate. I > thought it would be fun to show that the SIGKILL is never processed, but > instead python errors out. There

CPython Signal Handler Check for SIGKILL

All, I just want to understand the C/Python piece better because I am writing a tutorial on signals and I am using python to demonstrate. I thought it would be fun to show that the SIGKILL is never processed, but instead python errors out. There is something in Python checking the SIGKILL signal h

CPython 3.1.1 docs error in noddy3 example?

"Extending and Embedding the Python Interpreter" §2.1.2, the noddy3 extension module example, uses "S" as format character for string arguments in its call to PyArg_ParseTupleAndKeywords. This causes Noddy to only accept bytes as arguments, instead of strings (format "U"). I suspect this is

Re: Understanding the CPython dict implementation

On Tue, 16 Mar 2010 16:04:22 -0400, Terry Reedy wrote: > On 3/16/2010 7:46 AM, Steven D'Aprano wrote: >> On Sun, 14 Mar 2010 19:39:46 -0400, Terry Reedy wrote: >> >>> I found this PyCon2010 presentation to be excellent: The Mighty >>> Dictionary, Branden Craig Rhodes, 30 min. > > Sorry, > http://

Re: Understanding the CPython dict implementation

On 3/16/2010 7:46 AM, Steven D'Aprano wrote: On Sun, 14 Mar 2010 19:39:46 -0400, Terry Reedy wrote: I found this PyCon2010 presentation to be excellent: The Mighty Dictionary, Branden Craig Rhodes, 30 min. Sorry, http://pycon.blip.tv/file/3332763/ which plays fine in FF3.6 on windows http

Re: Understanding the CPython dict implementation

On 16 Mar 2010, at 12:46 , Steven D'Aprano wrote: > On Sun, 14 Mar 2010 19:39:46 -0400, Terry Reedy wrote: > >> I found this PyCon2010 presentation to be excellent: The Mighty >> Dictionary, Branden Craig Rhodes, 30 min. >> http://pycon.blip.tv/file/3264041/ > > > Unfortunately, that clip seem

<    1   2   3   4   5   6   7   >