Re: [Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

[Nathaniel Smith]

On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner
 wrote:
> CPython still has compatibility code for Linux 2.6, whereas the
> support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
> Should we also drop support for old Linux kernels? If yes, which ones?
> The Linux kernel has LTS version, the oldest is Linux 3.2 (support
> will end in May, 2018).
>
> Linux kernel support:
>
>   https://www.kernel.org/category/releases.html

RHEL 5 uses 2.6.28, and still has "extended life cycle support" until
2020, but I guess no-one should be running Python 3.7 on that. CentOS
6 and RHEL 6 use 2.6.32, and their EOL is also 2020 (or 2024 for RHEL
6 with extended life cycle support). Redhat does ship and support 3.6
on CentOS/RHEL 6 through their "software collections" product, and
presumably is planning to do the same for 3.7.

It is a little surprising to see a Redhat employee suggest dropping
support for RHEL 6. Hopefully you know what you're doing :-)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

[Benjamin Peterson]

+1 to both of your specific proposals.

More generally, I think it makes good sense to allow dropping support for a 
platform in the next major Python release after vendor support for the platform 
stops. Even we say we support something, it will break quickly without buildbot 
validation.

On Thu, Jan 18, 2018, at 12:27, Victor Stinner wrote:
> Hi,
> 
> I'm working on a exhaustive list of platforms supported by Python:
> 
>   http://vstinner.readthedocs.io/cpython.html#supported-platforms
> 
> 
> I noticed that the extended support phase of Windows Vista is expired,
> so I proposed to drop Vista support:
> 
>   "Drop support of Windows Vista in Python 3.7"
>   https://bugs.python.org/issue32592
>   https://github.com/python/cpython/pull/5231
> 
> Python has an explicit policy for Windows support, extract of the PEP 11:
> 
> "CPython’s Windows support now follows [Microsoft product support
> lifecycle]. A new feature release X.Y.0 will support all Windows
> releases whose extended support phase is not yet expired. Subsequent
> bug fix releases will support the same Windows releases as the
> original feature release (even if the extended support phase has
> ended)."
> 
> 
> For Linux and FreeBSD, we have no explicit rule. CPython code base
> still contains code for FreeBSD 4... but FreeBSD 4 support ended
> longer than 10 years ago (January 31, 2007). Maybe it's time to drop
> support of these old platforms to cleanup the CPython code base to
> ease its maintainance.
> 
> I proposed: "Drop FreeBSD 9 and older support:"
> 
>   https://bugs.python.org/issue32593
>   https://github.com/python/cpython/pull/5232
> 
> FreeBSD 9 supported ended 1 year ago (December 2016).
> 
> FreeBSD support:
> 
>   https://www.freebsd.org/security/
>   https://www.freebsd.org/security/unsupported.html
> 
> 
> CPython still has compatibility code for Linux 2.6, whereas the
> support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
> Should we also drop support for old Linux kernels? If yes, which ones?
> The Linux kernel has LTS version, the oldest is Linux 3.2 (support
> will end in May, 2018).
> 
> Linux kernel support:
> 
>   https://www.kernel.org/category/releases.html
> 
> 
> Note: I'm only talking about changing the future Python 3.7. We should
> have the same support policy than for Windows. If Python 3.x.0
> supports a platform, this support should be kept in the whole lifetime
> of the 3.x cycle (until it's end-of-line).
> 
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LibreSSL support

[Nathaniel Smith]

On Jan 18, 2018 07:34, "Christian Heimes"  wrote:

On 2018-01-16 21:17, Christian Heimes wrote:
> FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I have
> created a daily cronjob to populate Travis' cache with OpenSSL builds.
> Until the cache is filled, Linux CI will take an extra 5 minute.

I have messed up my initial research. :( When I was checking LibreSSL
and OpenSSL for features, I draw a wrong conclusion. LibreSSL is *not*
OpenSSL 1.0.2 compatible. It only implements some of the required
features from 1.0.2 (e.g. X509_check_hostname) but not
X509_VERIFY_PARAM_set1_host.

X509_VERIFY_PARAM_set1_host() is required to perform hostname
verification during the TLS handshake. Without the function, I'm unable
to fix Python's hostname matching code [1]. LibreSSL upstream knows
about the issue since 2016 [2]. I have opened another bug report [3].

We have two options until LibreSSL has addressed the issue:

1) Make the SSL module more secure, simpler and standard conform
2) Support LibreSSL


