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

[Mario Corchero]

OK, if no one has anything against, Pablo and I can start a PEP just for
the ‘/‘ simple syntax (without the argument group part).

On Sat, 20 Jan 2018 at 07:17, Larry Hastings  wrote:

>
>
> On 01/19/2018 08:47 PM, Nick Coghlan wrote:
>
> - proposing the full PEP 547, including the "argument groups" feature
> (which is a bigger change, but allows the expression of signatures
> like "range([start,] stop, [step,] /)")
>
>
> I hope we don't go down that route.
>
> I added support for "argument groups" to Argument Clinic in an attempt to
> support legacy functions with crazy argument signatures that count their
> arguments.  (For example, curses.window.overlay() takes either one or seven
> arguments exactly--not two!, and not six!.)  I have deeply mixed feelings
> about the result, and I would hate to see support for it added to the
> language.  If I had my way I'd rewrite or replace those functions and have
> only modern Pythonic signatures in the standard library.
>
>
> */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] LibreSSL support

[Christian Heimes]

On 2018-01-19 15:42, Christian Heimes wrote:
> On 2018-01-19 10:43, Steve Holden wrote:
>> On Fri, Jan 19, 2018 at 12:09 AM, Nathaniel Smith > > wrote:
>>
>> 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
>>
>>
>> ​[...]
>>
>>  
>>
>> 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.
>>
>> ​Given the hard limit on resources it seems only sensible to focus on
>> the "industry standard" library​. I'm rather disappointed that LibreSSL
>> isn't a choice, but given the lack of compatibility that's hardly
>> Python's problem.
> 
> Thanks!
> 
> I'd prefer to support LibreSSL, too. Paul Kehrer from PyCA summed up the
> issue with LibreSSL nicely:
> 
>> It was marketed as an API compatible drop-in replacement and it is
> failing in that capacity. Additionally, it is missing features needed to
> improve the security and ease the maintenance burden of CPython’s dev team.
> 
> 
> Since I haven given up on LibreSSL, I spent some time and implemented
> some autoconf magic in https://github.com/python/cpython/pull/5242. It
> checks for the presence of libssl and X509_VERIFY_PARAM_set1_host()
> function family:
> 
> ...
> checking whether compiling and linking against OpenSSL works... yes
> checking for X509_VERIFY_PARAM_set1_host in libssl... yes
> ...
> 
> The ssl module will regain compatibility with LibreSSL as soon as a new
> release provides the necessary functions.

No core developer has vetoed against my proposal. I also spoke to
several members of Python Cryptographic Authority and Python Packaging
Authority. They are all in favor of my proposal, too.

There I have decided to move forward and require OpenSSL 1.0.2 API. This
means Python 3.7 temporarily suspends support for LibreSSL until
https://github.com/libressl-portable/portable/issues/381 is resolved. I
have appended a lengthy explanation to my LibreSSL ticket, too.

I also informed LibreSSL developers that Python 3.8 will most likely
require an OpenSSL 1.1 compatible API. With OpenSSL 1.0.2 support, I can
drop a considerable amount of legacy code, e.g. custom thread locking,
initialization and a bunch of shim functions.

Regards,
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] Unique loader per module

[Barry Warsaw]

On Jan 05, 2018, at 05:12 PM, Nick Coghlan wrote:

>I think the main reason you're seeing a problem here is because
>ResourceReader has currently been designed to be implemented directly
>by loaders, rather than being a subcomponent that you can request
>*from* a loader.
>
>If you instead had an indirection API (that could optionally return
>self in the case of non-shared loaders), you'd keep the current
>resource reader method signatures, but the way you'd access the itself
>would be:
>
>resources = module.__spec__.loader.get_resource_reader(module)
># resources implements the ResourceReader ABC

BTW, just as a quick followup, this API suggestion was brilliant, Nick.  It
solved the problem nicely, and let me add support for ResourceReader to
zipimport with only touching the bare minimum of zipimport.c. :)

https://github.com/python/cpython/pull/5248

Cheers,
-Barry


pgpmPkp2zc3oF.pgp
Description: OpenPGP digital signature
___
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

[Guido van Rossum]

On Sat, Jan 20, 2018 at 1:25 AM, Mario Corchero  wrote:

> OK, if no one has anything against, Pablo and I can start a PEP just for
> the ‘/‘ simple syntax (without the argument group part).
>

Go for it!

Note that your target will be Python 3.8.

-- 
--Guido van Rossum (python.org/~guido)
___
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?

[Florian Weimer]

* Victor Stinner:

> 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.

There are still reasonably widely used 2.6 kernels under support, but
they have lots of (feature) backports, so maybe they do not need the
2.6.32 workarounds you plan to remove.

(glibc upstream nowadays requires Linux 3.2 (stable branch) as the
minimum, but then people are less likely to update glibc on really old
systems.)

> 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).

What exactly do you plan to change?  Is it about unconditionally
assuming accept4 support?  accept4 support was added to Linux 3.3 on
ia64.  This is not uncommon: The first version in which a particular
(generic) system call is available varies a lot between architectures.
You'll have to investigate each case separately.
___
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