Re: [Python-Dev] Supported versions of OpenSSL

On 2016-08-29 21:31, M.-A. Lemburg wrote: > On 29.08.2016 18:33, Cory Benfield wrote: >> >>> On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: >>> >>> On 28.08.2016 22:40, Christian Heimes wrote: ... I like to reduce the maintenance burden and list of supported OpenSSL

Re: [Python-Dev] Supported versions of OpenSSL

On 2016-08-29 22:10, Random832 wrote: > On Mon, Aug 29, 2016, at 04:09, M.-A. Lemburg wrote: >> Hmm, that last part would mean that Python 3.7 will no longer compile >> on e.g. Ubuntu 14.04 LTS which uses OpenSSL 1.0.1 as default version. >> Since 14.04 LTS is supported until 2019, I think it

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, 29 Aug 2016 at 09:34 Cory Benfield wrote: > > > On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: > > > > On 28.08.2016 22:40, Christian Heimes wrote: > >> ... > >> I like to reduce the maintenance burden and list of supported OpenSSL > >> versions ASAP.

Re: [Python-Dev] Supported versions of OpenSSL

On 29.08.2016 18:33, Cory Benfield wrote: > >> On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: >> >> On 28.08.2016 22:40, Christian Heimes wrote: >>> ... >>> I like to reduce the maintenance burden and list of supported OpenSSL >>> versions ASAP. OpenSSL has deprecated 0.9.8 and

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, Aug 29, 2016, at 04:09, M.-A. Lemburg wrote: > Hmm, that last part would mean that Python 3.7 will no longer compile > on e.g. Ubuntu 14.04 LTS which uses OpenSSL 1.0.1 as default version. > Since 14.04 LTS is supported until 2019, I think it would be better > to only start requiring 1.0.2

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

Anyway, given the outcome of Dino's tests I have no objections to the PEP. (Though using Christian's hack would be cool.) On Mon, Aug 29, 2016 at 3:28 PM, Christian Heimes wrote: > On 2016-08-29 23:38, Brett Cannon wrote: >> That means we still want to find a solution to

Re: [Python-Dev] Supported versions of OpenSSL

On Aug 29, 2016, at 12:33 PM, Cory Benfield wrote: >Can someone explain to me why this is a use-case we care about? I do think it would be nice to be able to compile newer versions of Python on stock LTS releases, especially for people developing software that they want to support on a

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Mon, 29 Aug 2016 at 15:51 Guido van Rossum wrote: > Anyway, given the outcome of Dino's tests I have no objections to the > PEP. (Though using Christian's hack would be cool.) > Great! I'll mark the PEP as accepted and get the implementation in for 3.6. > > On Mon, Aug

Re: [Python-Dev] File system path encoding on Windows