There are tons of different SSL libraries out there that we could
theoretically support, but don't. IIUC, the reasons we started supporting
LibreSSL in the first place were:

- it claimed to be OpenSSL compatible, so supporting it is supposed to be
"free"

- when it started (just after heartbleed), there was a lot of uncertainty
about whether OpenSSL would remain a viable option, and LibreSSL looked
like it might become the new de facto standard.

Now it's a few years later, and things have turned out differently: they
aren't compatible in practice, and OpenSSL has turned things around so that
it's clearly ahead of LibreSSL technically (cleaner API, new features like
TLS 1.3, ...), and in terms of developer momentum.

We have *very* few people qualified to maintain the ssl module, so given
the new landscape I think we should focus on keeping our core OpenSSL
support solid and not worry about LibreSSL. If LibreSSL wants to be
supported as well then – like any other 2nd tier platform – they need to
find someone to do the work. And if people are worried about supporting
more diversity in SSL implementations, then PEP 543 is probably the thing
to focus on.

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

Re: [Python-Dev] LibreSSL support

[Christian Heimes]

On 2018-01-18 21:49, Chris Jerdonek wrote:
> 
> On Thu, Jan 18, 2018 at 7:34 AM Christian Heimes  > wrote:
> 
> On 2018-01-16 21:17, Christian Heimes wrote:
> We have two options until LibreSSL has addressed the issue:
> 
> 1) Make the SSL module more secure, simpler and standard conform
> 2) Support LibreSSL
> 
> I started a vote on Twitter [4]. So far most people prefer security.
> 
> 
> It’s not exactly the most balanced (neutral) presentation of a ballot
> question though. :)

It's more venting than voting :)

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

Re: [Python-Dev] LibreSSL support

[Chris Jerdonek]

On Thu, Jan 18, 2018 at 7:34 AM Christian Heimes 
wrote:

> On 2018-01-16 21:17, Christian Heimes wrote:
> We have two options until LibreSSL has addressed the issue:
>
> 1) Make the SSL module more secure, simpler and standard conform
> 2) Support LibreSSL
>
> I started a vote on Twitter [4]. So far most people prefer security.


It’s not exactly the most balanced (neutral) presentation of a ballot
question though. :)

—Chris


>
> Christian
>
> [1] https://bugs.python.org/issue31399
> [2] https://github.com/pyca/cryptography/issues/3247
> [3] https://github.com/libressl-portable/portable/issues/381
> [4] https://twitter.com/reaperhulk/status/953991843565490176
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

[Victor Stinner]

Hi,

I'm working on a exhaustive list of platforms supported by Python:

  http://vstinner.readthedocs.io/cpython.html#supported-platforms


I noticed that the extended support phase of Windows Vista is expired,
so I proposed to drop Vista support:

  "Drop support of Windows Vista in Python 3.7"
  https://bugs.python.org/issue32592
  https://github.com/python/cpython/pull/5231

Python has an explicit policy for Windows support, extract of the PEP 11:

"CPython’s Windows support now follows [Microsoft product support
lifecycle]. A new feature release X.Y.0 will support all Windows
releases whose extended support phase is not yet expired. Subsequent
bug fix releases will support the same Windows releases as the
original feature release (even if the extended support phase has
ended)."


