Re: [Python-Dev] Python 2.6.3

[Zvezdan Petkovic]

On Sep 9, 2009, at 2:19 PM, Ronald Oussoren wrote:

MacOS X 10.6 support should be stable now, except for a critical issue
with IDLE: opening a new window hangs IDLE (issue 6864).

That said, I haven't scanned the issue tracker for more 10.6 related  
issues.


I just opened issue 6877 and provided a patch that I use for a long  
time already.  It would be nice to have it in the release though since  
other people could benefit from it too.


It resolves a BusError crash when Python readline module is built with  
a native Mac OS X editline (emulates readline).  The patch fixes the  
issue and enables use of readline module on Mac OS X.


Best regards,

Zvezdan

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] FWD: Front Runner Program

[Aahz]

I'm still no-mail on python-dev, forwarding as FYI

- Forwarded message from Eric Albrecht  -

From: Eric Albrecht 
To: "webmas...@python.org" 
Date: Thu, 10 Sep 2009 10:48:11 -0400
Subject: Front Runner Program 

Regarding: Windows 7 Compatibility for Python Application.

I am trying to contact your company regarding the Microsoft Windows 7 
Compatibility Program for the application above. I have not been able to get in 
touch with the person responsible for this application in your company and this 
is why I am reaching out to you through the Support Team. This application has 
been identified as one of the applications Microsoft would like to see 
supported on Windows 7 and I have been tasked by Microsoft to help answer your 
questions about Windows 7 application compatibility and help you get your 
application through the Windows 7 "Green Light" compatibility process.

If your application already supports Windows Vista, chances are it will already 
be compatible with Windows 7 without the need for any code changes.  By 
pledging support for Windows 7 you're application will automatically be listed 
in the Windows Application Compatibility seen currently by more than 1 million 
users per month. The registration is extremely simple and just asks a few key 
questions.

Here is the link to Microsoft's ISV Application Compatibility page: 
www.isvappcompat.com . When you have a moment, I 
would encourage you to visit the site and complete the process to pledge 
support for your application on Windows 7 by October 22nd 2009 when Windows 7 
is officially released.

In addition if you are able to pledge compatibility you'll receive access to a 
special Windows 7 Partner Marketing Kit that includes a press release with a 
Microsoft quote, plus customizable marketing templates including; email 
templates, postcards, web banners, business letter, and copy blocks, all to 
identify to your customers, or potential customers that your solutions are 
compatible with Windows 7.

If you provide me with a phone number where to get in touch with you, I will 
call you to answer any questions you may have.

Once you register on the ISV Application Compatibility site, I would appreciate 
it if email me to let me know that you have completed so that I can make a note 
of it for Microsoft. If you register the application under a different partner 
or application name please let me know in order to track changes. If there is a 
new version of the application and there are no plans to support Windows 7 on 
the older version please register the older version as "No planned Support" on 
the site as well as the new version with desired Win7 compatibility date.

Should you have any questions about this email feel free to call me or send an 
email to my supervisor at v-m...@microsoft.com.

Best regards,
Eric Albrecht
800-508-4291 EXT: 309
eric.albre...@nichecubed.com


- End forwarded message -

-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"To me vi is Zen.  To use vi is to practice zen.  Every command is a
koan.  Profound to the user, unintelligible to the uninitiated.  You
discover truth everytime you use it."  --re...@lion.austin.ibm.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FWD: Front Runner Program

[C. Titus Brown]

On Thu, Sep 10, 2009 at 08:11:55AM -0700, Aahz wrote:
-> I'm still no-mail on python-dev, forwarding as FYI
->
-> - Forwarded message from Eric Albrecht  
-
-> 
-> From: Eric Albrecht 
-> To: "webmas...@python.org" 
-> Date: Thu, 10 Sep 2009 10:48:11 -0400
-> Subject: Front Runner Program 
-> 
-> Regarding: Windows 7 Compatibility for Python Application.

Thanks, Aahz!

I don't see a Windows 7 buildbot up here:

http://www.python.org/dev/buildbot/all/

but I confess that I'm bad at reading these pages.  Has anyone tried
compiling either trunk or py3k on Win 7?  Would this be useful?

My recently acquired* MSDN account has led me to getting XP up and
running in a VM, and I would be happy to try other Windows OSes of
interest.

--titus

* acquired courtesy of Snakebite/Trent Nelson.
--
C. Titus Brown, c...@msu.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.3

[Ned Deily]

