> The simplest way to do verification is to allow the application to
> provide a set of root certs that it would like to verify against, and
> use the built-in OpenSSL verification procedure.
That's good. I don't recall whether you planned for this, however,
it would then be necessary to find out
Amaury Forgeot d'Arc schrieb:
> Hello,
>
> Martin v. Löwis wrote:
>> I think the obvious thing you missed is that the problem got fixed
>> already. Whether the documentation system should be more defensive and
>> work with 2.5.0 also is a different question.
>
> You are right. python 2.5.1 correc
On 8/20/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> PEP 302 ("New Import Hooks") has an optional extensions section so
> that tools like py2exe and py2app have an easier time. Part of the
> optional extensions is the method get_code that is to return the code
> object for the specified method (i
PEP 302 ("New Import Hooks") has an optional extensions section so
that tools like py2exe and py2app have an easier time. Part of the
optional extensions is the method get_code that is to return the code
object for the specified method (if the loader can handle it).
But there is a lack in the def
Maciej Fijalkowski wrote:
> IMHO this shouldn't segfault:
>
> import thread
>
> while 1:
> f = open("/tmp/dupa", "w")
> thread.start_new_thread(f.close, ())
> f.close()
>
> while it does on cpython 2.5.1 , linux box.
>
> May I consider this a bug?
Yes, that's a bug. Please file it
> * Allow certificate validation. This is a bit tricky; typically
> certs are validated against some database of root certificates, so you
> need a whole infrastructure to maintain that database. Currently, we
> don't have one, so no certs can be validated. We could add a switc
Steve Holden wrote:
> Martin v. Löwis wrote:
>>> The only environment variables that don't appear in the shell output
>>> from the env command are INFOPATH, MAKE_MODE and PLAT. I am still flummoxed.
>> At this point, I'd recommend to perform a cygwin update; with Cygwin,
>> these problems often go
Hello,
Martin v. Löwis wrote:
> I think the obvious thing you missed is that the problem got fixed
> already. Whether the documentation system should be more defensive and
> work with 2.5.0 also is a different question.
You are right. python 2.5.1 corrected this.
May I still dare propose the foll
> However, I run into a problem while trying to build the new python docs.
> I initially used python2.5 on windows, but Linux seems to have the same
> problem.
> Am I really the only one who gets this error?
Not sure - but it works fine for me.
from __future__ import with_statement
imp
Hello,
The new documentation system is really a major improvement: congratulations!
However, I run into a problem while trying to build the new python docs.
I initially used python2.5 on windows, but Linux seems to have the same problem.
Am I really the only one who gets this error?
The offendin
> I view TLS as a wrapper around / layer on top of TCP, and so I think the
> API should look like, as well.
I think Martin raises a valid point here, which should at least be
discussed more thoroughly. Should there be an "SSL socket", which is
just like a regular socket? Does that really provide
On 8/20/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> I believe email addresses are automatically obfuscated as part of the
> HTML generation process, but one of the PEP editors can correct me if
> I am wrong.
Yes, email addresses are obfuscated in PEPs.
For example, in PEPs 0 & 12, my address is
On 8/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Ask the people involved if they're okay with "user at host dot com"
> obfuscation. That's used in a few places already (e.g. PEP 0).
>
I believe email addresses are automatically obfuscated as part of the
HTML generation process, but one of
IMHO this shouldn't segfault:
import thread
while 1:
f = open("/tmp/dupa", "w")
thread.start_new_thread(f.close, ())
f.close()
while it does on cpython 2.5.1, linux box.
May I consider this a bug?
___
Python-Dev mailing list
Python-Dev@pyt
Ask the people involved if they're okay with "user at host dot com"
obfuscation. That's used in a few places already (e.g. PEP 0).
On 8/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Is there a policy about putting email addresses in PEPs? I have the names
> and email addresses of a couple
> Yes, you're right. Of course, STARTTLS is properly regarded as a
> terrible hack :-).
I know you mean that jokingly - but I think it is considered as the
*proper* usage of TLS, with all these "let's use a different well-known
port for TLS over X" being those protocols that are hacks. I believe
> That's somewhat limiting - you should be able to do connection
> upgrades (e.g. SMTP STARTTLS, or HTTP Connection: Upgrade); with
> that design, such usages would not be possible, no?
Yes, you're right. Of course, STARTTLS is properly regarded as a
terrible hack :-).
The actual functionality e
> We add to the socket module a subtype of socket.socket,
> socket.SSLSocket. It has the following constructor:
>
> SSLSocket (family=AF_INET, type=SOCK_STREAM, proto=0,
>cert_filename=None, key_filename=None,
>cert_policy=CERT_NONE, ssl_protocol=PROTOCOL_SSLv23)
That's
All right, here's my current design :-).
We add to the socket module a subtype of socket.socket,
socket.SSLSocket. It has the following constructor:
SSLSocket (family=AF_INET, type=SOCK_STREAM, proto=0,
cert_filename=None, key_filename=None,
cert_policy=CERT_NONE, ssl
Is there a policy about putting email addresses in PEPs? I have the names
and email addresses of a couple platform maintainers to add to PEP 11.
Having the email addresses there would make it handy to contact said
maintainers, but I realize people don't always appreciate the extra exposure
to spam
Having squashed the final issues, we are now ready to switch over to
the new tracker! The plan is to do it on the 23rd. But before I
announce to the community I wanted to make sure there was not some
specific objection by python-dev or python-3000. If there is please
let me know by midday Monday
On Tue, Aug 14, 2007 at 09:58:32AM -0400, Barry Warsaw wrote:
> This was all fine except that some of the tests started
> failing because of the EOL translation that happens unconditionally
> now. The file contained \r\n and the test was ensuring these EOLs
> were preserved in the parsed te
22 matches
Mail list logo