For Linux and FreeBSD, we have no explicit rule. CPython code base
still contains code for FreeBSD 4... but FreeBSD 4 support ended
longer than 10 years ago (January 31, 2007). Maybe it's time to drop
support of these old platforms to cleanup the CPython code base to
ease its maintainance.

I proposed: "Drop FreeBSD 9 and older support:"

  https://bugs.python.org/issue32593
  https://github.com/python/cpython/pull/5232

FreeBSD 9 supported ended 1 year ago (December 2016).

FreeBSD support:

  https://www.freebsd.org/security/
  https://www.freebsd.org/security/unsupported.html


CPython still has compatibility code for Linux 2.6, whereas the
support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
Should we also drop support for old Linux kernels? If yes, which ones?
The Linux kernel has LTS version, the oldest is Linux 3.2 (support
will end in May, 2018).

Linux kernel support:

  https://www.kernel.org/category/releases.html


Note: I'm only talking about changing the future Python 3.7. We should
have the same support policy than for Windows. If Python 3.x.0
supports a platform, this support should be kept in the whole lifetime
of the 3.x cycle (until it's end-of-line).

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

Re: [Python-Dev] LibreSSL support

[Christian Heimes]

On 2018-01-18 20:54, Wes Turner wrote:
> LibreSSL is not a pressing need for me; but fallback to the existing
> insecure check if LibreSSL is present shouldn't be too difficult?

Please give it a try and report back. Patches welcome :)

Christian

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

Re: [Python-Dev] LibreSSL support

[Wes Turner]

LibreSSL is not a pressing need for me; but fallback to the existing
insecure check if LibreSSL is present shouldn't be too difficult?

On Thursday, January 18, 2018, Christian Heimes 
wrote:

> On 2018-01-18 19:42, Wes Turner wrote:
> > Is there a build flag or a ./configure-time autodetection that would
> > allow for supporting LibreSSL while they port
> X509_VERIFY_PARAM_set1_host?
>
> X509_VERIFY_PARAM_set1_host() is a fundamental and essential piece in
> the new hostname verification code. I cannot replace
> ssl.match_hostname() easily without the API. There might be a way to add
> a callback, but it would take a couple of days of R to implement it.
> It won't be finished for beta1 feature freeze.
>
> Christian
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LibreSSL support

[Christian Heimes]

On 2018-01-18 19:42, Wes Turner wrote:
> Is there a build flag or a ./configure-time autodetection that would
> allow for supporting LibreSSL while they port X509_VERIFY_PARAM_set1_host?

X509_VERIFY_PARAM_set1_host() is a fundamental and essential piece in
the new hostname verification code. I cannot replace
ssl.match_hostname() easily without the API. There might be a way to add
a callback, but it would take a couple of days of R to implement it.
It won't be finished for beta1 feature freeze.

Christian

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

Re: [Python-Dev] LibreSSL support

[Wes Turner]

Is there a build flag or a ./configure-time autodetection that would allow
for supporting LibreSSL while they port X509_VERIFY_PARAM_set1_host?

On Thursday, January 18, 2018, Christian Heimes 
wrote:

> On 2018-01-16 21:17, Christian Heimes wrote:
> > FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I have
> > created a daily cronjob to populate Travis' cache with OpenSSL builds.
> > Until the cache is filled, Linux CI will take an extra 5 minute.
>
> I have messed up my initial research. :( When I was checking LibreSSL
> and OpenSSL for features, I draw a wrong conclusion. LibreSSL is *not*
> OpenSSL 1.0.2 compatible. It only implements some of the required
> features from 1.0.2 (e.g. X509_check_hostname) but not
> X509_VERIFY_PARAM_set1_host.
>
> X509_VERIFY_PARAM_set1_host() is required to perform hostname
> verification during the TLS handshake. Without the function, I'm unable
> to fix Python's hostname matching code [1]. LibreSSL upstream knows
> about the issue since 2016 [2]. I have opened another bug report [3].
>
> We have two options until LibreSSL has addressed the issue:
>
> 1) Make the SSL module more secure, simpler and standard conform
> 2) Support LibreSSL
>
> I started a vote on Twitter [4]. So far most people prefer security.
>
> Christian
>
> [1] https://bugs.python.org/issue31399
> [2] https://github.com/pyca/cryptography/issues/3247
> [3] https://github.com/libressl-portable/portable/issues/381
> [4] https://twitter.com/reaperhulk/status/953991843565490176
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] LibreSSL support