In article <9d506035-7c2d-4929-a134-e88eeb7b7...@python.org>,
 Barry Warsaw  wrote:

> On Sep 9, 2009, at 1:29 PM, Ned Deily wrote:
> 
> > In article <11a6545d-7204-4f61-b55b-1cc77cb56...@python.org>,
> > Barry Warsaw  wrote:
> >> I still want to release by the 25th, but I'd be willing to move the  
> >> rc
> >> to Monday the 21st.  We're really just trying to avoid a brown bag
> >> moment, so that should give us enough time to double check the  
> >> releases.
> >
> > The recent release of OS X 10.6 (Snow Leopard) has triggered a fair
> > amount of 2.6 bug tracker activity, since 10.6 now includes 2.6  
> > (2.6.1)
> > and a 64-bit version at that.   A number of patches have either just
> > been checked-in over the past couple of weeks or are getting some
> > exposure before check-in.  Given the timing and the (appropriate)
> > infrequency of 2.6.x releases, I think it would be unfortunate to push
> > 2.6.3 out the door without ensuring that it works well on 10.6.
> > Therefore, I propose that 2.6.3 should have 10.6 compatibility as a
> > "release goal".
> >
> > Without trying to put Ronald on the spot (too much!), it would be a  
> > good
> > idea to get his assessment where things stand wrt 2.6 on 10.6 before
> > setting a final release date.
> 
> I'm hoping that Python won't have any issues building and running on  
> 10.6, but I don't have it yet so I can't personally test it out.
> 
> How would you quantify "works well"?  Do you have any thoughts on  
> tests you'd run other than the standard test suite?  If 2.6.3 is shown  
> to pass its test suite on 10.5.x, is that good enough?  Are the  
> specific bug fixes necessary for 10.6?

Running the standard test suite on 10.6 and seeing no regressions 
compared to the same suite on 10.5.x seems a reasonable necessary 
requirement.  We have the resources to do that.  Beyond that, as Ronald 
suggests, I think it important to go through the open issues in the next 
couple of days and identify and flag any potential release-blockers 
(besides the IDLE problem already mentioned).

One other open issue is 64-bit support in the python.org OS X installer.  
There have been discussions and requests in the past and, with Apple 
providing 64-bit out of the box in 10.6, it seems like it's time to 
provide something on python.org as well.   One option: continue to 
provide a 32-bit only installer for ppc and i386 for 10.3.9 and beyond 
and add a second installer image with 3-way (ppc, i386, x86_64 but no 
ppc64) 32/64 for 10.5 and beyond.   Ronald, is that your current 
thinking?

-- 
 Ned Deily,
 n...@acm.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.3

[Martin v. Löwis]

Barry Warsaw schrieb:
> I had previously wanted to release Python 2.6.3 over the summer, but for
> various personal reasons, the summer was just too insane.  I'd like to
> reschedule a 2.6.3 release, shooting for final release on 25-September.

I'm travelling that week (as well as the time until then), so I would
prefer to make it a week later.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FWD: Front Runner Program

[Martin v. Löwis]

> My recently acquired* MSDN account has led me to getting XP up and
> running in a VM, and I would be happy to try other Windows OSes of
> interest.

Without checking the specific program, I think chances are that there
are higher requirements for being listed in some Microsoft list than
"it works", in particular wrt. the installation procedure.

Of course, testing that it works is a good idea independent of any logo
certification.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Controlling the cipher list for SSL connections

[Bill Janssen]

Thanks, Chris.  Can you explain why you want to set the cipher list
explicitly?  IMO, it's usually better to select a security scheme (TLS1,
or SSLv3, etc.), and let the implementation pick the cipher list.

Bill

Chris Frantz  wrote:

> Done.
> 
> Attached to Issue 3597, which is a similar request to mine.
> 
> Best Regards,
> --Chris
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/janssen%40parc.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Controlling the cipher list for SSL connections

[Bill Janssen]

Chris,

OK, seems reasonable.  Thanks.  In the near term, can you do this with
M2Crypto or PyOpenSSL?

When I started this update in 2007, we were trying to keep the API
simple to avoid confusing people and avoid competition with the two
full-fledged toolkits out there.  But I don't see any real reason not to
extend the API a bit.

Bill

Chris Frantz  wrote:

> Bill,
> 
> I agree that it's usually better to let the SSL implementation pick
> the ciphers.
> 
> I have a certain device that I'd like to talk to that is running on an
> underpowered embedded CPU.   When I let OpenSSL pick the ciphers, it
> chooses something like EDH-RSA-AES-SHA and takes about 3.5 seconds to
> finish  the handshake.  If I can restrict the cipher list to
> RSA-RC4-SHA I can reduce the handshake time to less than a second and
> improve the throughput of any bulk data transfer over the connection.
> 
> --Chris
> 
> 
> 
> On Thu, Sep 10, 2009 at 12:09 PM, Bill Janssen wrote:
> > Thanks, Chris.  Can you explain why you want to set the cipher list
> > explicitly?  IMO, it's usually better to select a security scheme (TLS1,
> > or SSLv3, etc.), and let the implementation pick the cipher list.
> >
> > Bill
> >
> > Chris Frantz  wrote:
> >
> >> Done.
> >>
> >> Attached to Issue 3597, which is a similar request to mine.
> >>
> >> Best Regards,
> >> --Chris
> >> ___
> >> Python-Dev mailing list
> >> Python-Dev@python.org
> >> http://mail.python.org/mailman/listinfo/python-dev
> >> Unsubscribe: 
> >> http://mail.python.org/mailman/options/python-dev/janssen%40parc.com
> >
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Controlling the cipher list for SSL connections

[Heikki Toivonen]

Bill Janssen wrote:
> OK, seems reasonable.  Thanks.  In the near term, can you do this with
> M2Crypto or PyOpenSSL?
> 
> When I started this update in 2007, we were trying to keep the API
> simple to avoid confusing people and avoid competition with the two
> full-fledged toolkits out there.  But I don't see any real reason not to
> extend the API a bit.

Speaking as the M2Crypto maintainer, I don't mind the stdlib competing
with M2Crypto/getting better at SSL. In fact, I would actually like to
see the stdlib SSL implementation getting good enough so that people
would not need M2Crypto for SSL (except maybe in special circumstances).
There is much M2Crypto does besides SSL so this wouldn't even obsolete it.

One of the main things IMO missing from stdlib SSL implementation is
hostname checking by default (with override option), but I know you and
I have different opinions on this. I would be happy to provide patches
against the stdlib SSL implementation for some things M2Crypto does that
the stdlib SSL module is missing if we could agree on the
features/design first. Simple is good, but I'd like the defaults to be
secure and commonly overridden things to be overrideable.

-- 
  Heikki Toivonen



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Controlling the cipher list for SSL connections

[Chris Frantz]

Bill,

For now, using pyOpenSSL is acceptable.  I just discovered that the
web.py framework wants pyOpenSSL.  Since my project is also using
web.py, I'll need pyOpenSSL anyway.

Thank you,
--Chris


On Thu, Sep 10, 2009 at 1:14 PM, Bill Janssen wrote:
> Chris,
>
> OK, seems reasonable.  Thanks.  In the near term, can you do this with
> M2Crypto or PyOpenSSL?
>
> When I started this update in 2007, we were trying to keep the API
> simple to avoid confusing people and avoid competition with the two
> full-fledged toolkits out there.  But I don't see any real reason not to
> extend the API a bit.
>
> Bill
>
> Chris Frantz  wrote:
>
>> Bill,
>>
>> I agree that it's usually better to let the SSL implementation pick
>> the ciphers.
>>
>> I have a certain device that I'd like to talk to that is running on an
>> underpowered embedded CPU.   When I let OpenSSL pick the ciphers, it
>> chooses something like EDH-RSA-AES-SHA and takes about 3.5 seconds to
>> finish  the handshake.  If I can restrict the cipher list to
>> RSA-RC4-SHA I can reduce the handshake time to less than a second and
>> improve the throughput of any bulk data transfer over the connection.
>>
>> --Chris
>>
>>
>>
>> On Thu, Sep 10, 2009 at 12:09 PM, Bill Janssen wrote:
>> > Thanks, Chris.  Can you explain why you want to set the cipher list
>> > explicitly?  IMO, it's usually better to select a security scheme (TLS1,
>> > or SSLv3, etc.), and let the implementation pick the cipher list.
>> >
>> > Bill
>> >
>> > Chris Frantz  wrote:
>> >
>> >> Done.
>> >>
>> >> Attached to Issue 3597, which is a similar request to mine.
>> >>
>> >> Best Regards,
>> >> --Chris
>> >> ___
>> >> Python-Dev mailing list
>> >> Python-Dev@python.org
>> >> http://mail.python.org/mailman/listinfo/python-dev
>> >> Unsubscribe: 
>> >> http://mail.python.org/mailman/options/python-dev/janssen%40parc.com
>> >
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Controlling the cipher list for SSL connections

