Mailman 3 September 2007 - Python-Dev

Making directories and zip files executable
by Nick Coghlan Sept. 12, 2007

Sept. 12, 2007

The local patch I have for PEP 366 is somewhat stale, and before I bring it up to date with SVN head, I'd like to close out the issue raised a while back regarding making zip files executable [1]. The original proposal was for a new command line switch, but PJE came up with a patch (attached to the roundup tracker item) that uses the existing import machinery to avoid the need for the extra command line switch (by checking if the argument is a valid sys.path entry before checking to see if it is an executable script). I personally like the idea (and PJE's approach), and the performance impact on script startup time appears to be negligible (although I haven't performed any high precision measurements - I'm just using the Linux time utility on a short test script with and without the patch). Are there any objections to my committing this? Cheers, Nick. [1] http://bugs.python.org/issue1739468 -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

2 3

SSL-protected server on python.org for testing?
by Bill Janssen Sept. 12, 2007

Sept. 12, 2007

The SSL tests currently use SSL-protected ports on gmail.com and Verisign for testing. That's not what they are for; I think we should shift to using SSL-protected ports on python.org somewhere. Are there any HTTPS servers, or SSL-protected POP or IMAP servers, currently running on python.org already that I could use? The "use" is an SSL handshake with the server, once or twice per test run. Bill

2 2

Removing the GIL (Me, not you!)
by Justin Tulloss Sept. 12, 2007

Sept. 12, 2007

Hi, I had a whole long email about exactly what I was doing, but I think I'll get to the point instead. I'm trying to implement a python concurrency API and would like to use cpython to do it. To do that, I would like to remove the GIL. So, since I'm new to interpreter hacking, some help would be appreciated. I've listed what I think the GIL does; if you guys could add to this list or refine it, I would very much appreciate it. Roles of the GIL: 1. Some global interpreter state/modules are protected (where are these globals at?) 2. When writing C extensions I can change the state of my python object without worrying about synchronization 3. When writing C extensions I can change my own internal C state without worrying about synchronization (unless I have other, non-python threads running) Does anyone know of a place where the GIL is required when not operating on a python object? It seems like this would never happen, and would make replacing the GIL somewhat easier. I've only started looking at the code recently, so please forgive my naivety. I'm still learning how the interpreter works on a high level, let alone all the nitty gritty details! Thanks, Justin

6 10

what versions of Python don't have the "addr" field in the socket object?
by Bill Janssen Sept. 12, 2007

Sept. 12, 2007

Looks like this change is bothering the error returns from my backported SSL code. I believe this is only in 2.5.1 and later -- can anyone confirm that? Bill ------------------------------------------------------------ r52906 | martin.v.loewis | 2006-12-03 03:23:45 -0800 (Sun, 03 Dec 2006) | 4 lines Patch #1544279: Improve thread-safety of the socket module by moving the sock_addr_t storage out of the socket object. Will backport to 2.5.

2 1

SSL package for Python 2.3 to 2.5
by Bill Janssen Sept. 11, 2007

Sept. 11, 2007

I've put up an initial source package at http://www.parc.com/janssen/transient/ssl-1.0.tar.gz which I've tested with Python 2.3.5 on Mac OS X 10.4.10 (Intel) and Python 2.5 on Fedora Core 7. Please send bugs you find to me at janssen(a)parc.com. Try "python setup.py build", then "python setup.py test". Bill

1 1

Re: [Python-Dev] re-using the Python setup.py file?
by Gregory P. Smith Sept. 11, 2007

Sept. 11, 2007

On 9/11/07, Bill Janssen <janssen(a)parc.com> wrote: > > I see that the setup.py at the top level of the Python distribution > does a lot of things wrt sensing compiler options, etc, that I'd like > to re-use in my SSL setup.py distribution file. I'm a bit curious > as to why this framework isn't in the distutils package? I suspect a combo of (a) nobody has done it yet and (b) many of the things done there felt too hackish to the person writing them. Regardless of (b) I'd place my money on (a). In maintaining external bsddb and hashlib module distributions for use on older pythons I have so far just pasted code as appropriate to/from the python setup.py and the separate distribution ones. Not ideal but trivial since once settled upon setup didn't change much.

1 0

re-using the Python setup.py file?
by Bill Janssen Sept. 11, 2007

Sept. 11, 2007

I see that the setup.py at the top level of the Python distribution does a lot of things wrt sensing compiler options, etc, that I'd like to re-use in my SSL setup.py distribution file. I'm a bit curious as to why this framework isn't in the distutils package? Bill

1 0

adding a "test" fork to a setup.py package
by Bill Janssen Sept. 11, 2007

Sept. 11, 2007

I'm packaging up the SSL support for Python 2.3, and I'd like to be able to include the unit test for it along with the package. Ideally, I'd like to be able to say % python setup.py build % python setup.py test and have the regrtest.py module run my tests. Any ideas (examples) of how to do that? Bill

3 3

Re: [Python-Dev] Making directories and zip files executable
by Phillip J. Eby Sept. 11, 2007

Sept. 11, 2007

At 10:48 AM 9/11/2007 -0700, Guido van Rossum wrote: >I could use a refresher on how PJE's patch solves Andy's problem. It does the same thing, but with __main__ instead of __zipmain__, and without needing the -z. So instead of "python -z foo.zip" you can just do "python foo.zip". This means you can use a reasonably cross-platform #! header that invokes Python via "env". If you tried to use -z with env, Andy's approach would either only work on BSDish platforms that support multiple options to a #! command, or else you'd have to ditch the "env" and hardcode the patht to Python. So not needing a command-line option improves the effective portability/usability of the executable zip file. Also, being able to run "python directory_to_be_zipped_later" also lets you test/develop your program without it needing to be zipped first. >On 9/11/07, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > > The local patch I have for PEP 366 is somewhat stale, and before I bring > > it up to date with SVN head, I'd like to close out the issue raised a > > while back regarding making zip files executable [1]. > > > > The original proposal was for a new command line switch, but PJE came up > > with a patch (attached to the roundup tracker item) that uses the > > existing import machinery to avoid the need for the extra command line > > switch (by checking if the argument is a valid sys.path entry before > > checking to see if it is an executable script). > > > > I personally like the idea (and PJE's approach), and the performance > > impact on script startup time appears to be negligible (although I > > haven't performed any high precision measurements - I'm just using the > > Linux time utility on a short test script with and without the patch). > > > > Are there any objections to my committing this? > > > > Cheers, > > Nick. > > > > [1] http://bugs.python.org/issue1739468

1 0

Compiler Python
by Carlos Martínez Sept. 11, 2007

Sept. 11, 2007

Hello Someone knows since as I can obtain the information detailed about the compiler of Python? (Table of tokens, lists of productions of the syntactic one , semantic restrictions...) Thanks.

2 1