[Christian Heimes]

On 2018-01-16 21:17, Christian Heimes wrote:
> FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I have
> created a daily cronjob to populate Travis' cache with OpenSSL builds.
> Until the cache is filled, Linux CI will take an extra 5 minute.

I have messed up my initial research. :( When I was checking LibreSSL
and OpenSSL for features, I draw a wrong conclusion. LibreSSL is *not*
OpenSSL 1.0.2 compatible. It only implements some of the required
features from 1.0.2 (e.g. X509_check_hostname) but not
X509_VERIFY_PARAM_set1_host.

X509_VERIFY_PARAM_set1_host() is required to perform hostname
verification during the TLS handshake. Without the function, I'm unable
to fix Python's hostname matching code [1]. LibreSSL upstream knows
about the issue since 2016 [2]. I have opened another bug report [3].

We have two options until LibreSSL has addressed the issue:

1) Make the SSL module more secure, simpler and standard conform
2) Support LibreSSL

I started a vote on Twitter [4]. So far most people prefer security.

Christian

[1] https://bugs.python.org/issue31399
[2] https://github.com/pyca/cryptography/issues/3247
[3] https://github.com/libressl-portable/portable/issues/381
[4] https://twitter.com/reaperhulk/status/953991843565490176

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

Re: [Python-Dev] Positional-only parameters in Python

[Nick Coghlan]

On 18 January 2018 at 19:26, Larry Hastings  wrote:
> Would we be adding yet a third argument-parsing function,
> PyArg_ParseTupleAndKeywordsWithPositionalOnly()?

Checking the docs, it turns out PyArg_ParseTupleAndKeywords already
gained positional-only argument support in 3.6 by way of empty strings
in the keyword array.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Positional-only parameters in Python

[Victor Stinner]

2018-01-18 10:26 GMT+01:00 Larry Hastings :
> Why did Argument Clinic choose that syntax?  It was suggested by one Guido
> van Rossum in March 2012: (...)
> I'm not wading into the debate over what syntax Python should use if it adds
> positional-only parameters, except to say that I think "/" is reasonable.
> If Python winds up using a different syntax, I'd look into modifying
> Argument Clinic so that it accepts both this hypothetical new syntax and the
> existing syntax using "/".

The "/" syntax is used since Python 3.5, at least in some function docstrings:
---
$ python3.5
Python 3.5.4+ (heads/3.5:fd8614c5c5, Dec 18 2017, 12:53:10)
>>> help(abs)
Help on built-in function abs in module builtins:

abs(x, /)
Return the absolute value of the argument.
---

inspect.signature() is able to parse this syntax, but currently, it is
only used to parse __text_signature__ attribute of builtin functions.

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

Re: [Python-Dev] Positional-only parameters in Python

[Larry Hastings]

On 01/17/2018 08:29 AM, Ethan Furman wrote:

On 01/17/2018 08:14 AM, Serhiy Storchaka wrote:

17.01.18 16:34, Victor Stinner пише:

In Februrary 2017, I proposed on python-ideas to change the Python
syntax to allow to declare positional-only parameters in Python:

https://mail.python.org/pipermail/python-ideas/2017-February/044879.html 


https://mail.python.org/pipermail/python-ideas/2017-March/044956.html


The main problem -- designing a syntax that does not look ugly.


The syntax question is already solved:

   def some_func(a, b, /, this, that, *, the_other):
   # some stuff

