On 30 August 2016 at 15:13, Benjamin Peterson wrote:
> On Sun, Aug 28, 2016, at 22:42, Christian Heimes wrote:
>> In my proto-PEP I'm talking about different levels of support: full,
>> build-only and unsupported. Full support means that the combination of
>> Python and OpenSSL versions is reasona
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 versions older than 0.9.8
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 work?
> That seems very u
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 projects just dropping even no
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 mention it, and becau
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, especially for people dev
> 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 non-sequitur. You never
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 has deprecated 0.9.8 and 1.0.0 last
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 paths internally shou
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 native Windows
support, rather
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 know Nick and Victor like the idea of a -X flag (or
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 immutable and you're
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 ex
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
_hashopen
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 getfilesystemencoding() i
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 use-cases.
-Brett
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 line parameter parsi
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 29, 2016 at 3:28 PM,
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 wide-range
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 attach arbitrary data to
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,
well
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 and
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 523 proposed
> addin
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
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
>
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 wrote:
> ...
> I like to reduce
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 would
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
versions ASAP. O
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
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 1.0.0 last year. 1
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. OpenSSL has deprecated 0.9.8 and 1.0
> 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 end of this year,
>
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 w
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 slice object and a s
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
>>> 1.0.2 features for 3.7.
>>
>> What does "limit support" me
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 possible to build CPython
> 3.6 against OpenSS
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 new
>>> version of Python on an old LTS or Enterprise versio
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, please
>> contact your vendor and buy support.
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
> play with shiny new t
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 1.0
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,
>> https://ww
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 . Howeve
42 matches
Mail list logo