2016-08-20 21:31 GMT+02:00 Nick Coghlan : > Reading your summary meant this finally clicked with something Victor > has been considering for a while: a "Force UTF-8" switch that told > Python to ignore the locale encoding on Linux, and instead assume > UTF-8 everywhere (command

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Mon, 29 Aug 2016 at 15:12 Maciej Fijalkowski wrote: > Hi Brett > > For what is worth, vmprof and similar tools would love such field > (there is an open question how can you use vmprof *and* another tool, > but later) > That's great to hear! Glad the solution has multiple

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, Aug 29, 2016 at 1:18 PM Christian Heimes wrote: > On 2016-08-29 21:31, M.-A. Lemburg wrote: > > On 29.08.2016 18:33, Cory Benfield wrote: > >> > >>> On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: > >>> > >>> On 28.08.2016 22:40, Christian Heimes

Re: [Python-Dev] Supported versions of OpenSSL

On 2016-08-29 23:00, Gregory P. Smith wrote: > > Given that you already said: > > """ > For 3.6 I don't require any 1.0.2 feature yet. The 1.1.0 patch keeps > code compatible with 0.9.8zc to 1.1.0. But as soon as I use new > features, the ssl module will no longer be source and build compatible

[Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

For quick background for those that don't remember, part of PEP 523 proposed adding a co_extra field to code objects along with making the frame evaluation function pluggable ( https://www.python.org/dev/peps/pep-0523/#expanding-pycodeobject). The idea was that things like JITs and debuggers could

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

Hi Brett For what is worth, vmprof and similar tools would love such field (there is an open question how can you use vmprof *and* another tool, but later) On Mon, Aug 29, 2016 at 11:38 PM, Brett Cannon wrote: > For quick background for those that don't remember, part of PEP

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On 2016-08-29 23:38, Brett Cannon wrote: > That means we still want to find a solution to attach arbitrary data to > code objects without sacrificing performance. One proposal is what's in > PEP 523 for the extra field. Another option is to make the memory > allocator for code objects pluggable

Re: [Python-Dev] File system path encoding on Windows

Hi, tl; dr: just drop byte support and help developers to use Unicode in their application! As you may already know, I dislike your whole project. But first of all, IMHO you should open a separated thread to discuss changes related to the Windows console. I consider that they are unrelated,

Re: [Python-Dev] File system path encoding on Windows

2016-08-24 17:44 GMT+02:00 Steve Dower : > I know Nick and Victor like the idea of a -X flag (or a direct -utf8 flag), > but I prefer more specific environment variables: > > - PYTHONWINDOWSLEGACYSTDIO (for the console changes) > - PYTHONWINDOWSLEGACYPATHENCODING (assuming

Re: [Python-Dev] Supported versions of OpenSSL

On 8/29/2016 5:20 PM, Christian Heimes wrote: On 2016-08-29 23:00, Gregory P. Smith wrote: Lets make 3.7 require a higher version. The common OSS OS distros of its time will be better prepared. Especially is warned. My multissl test script allows me to compile and test _ssl.c and

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On 8/29/2016 5:38 PM, Brett Cannon wrote: who objected to the new field did either for memory ("it adds another pointer to the struct that won't be typically used"), or for conceptual reasons ("the code object is immutable and you're proposing a mutable field"). The latter is addressed by not

Re: [Python-Dev] File system path encoding on Windows

On 30 August 2016 at 11:10, Daniel Holth wrote: > A nice recent blog post about paths encoding in a media player. > http://beets.io/blog/paths.html . It's not merely the porting that makes it > hard. Interestingly, with Steve's proposed changes, their approach of using bytes

Re: [Python-Dev] File system path encoding on Windows

On 30 August 2016 at 13:29, Steve Dower wrote: > The other discussion about OpenSSL and LTS systems is also interesting. Do > we really expect users to take their fully functioning systems and blindly > upgrade to a new major version of Python expecting everything to just

Re: [Python-Dev] Supported versions of OpenSSL

On 30 August 2016 at 08:56, Barry Warsaw wrote: > On Aug 29, 2016, at 12:33 PM, Cory Benfield wrote: > >>Can someone explain to me why this is a use-case we care about? > > I do think it would be nice to be able to compile newer versions of Python on > stock LTS releases,

Re: [Python-Dev] Supported versions of OpenSSL

> On 29 Aug 2016, at 15:31, M.-A. Lemburg wrote: > > Ubuntu 14.04 is a widely deployed system and newer Python version > should run on such widely deployed systems without having to > replace important vendor maintained system libraries such as > OpenSSL. That's quite the

Re: [Python-Dev] File system path encoding on Windows

On 29Aug2016 1810, Nick Coghlan wrote: On 30 August 2016 at 08:38, Victor Stinner wrote: Hi, tl; dr: just drop byte support and help developers to use Unicode in their application! My view (and Steve's) is that this approach is likely to result in Linux-centric

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Mon, Aug 29, 2016, 17:06 Terry Reedy wrote: > On 8/29/2016 5:38 PM, Brett Cannon wrote: > > > who objected to the new field did either for memory ("it adds another > > pointer to the struct that won't be typically used"), or for conceptual > > reasons ("the code object is

Re: [Python-Dev] File system path encoding on Windows

On 30 August 2016 at 08:38, Victor Stinner wrote: > Hi, > > tl; dr: just drop byte support and help developers to use Unicode in > their application! My view (and Steve's) is that this approach is likely to result in Linux-centric projects just dropping even nominal

Re: [Python-Dev] Supported versions of OpenSSL

On Sun, Aug 28, 2016, at 22:42, Christian Heimes wrote: > On 2016-08-29 04:38, Ned Deily wrote: > > On Aug 28, 2016, at 19:06, Benjamin Peterson wrote: > >> On Sun, Aug 28, 2016, at 13:40, Christian Heimes wrote: > >>> Here is the deal for 2.7 to 3.5: > >>> > >>> 1) All

Re: [Python-Dev] Supported versions of OpenSSL

On Aug 29, 2016, at 22:59, Nick Coghlan wrote: > The other thing I've been looking at is how well documented the > process is for building with a custom OpenSSL instead of the system > one, and as near as I can tell, it isn't documented at all - the top > level README doesn't

Re: [Python-Dev] File system path encoding on Windows

A nice recent blog post about paths encoding in a media player. http://beets.io/blog/paths.html . It's not merely the porting that makes it hard. On Mon, Aug 29, 2016, 19:32 Victor Stinner wrote: > 2016-08-24 17:44 GMT+02:00 Steve Dower : > > I

Re: [Python-Dev] Supported versions of OpenSSL

On 30 August 2016 at 02:33, Cory Benfield wrote: > >> On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: >> >> On 28.08.2016 22:40, Christian Heimes wrote: >>> ... >>> I like to reduce the maintenance burden and list of supported OpenSSL >>> versions ASAP. OpenSSL

Re: [Python-Dev] Supported versions of OpenSSL

On 2016-08-29 10:09, M.-A. Lemburg wrote: > On 28.08.2016 22:40, Christian Heimes wrote: >> ... >> I like to reduce the maintenance burden and list of supported OpenSSL >> versions ASAP. OpenSSL has deprecated 0.9.8 and 1.0.0 last year. 1.0.1 >> will reach EOL by the end of this year, >>

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, Aug 29, 2016 at 10:24:42AM +0200, Christian Heimes wrote: > On 2016-08-29 10:09, M.-A. Lemburg wrote: > > On 28.08.2016 22:40, Christian Heimes wrote: > >> ... > >> I like to reduce the maintenance burden and list of supported OpenSSL > >> versions ASAP. OpenSSL has deprecated 0.9.8 and

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, Aug 29, 2016 at 6:24 PM, Christian Heimes wrote: > No, LTS support should not be our concern. If you need a brand new > version of Python on an old LTS or Enterprise version of your OS, please > contact your vendor and buy support. You don't get to run old metal and

Re: [Python-Dev] Supported versions of OpenSSL

On 28.08.2016 22:40, Christian Heimes wrote: > ... > I like to reduce the maintenance burden and list of supported OpenSSL > versions ASAP. OpenSSL has deprecated 0.9.8 and 1.0.0 last year. 1.0.1 > will reach EOL by the end of this year, > https://www.openssl.org/policies/releasestrat.html .

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, Aug 29, 2016 at 8:52 PM, Nick Coghlan wrote: > On 29 August 2016 at 19:14, Chris Angelico wrote: >> On Mon, Aug 29, 2016 at 6:24 PM, Christian Heimes >> wrote: >>> No, LTS support should not be our concern. If you need a brand

Re: [Python-Dev] Supported versions of OpenSSL

On 29 August 2016 at 19:14, Chris Angelico wrote: > On Mon, Aug 29, 2016 at 6:24 PM, Christian Heimes > wrote: >> No, LTS support should not be our concern. If you need a brand new >> version of Python on an old LTS or Enterprise version of your OS,

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, Aug 29, 2016 at 9:16 PM, Nick Coghlan wrote: > On 29 August 2016 at 21:05, Chris Angelico wrote: >> On Mon, Aug 29, 2016 at 8:52 PM, Nick Coghlan wrote: >>> For upcoming 3.6 I would like to limit support to 1.0.2+ and require >>>

Re: [Python-Dev] Supported versions of OpenSSL

On 29 August 2016 at 21:05, Chris Angelico wrote: > On Mon, Aug 29, 2016 at 8:52 PM, Nick Coghlan wrote: >> For upcoming 3.6 I would like to limit support to 1.0.2+ and require >> 1.0.2 features for 3.7. > > What does "limit support" mean? Will it be

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On 08/28/2016 09:26 AM, Nick Coghlan wrote: On 28 August 2016 at 08:25, Terry Reedy wrote: Slicing can be made to malfunction and even crash with an 'evil' __index__ method. https://bugs.python.org/issue27867 The crux of the problem is this: PySlice_GetIndicesEx receives a

Re: [Python-Dev] Supported versions of OpenSSL

> On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: > > On 28.08.2016 22:40, Christian Heimes wrote: >> ... >> I like to reduce the maintenance burden and list of supported OpenSSL >> versions ASAP. OpenSSL has deprecated 0.9.8 and 1.0.0 last year. 1.0.1 >> will reach EOL by the

Re: [Python-Dev] File system path encoding on Windows

On 28Aug2016 2043, Stephen J. Turnbull wrote: tritium-l...@sdamon.com writes: > Once you get to var lengths like that, arcane single character flags start > looking preferable. How about "PYTHONWINLEGACY" to just turn it all on or > off. If the code breaks on one thing, it obviously isn't