Everything before the slash is positional-only, between the slash and 
star is positional-or-keyword, and after the star is keyword-only.  
This is what is in our generated help(), and there is a nice symmetry 
between '/' and '*' being opposites, and positional/keyword being 
opposites.  And slash is certainly no uglier than star.  ;)


To clarify: this is the syntax used by "Argument Clinic", both as its 
input language, and as part of its output, exposed via the 
__text_signature__ attribute on builtins.


Why did Argument Clinic choose that syntax?  It was suggested by one 
Guido van Rossum in March 2012:


   https://mail.python.org/pipermail/python-ideas/2012-March/014364.html
   https://mail.python.org/pipermail/python-ideas/2012-March/014378.html
   https://mail.python.org/pipermail/python-ideas/2012-March/014417.html


I'm not wading into the debate over what syntax Python should use if it 
adds positional-only parameters, except to say that I think "/" is 
reasonable.  If Python winds up using a different syntax, I'd look into 
modifying Argument Clinic so that it accepts both this hypothetical new 
syntax and the existing syntax using "/".




Would we be adding yet a third argument-parsing function, 
PyArg_ParseTupleAndKeywordsWithPositionalOnly()?  I would actually 
propose a different approach: modify Argument Clinic so it generates 
custom argument-parsing code for each function, adding a new call type 
(which I propose calling "METH_RAW" or "METH_STACK") where the stack is 
passed in directly.  I spent some time on this in the past, though I got 
distracted and now haven't touched it in years.




Cheers,


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

Re: [Python-Dev] PEP 567 v3

[Nathaniel Smith]

On Thu, Jan 18, 2018 at 12:03 AM, Antoine Pitrou  wrote:
> On Wed, 17 Jan 2018 20:53:42 -0500
> Yury Selivanov  wrote:
>>
>> Proposed by Antoine Pitrou, this could enable transparent
>> cross-process use of ``Context`` objects, so the
>> `Offloading execution to other threads`_ example would work with
>> a ``ProcessPoolExecutor`` too.
>>
>> Enabling this is problematic because of the following reasons:
>>
>> 1. ``ContextVar`` objects do not have ``__module__`` and
>>``__qualname__`` attributes, making straightforward pickling
>>of ``Context`` objects impossible.  This is solvable by modifying
>>the API to either auto detect the module where a context variable
>>is defined, or by adding a new keyword-only "module" parameter
>>to ``ContextVar`` constructor.
>>
>> 2. Not all context variables refer to picklable objects.  Making a
>>``ContextVar`` picklable must be an opt-in.
>
> This is a red herring.  If a value isn't picklable, pickle will simply
> raise as it does in other contexts.  You should't need to opt in for
> anything here.

The complication is that Contexts collect ContextVars from all over
the process. So if people are going to pickle Contexts, we need some
mechanism to make sure that we don't end up in a situation where it
seems to work and users depend on it, and then they import a new
library and suddenly pickling raises an error (because the new library
internally uses a ContextVar that happens not to be pickleable).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 567 v3

[Antoine Pitrou]

On Wed, 17 Jan 2018 20:53:42 -0500
Yury Selivanov  wrote:
> 
> Proposed by Antoine Pitrou, this could enable transparent
> cross-process use of ``Context`` objects, so the
> `Offloading execution to other threads`_ example would work with
> a ``ProcessPoolExecutor`` too.
> 
> Enabling this is problematic because of the following reasons:
> 
> 1. ``ContextVar`` objects do not have ``__module__`` and
>``__qualname__`` attributes, making straightforward pickling
>of ``Context`` objects impossible.  This is solvable by modifying
>the API to either auto detect the module where a context variable
>is defined, or by adding a new keyword-only "module" parameter
>to ``ContextVar`` constructor.
> 
> 2. Not all context variables refer to picklable objects.  Making a
>``ContextVar`` picklable must be an opt-in.

This is a red herring.  If a value isn't picklable, pickle will simply
raise as it does in other contexts.  You should't need to opt in for
anything here.

Regards

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