[Chris Frantz]

Bill,

I agree that it's usually better to let the SSL implementation pick
the ciphers.

I have a certain device that I'd like to talk to that is running on an
underpowered embedded CPU.   When I let OpenSSL pick the ciphers, it
chooses something like EDH-RSA-AES-SHA and takes about 3.5 seconds to
finish  the handshake.  If I can restrict the cipher list to
RSA-RC4-SHA I can reduce the handshake time to less than a second and
improve the throughput of any bulk data transfer over the connection.

--Chris



On Thu, Sep 10, 2009 at 12:09 PM, Bill Janssen wrote:
> Thanks, Chris.  Can you explain why you want to set the cipher list
> explicitly?  IMO, it's usually better to select a security scheme (TLS1,
> or SSLv3, etc.), and let the implementation pick the cipher list.
>
> Bill
>
> Chris Frantz  wrote:
>
>> Done.
>>
>> Attached to Issue 3597, which is a similar request to mine.
>>
>> Best Regards,
>> --Chris
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/python-dev/janssen%40parc.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] evolving the SSL module API

[Bill Janssen]

Heikki, I'm OK with this, too.  would you like to propose an extended
API for the SSL module?  That would give us a starting point to talk
about.

This should probably be a PEP, just for the sake of writing things down.

As you say, the hostname checking feature seems to me possibly
appropriate for some application protocols, though it's made the use of
HTTPS as a transport-level protocol unnecessarily confusing and buggy.
I don't see putting that into the SSL module as a default, but perhaps a
utility function in that module, to check a server-side cert against a
hostname, is a good idea.

Bill


Heikki Toivonen  wrote:

> Bill Janssen wrote:
> > OK, seems reasonable.  Thanks.  In the near term, can you do this with
> > M2Crypto or PyOpenSSL?
> > 
> > When I started this update in 2007, we were trying to keep the API
> > simple to avoid confusing people and avoid competition with the two
> > full-fledged toolkits out there.  But I don't see any real reason not to
> > extend the API a bit.
> 
> Speaking as the M2Crypto maintainer, I don't mind the stdlib competing
> with M2Crypto/getting better at SSL. In fact, I would actually like to
> see the stdlib SSL implementation getting good enough so that people
> would not need M2Crypto for SSL (except maybe in special circumstances).
> There is much M2Crypto does besides SSL so this wouldn't even obsolete it.
> 
> One of the main things IMO missing from stdlib SSL implementation is
> hostname checking by default (with override option), but I know you and
> I have different opinions on this. I would be happy to provide patches
> against the stdlib SSL implementation for some things M2Crypto does that
> the stdlib SSL module is missing if we could agree on the
> features/design first. Simple is good, but I'd like the defaults to be
> secure and commonly overridden things to be overrideable.
> 
> -- 
>   Heikki Toivonen
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/janssen%40parc.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] evolving the SSL module API

[Jesse Noller]

There's also the patch to httplib that Devin Cook has been working on
for SSL enhancements, some of which do name checking. He's got most of
a patch completed.

On Thu, Sep 10, 2009 at 3:01 PM, Bill Janssen  wrote:
> Heikki, I'm OK with this, too.  would you like to propose an extended
> API for the SSL module?  That would give us a starting point to talk
> about.
>
> This should probably be a PEP, just for the sake of writing things down.
>
> As you say, the hostname checking feature seems to me possibly
> appropriate for some application protocols, though it's made the use of
> HTTPS as a transport-level protocol unnecessarily confusing and buggy.
> I don't see putting that into the SSL module as a default, but perhaps a
> utility function in that module, to check a server-side cert against a
> hostname, is a good idea.
>
> Bill
>
>
> Heikki Toivonen  wrote:
>
>> Bill Janssen wrote:
>> > OK, seems reasonable.  Thanks.  In the near term, can you do this with
>> > M2Crypto or PyOpenSSL?
>> >
>> > When I started this update in 2007, we were trying to keep the API
>> > simple to avoid confusing people and avoid competition with the two
>> > full-fledged toolkits out there.  But I don't see any real reason not to
>> > extend the API a bit.
>>
>> Speaking as the M2Crypto maintainer, I don't mind the stdlib competing
>> with M2Crypto/getting better at SSL. In fact, I would actually like to
>> see the stdlib SSL implementation getting good enough so that people
>> would not need M2Crypto for SSL (except maybe in special circumstances).
>> There is much M2Crypto does besides SSL so this wouldn't even obsolete it.
>>
>> One of the main things IMO missing from stdlib SSL implementation is
>> hostname checking by default (with override option), but I know you and
>> I have different opinions on this. I would be happy to provide patches
>> against the stdlib SSL implementation for some things M2Crypto does that
>> the stdlib SSL module is missing if we could agree on the
>> features/design first. Simple is good, but I'd like the defaults to be
>> secure and commonly overridden things to be overrideable.
>>
>> --
>>   Heikki Toivonen
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/python-dev/janssen%40parc.com
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.3

