But this has been raised before, and was rejected as not worth the
amount of work that would be required to achieve it.
In my understanding, there is an important difference between
it was rejected, and it was not done.
Regards,
Martin
___
I believe this is only in 2.5.1 and later -- can
anyone confirm that?
That's correct.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Guido van Rossum wrote:
I could use a refresher on how PJE's patch solves Andy's problem.
I'm not sure if you're asking about how you would execute a zip file
after the patch has been applied, or about the mechanics of how the
patch works. PJE's last post covered the former question, so I'll
On 9/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Now we are getting into details: you do NOT have to lock
an object to modify its reference count. An atomic
increment/decrement operation is enough.
One could measure the performance hit incurred by using atomic
operations for refcounting by
Brett We should probably document where all of these globals lists are
Brett instead of relying on looking for all file level static
Brett declarations or something.
I smell a wiki page.
Skip
Brett Or would there be benefit to moving things like this to the
Brett
Martin Now we are getting into details: you do NOT have to lock an
Martin object to modify its reference count. An atomic
Martin increment/decrement operation is enough.
Implemented in asm I suspect? For common CPUs this could just be part of
the normal Python distribution. For
I can't figure out how to build a Windows package for ssl-1.1.tar.gz,
and probably don't have the tools to do it anyway. I presume that
both a Windows machine and Visual Studio (because there's a C
extension) is required?
Anyone out there who's interested in the challenge?
It's at
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
By the way, I think the hostname matching provisions of 2818 (which
is, after all, only an informational RFC, not a standard) are poorly
thought out. Many machines have more hostnames than you can shake a
stick at, and often provide certs with the wrong hostname in them
(usually because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 12, 2007, at 2:05 PM, Bill Janssen wrote:
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.
Yes, port 443 on svn.python.org seems to work for this purpose.
Everyone OK with that? If so, I'll change the SSL test code.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 9/12/07, Nick Coghlan [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I could use a refresher on how PJE's patch solves Andy's problem.
I'm not sure if you're asking about how you would execute a zip file
after the patch has been applied, or about the mechanics of how the
patch works.
I can't figure out how to build a Windows package for ssl-1.1.tar.gz,
and probably don't have the tools to do it anyway. I presume that
both a Windows machine and Visual Studio (because there's a C
extension) is required?
Anyone out there who's interested in the challenge?
It's at
Thanks, Mark (and David, who replied to me personally). I'll update
the setup.py files with your suggestions and do a 1.2 (with more
metadata in it, too). Looks like the functionality is working for
people, even if the build is still a bit flakey.
Bill
* find_ssl() is along way from working on Windows. Python itself uses magic
to locate an SSL directory in the main Python directory's parent. On my
system, this is c:\src\openssl-0.9.7e, but obviously that could be almost
anywhere, and with almost any name. See PCBuild\build_ssl.py and
* find_ssl() is along way from working on Windows. Python itself
uses magic
to locate an SSL directory in the main Python directory's parent. On
my
system, this is c:\src\openssl-0.9.7e, but obviously that could be
almost
anywhere, and with almost any name. See PCBuild\build_ssl.py
Can't we look in the registry for this? We have a working Python;
perhaps we can just use a Windows-specific registry lookup to find
OpenSSL? (I'm just blue-skying here; I have no clue how things work
on Windows.)
Not really. Python itself, when building _ssl, doesn't look for a
On Wed, Sep 12, 2007, Bill Janssen wrote:
By the way, I think the hostname matching provisions of 2818 (which
is, after all, only an informational RFC, not a standard) are poorly
thought out. Many machines have more hostnames than you can shake a
stick at, and often provide certs with the
I was reading GvR's post on this and came up with a theory on how to
tackle the problem.
I ended up putting it in a blog post.
http://www.brainwavelive.com/blog/index.php?/archives/12-Suggestion-
for-removing-the-Python-Global-Interpreter-Lock.html
What do you think?
Prateek
On Sep 12,
What do you think?
I think what you are describing is the situation of today,
except in a less-performant way. The kernel *already*
implements such a synchronization server, except that
all CPUs can act as such. You write
Since we are guaranteeing that synchronized code is running on a single
Bill Janssen [EMAIL PROTECTED] writes:
In that case, I think your idea of just hard-coding a path is probably
the right thing to do. I'll add a note that this is how you need to do
it if you are going to try python setup.py build. Presumably the
binary then built with python setup.py bdist
21 matches
Mail list logo
