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.
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
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
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
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!
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?
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.
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".
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.
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'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?
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 .
> > 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.
> >  http://bugs.python.org/issue1739468