[Russell E. Owen]

In article ,
 Ronald Oussoren  wrote:

> On 9 Sep, 2009, at 19:29, Ned Deily wrote:
> >
> >
> > Without trying to put Ronald on the spot (too much!), it would be a  
> > good
> > idea to get his assessment where things stand wrt 2.6 on 10.6 before
> > setting a final release date.
> 
> MacOS X 10.6 support should be stable now, except for a critical issue
> with IDLE: opening a new window hangs IDLE (issue 6864).
> 
> That said, I haven't scanned the issue tracker for more 10.6 related  
> issues.
> 
> BTW. I'm fine with a sept. 25th release, that should give us enough time
> to shake out issues with OSX 10.6 support.
> 
> Ronald-

Some or all earlier Mac binaries of Python 2.6 were not compatible with 
3rd party Aqua Tcl/Tk (e.g. ActiveState's versions) -- at least on MacOS 
X 10.5. I hope that will be fixed with the current release.

-- Russell

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FWD: Front Runner Program

[Paul Moore]

2009/9/10 C. Titus Brown :
> I don't see a Windows 7 buildbot up here:
>
>        http://www.python.org/dev/buildbot/all/
>
> but I confess that I'm bad at reading these pages.  Has anyone tried
> compiling either trunk or py3k on Win 7?  Would this be useful?

I plan to do something like this but PC breakage has delayed this.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] evolving the SSL module API

[Devin Cook]

Yes, my patch implements hostname checking in httplib (although I
haven't had time to do much testing). I also made the documentation
changes, but have not yet created any test cases since there really
aren't any HTTPS test cases in the test_httplib.py file (which is
probably another issue that needs attention).

We had talked a month or two back about including hostname checking in
the ssl module, but the consensus seemed to be that it doesn't belong
there.

Personally, I would like to see it make it into the ssl module, as
that would mean all the modules that use the ssl module (httplib,
etc.) wouldn't have to write their own (and it isn't very
straightforward... lots of different RFCs involved). Just my 2 cents.

-Devin

On Thu, Sep 10, 2009 at 3:17 PM, Jesse Noller  wrote:
> There's also the patch to httplib that Devin Cook has been working on
> for SSL enhancements, some of which do name checking. He's got most of
> a patch completed.
>
> On Thu, Sep 10, 2009 at 3:01 PM, Bill Janssen  wrote:
>> Heikki, I'm OK with this, too.  would you like to propose an extended
>> API for the SSL module?  That would give us a starting point to talk
>> about.
>>
>> This should probably be a PEP, just for the sake of writing things down.
>>
>> As you say, the hostname checking feature seems to me possibly
>> appropriate for some application protocols, though it's made the use of
>> HTTPS as a transport-level protocol unnecessarily confusing and buggy.
>> I don't see putting that into the SSL module as a default, but perhaps a
>> utility function in that module, to check a server-side cert against a
>> hostname, is a good idea.
>>
>> Bill
>>
>>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pthreads, fork, import, and execvp

[Cameron Simpson]

On 25Jul2009 10:25, Gregory P. Smith  wrote:
| On Thu, Jul 23, 2009 at 4:28 PM, Thomas Wouters wrote:
| > So attached (and at http://codereview.appspot.com/96125/show ) is a
| > preliminary fix, correcting the problem with os.fork(), os.forkpty() and
| > os.fork1(). This doesn't expose a general API for C code to use, for two
| > reasons: it's not easy, and I need this fix more than I need the API change
| > :-) (I actually need this fix myself for Python 2.4, but it applies fairly
| > cleanly.)
| 
| This looks good to me.
[...]

Where's this stand with respect to the upcoming Python 2.6.3?
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

Life is pleasant. Death is peaceful. It's the transition that's troublesome.
- Isaac Asimov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com