[Python-Dev] Why wont duplicate methods be flagged as error (syntax or anything suitable error)

[joannah nanjekye]

Hello,

Apparently when you implement two methods with the same name:

def sub(x, y):
 print(x -y)

def sub(x, y):
 print(x -y)

Even with type hints.

def sub(x: int, y:int) -> int:
return x - y

def sub(x: float, y:float) -> float:
return 8

If you are from another background, you will expect the syntax with type
hints to act as though method overloading but instead last implementation
is always called. If this is the required behavior,then just flag any
duplicate method implementations as syntax errors.

Is this sort of method name duplication important in any cases?

Not aimed at criticism, just to understand.

-- 
Joannah Nanjekye
+256776468213
F : Nanjekye Captain Joannah
S : joannah.nanjekye
T : @Captain_Joannah
SO : joannah


*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program." Alan J. Perlis*
___
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] Why wont duplicate methods be flagged as error (syntax or anything suitable error)

[Chris Angelico]

On Sun, Jan 14, 2018 at 7:10 PM, joannah nanjekye
 wrote:
> Hello,
>
> Apparently when you implement two methods with the same name:
>
> def sub(x, y):
>  print(x -y)
>
> def sub(x, y):
>  print(x -y)
>
> Even with type hints.
>
> def sub(x: int, y:int) -> int:
> return x - y
>
> def sub(x: float, y:float) -> float:
> return 8
>
> If you are from another background, you will expect the syntax with type
> hints to act as though method overloading but instead last implementation is
> always called. If this is the required behavior,then just flag any duplicate
> method implementations as syntax errors.
>
> Is this sort of method name duplication important in any cases?
>
> Not aimed at criticism, just to understand.

This is not an error in the language for the same reason that any
other assignment isn't an error:

x = 5
x = 6

But you will find that a number of linters will flag this as a
warning. You can configure your editor to constantly run a linter and
show you when something's wrong.

ChrisA
___
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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Terry Reedy]

On 1/13/2018 3:02 PM, Brett Cannon wrote:



On Sat, Jan 13, 2018, 05:24 Antoine Pitrou, > wrote:


On Sat, 13 Jan 2018 13:54:33 +0100
Christian Heimes mailto:christ...@python.org>> wrote:
 >
 > If we agree to drop support for OpenSSL 0.9.8 and 1.0.1, then I
can land
 > bunch of useful goodies like proper hostname verification [2], proper
 > fix for IP address in SNI TLS header [3], PEP 543 compatible
Certificate
 > and PrivateKey types (support loading certs and keys from file and
 > memory) [4], and simplified cipher suite configuration [5]. I can
 > finally clean up _ssl.c during the beta phase, too.

Given the annoyance of supporting old OpenSSL versions, I'd say +1 to
this.


+1 from me as well for the improved security.


FWIW, given that I will not be doing any of the work, +1 from me also.

--
Terry Jan Reedy

___
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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Christian Heimes]

On 2018-01-14 01:03, Steven D'Aprano wrote:
> On Sat, Jan 13, 2018 at 02:23:19PM +0100, Antoine Pitrou wrote:
>> On Sat, 13 Jan 2018 13:54:33 +0100
>> Christian Heimes  wrote:
>>>
>>> If we agree to drop support for OpenSSL 0.9.8 and 1.0.1, then I can land
>>> bunch of useful goodies like proper hostname verification [2], proper
>>> fix for IP address in SNI TLS header [3], PEP 543 compatible Certificate
>>> and PrivateKey types (support loading certs and keys from file and
>>> memory) [4], and simplified cipher suite configuration [5]. I can
>>> finally clean up _ssl.c during the beta phase, too.
>>
>> Given the annoyance of supporting old OpenSSL versions, I'd say +1 to
>> this.
>>
>> We'll have to deal with the complaints of users of Debian oldstable,
>> CentOS 6 and RHEL 6, though.
> 
> It will probably be more work for Christian, but is it reasonable to 
> keep support for the older versions of OpenSSL, but make the useful 
> goodies conditional on a newer version?

It's much more than just goodies. For example the
X509_VERIFY_PARAM_set1_host() API fixes a whole lot of issues with
ssl.match_hostname(). The feature is OpenSSL 1.0.2+ and baked into the
certificate validation system. I don't see a realistic way to perform
the same task with 1.0.1.

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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Christian Heimes]

On 2018-01-14 03:48, Paul G wrote:
> One thing to note is that if getting Travis working with Python 3.7 is a
> pain, a huge number of libraries on PyPI probably just won't test
> against Python 3.7, which is not a great situation to be in.
> 
> It's probably worth contacting Travis to give them a head's up and see
> how likely it is that they'll be able to support Python 3.7 if it
> requires a newer version of these libraries.

Unless my proposal isn't rejected, I'll contact Travis CI tomorrow.

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] Why wont duplicate methods be flagged as error (syntax or anything suitable error)

[Steven D'Aprano]

On Sun, Jan 14, 2018 at 11:10:33AM +0300, joannah nanjekye wrote:

[...]
> Is this sort of method name duplication important in any cases?

Yes. For example, inside a class:

class MyClass(object):
@property
def something(self):
pass

@something.setter
def something(self):
pass


> Not aimed at criticism, just to understand.

This mailing list is not really for general discussions about Python, 
this is for the development of the Python interpreter. For questions 
about how Python works and the reasons for design choices such as 
allowing duplicate function or method definitions, please try 
python-l...@python.org, or a forum such as Reddit /r/python.


Thank you.



-- 
Steve
___
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] Why wont duplicate methods be flagged as error (syntax or anything suitable error)

[Ivan Levkivskyi]

On 14 January 2018 at 08:20, Chris Angelico  wrote:

> On Sun, Jan 14, 2018 at 7:10 PM, joannah nanjekye
>  wrote:
> > Hello,
> >
> > Apparently when you implement two methods with the same name:
> >
> > def sub(x, y):
> >  print(x -y)
> >
> > def sub(x, y):
> >  print(x -y)
> >
> > Even with type hints.
> >
> > def sub(x: int, y:int) -> int:
> > return x - y
> >
> > def sub(x: float, y:float) -> float:
> > return 8
> >
> > If you are from another background, you will expect the syntax with type
> > hints to act as though method overloading but instead last
> implementation is
> > always called. If this is the required behavior,then just flag any
> duplicate
> > method implementations as syntax errors.
> >
> > Is this sort of method name duplication important in any cases?
> >
> > Not aimed at criticism, just to understand.
>
> This is not an error in the language for the same reason that any
> other assignment isn't an error:
>
> x = 5
> x = 6
>
> But you will find that a number of linters will flag this as a
> warning. You can configure your editor to constantly run a linter and
> show you when something's wrong.
>

For example mypy (and probably also PyCharm) warn about
variable/function/class re-definition.

--
Ivan
___
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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Antoine Pitrou]

On Sat, 13 Jan 2018 23:45:07 +0100
Christian Heimes  wrote:
> On 2018-01-13 21:02, Brett Cannon wrote:
> > +1 from me as well for the improved security.  
> 
> Thanks, Brett!
> 
> How should we handle CPython's Travis CI tests? The 14.04 boxes have
> OpenSSL 1.0.1. To the best of my knowledge, Travis doesn't offer 16.04.
> We could either move to container-based testing with a 16.04 container,
> which would give us 1.0.2 Or we could compile our own copy of OpenSSL
> with my multissl builder and use some rpath magic.

I don't think you need some rpath magic, just set LD_LIBRARY_PATH to
the right value.

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

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Christian Heimes]

On 2018-01-14 11:17, Antoine Pitrou wrote:
> On Sat, 13 Jan 2018 23:45:07 +0100
> Christian Heimes  wrote:
>> On 2018-01-13 21:02, Brett Cannon wrote:
>>> +1 from me as well for the improved security.  
>>
>> Thanks, Brett!
>>
>> How should we handle CPython's Travis CI tests? The 14.04 boxes have
>> OpenSSL 1.0.1. To the best of my knowledge, Travis doesn't offer 16.04.
>> We could either move to container-based testing with a 16.04 container,
>> which would give us 1.0.2 Or we could compile our own copy of OpenSSL
>> with my multissl builder and use some rpath magic.
> 
> I don't think you need some rpath magic, just set LD_LIBRARY_PATH to
> the right value.

I prefer LD_RUN_PATH because it adds rpath to the ELF header of shared
libraries and binaries.

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

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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Matt Billenstein]

Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has
deprecated (and no longer ships the header files for) the version shipped with
recent versions of osx.

Perhaps this is an option to support the various flavors of Linux as well?

m

On Sun, Jan 14, 2018 at 02:48:49AM +, Paul G wrote:
>One thing to note is that if getting Travis working with Python 3.7 is a
>pain, a huge number of libraries on PyPI probably just won't test against
>Python 3.7, which is not a great situation to be in.
> 
>It's probably worth contacting Travis to give them a head's up and see how
>likely it is that they'll be able to support Python 3.7 if it requires a
>newer version of these libraries.
> 
>On January 14, 2018 2:16:53 AM UTC, Brett Cannon  wrote:
> 
>  On Sat, Jan 13, 2018, 14:45 Christian Heimes, 
>  wrote:
> 
>On 2018-01-13 21:02, Brett Cannon wrote:
>> +1 from me as well for the improved security.
> 
>Thanks, Brett!
> 
>How should we handle CPython's Travis CI tests? The 14.04 boxes have
>OpenSSL 1.0.1. To the best of my knowledge, Travis doesn't offer
>16.04.
>We could either move to container-based testing with a 16.04
>container,
>which would give us 1.0.2 Or we could compile our own copy of OpenSSL
>with my multissl builder and use some rpath magic.
> 
>In order to test all new features, Ubuntu doesn't cut it. Even current
>snapshot of Ubuntu doesn't contain OpenSSL 1.1. Debian Stretch or
>Fedora
>would do the trick, though.
> 
>Maybe Barry's work on official test container could leveraged testing?
> 
>  My guess is we either move to containers on Travis, see if we can
>  manually install -- through apt or something -- a newer version of
>  OpenSSL, or we look at alternative CI options.
>  -Brett
> 
>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/matt%40vazor.com


-- 
Matt Billenstein
m...@vazor.com
http://www.vazor.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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Christian Heimes]

On 2018-01-14 09:24, Matt Billenstein wrote:
> Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has
> deprecated (and no longer ships the header files for) the version shipped with
> recent versions of osx.
> 
> Perhaps this is an option to support the various flavors of Linux as well?

AFAK Apple has decided to compile and statically link CPython's ssl with
an ancient, customized LibreSSL version. Cory posted [1] a couple of
months ago

Can confirm: macOS 10.13 will ship a Python linked against LibreSSL
2.2.7. A downside: this continues to use the TEA, meaning you cannot
choose to distrust the system roots with it.

For TEA, see Hynek's blog post [2]


I'm not going to add OpenSSL sources or builds to CPython. We just got
rid of copies of libffi and other 3rd party dependencies. Crypto and TLS
libraries are much, MUCH more complicated to handle than libffi. It's a
constant moving targets of attacks. Vendors and distributions also have
different opinions about trust store and policies.

Let's keep build dependencies a downstream and vendor problem.

Christian

[1] https://twitter.com/lukasaoz/status/872085966579802112
[2] https://hynek.me/articles/apple-openssl-verification-surprises/


___
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] Deprecate PEP 370 Per user site-packages directory?

[Christian Heimes]

On 2018-01-14 04:16, Barry Warsaw wrote:
> On Jan 13, 2018, at 12:06, Christian Heimes  wrote:
> 
>> These days a lot of packages are using setuptools' entry points to
>> create console scripts. Entry point have no option to create a console
>> script with -s or -I flag. On my system, only 40 out of 360 scripts in
>> /usr/bin have -s or -I.
> 
> -I should be the default for system scripts; it’s not on Debian/Ubuntu though 
> unfortunately.

Same for most Fedora scripts. :/

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] Deprecate PEP 370 Per user site-packages directory?

[Nick Coghlan]

On 14 January 2018 at 03:06, Christian Heimes  wrote:
> Hi,
>
> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> virtual environment support in Python. Ian Bicking had just started to
> create the virtualenv project a couple of months earlier.
>
> Fast forward 10 years...
>
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful. I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
>
> I propose to deprecate the feature and remove it in Python 4.0.

Given that we're working towards making user site-packages the default
install location in pip, removing that feature at the interpreter
level would be rather counterproductive :)

Virtual environments are a useful tool if you're a professional
developer, but for a lot of folks just doing ad hoc personal
scripting, they're more complexity than is needed, and the simple "my
packages" vs "the system's package" split is a better option. (It's
also rather useful for bootstrapping tools like "pipsi" - "pip install
--user pipsi", then "pipsi install" the other commands you want access
to).

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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Ned Deily]

On Jan 14, 2018, at 08:39, Christian Heimes  wrote:
> On 2018-01-14 09:24, Matt Billenstein wrote:
>> Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has
>> deprecated (and no longer ships the header files for) the version shipped 
>> with
>> recent versions of osx.
>> 
>> Perhaps this is an option to support the various flavors of Linux as well?
> 
> AFAK Apple has decided to compile and statically link CPython's ssl with
> an ancient, customized LibreSSL version. Cory posted [1] a couple of
> months ago

I think you're conflating some things here.  Apple has not yet shipped a
version of Python 3 with macOS so the fact that Apple now links their
version of Python2.7 with a "private" copy of LibreSSL is irrelevant.
(It's private in the sense that they don't ship the header files for it;
the shared libs are there just for the use of the open source products
they ship with macOS that don't yet use the macOS native crypto APIs,
products like Python and Perl.)

What Matt is likely thinking of is the Python 3 versions provided by the
python.org macOS binary installers where we do build and link with our
own 1.0.2 (and soon 1.1.0 for 3.7) versions of OpenSSL.  Currently,
the OpenSSL (and several other third-party libs such as libxz which
is not shipped by Apple) are built as part of the installer build
script in the Mac section of the source repo.  I would like to
refactor and generalize that so those third-party libs
could optionally be used for non-installer builds as well.  But, in
any case, we don't have much choice for the installer builds until
such time as cPython has support for the Apple-provided crypto APIs.

> I'm not going to add OpenSSL sources or builds to CPython. We just got
> rid of copies of libffi and other 3rd party dependencies. Crypto and TLS
> libraries are much, MUCH more complicated to handle than libffi. It's a
> constant moving targets of attacks. Vendors and distributions also have
> different opinions about trust store and policies.
> 
> Let's keep build dependencies a downstream and vendor problem.

That's not always an option, unfortunately.

--
  Ned Deily
  n...@python.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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Wes Turner]

FWIW, anaconda and conda-forge currently have 1.0.2 X

https://anaconda.org/anaconda/openssl

https://anaconda.org/conda-forge/openssl

On Sunday, January 14, 2018, Ned Deily  wrote:

> On Jan 14, 2018, at 08:39, Christian Heimes  wrote:
> > On 2018-01-14 09:24, Matt Billenstein wrote:
> >> Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple
> has
> >> deprecated (and no longer ships the header files for) the version
> shipped with
> >> recent versions of osx.
> >>
> >> Perhaps this is an option to support the various flavors of Linux as
> well?
> >
> > AFAK Apple has decided to compile and statically link CPython's ssl with
> > an ancient, customized LibreSSL version. Cory posted [1] a couple of
> > months ago
>
> I think you're conflating some things here.  Apple has not yet shipped a
> version of Python 3 with macOS so the fact that Apple now links their
> version of Python2.7 with a "private" copy of LibreSSL is irrelevant.
> (It's private in the sense that they don't ship the header files for it;
> the shared libs are there just for the use of the open source products
> they ship with macOS that don't yet use the macOS native crypto APIs,
> products like Python and Perl.)
>
> What Matt is likely thinking of is the Python 3 versions provided by the
> python.org macOS binary installers where we do build and link with our
> own 1.0.2 (and soon 1.1.0 for 3.7) versions of OpenSSL.  Currently,
> the OpenSSL (and several other third-party libs such as libxz which
> is not shipped by Apple) are built as part of the installer build
> script in the Mac section of the source repo.  I would like to
> refactor and generalize that so those third-party libs
> could optionally be used for non-installer builds as well.  But, in
> any case, we don't have much choice for the installer builds until
> such time as cPython has support for the Apple-provided crypto APIs.


Support for Apple SecureTransport is part of the TLS module. IDK how far
along that work is (whether it'll be ready for 3.7 beta 1)?

https://github.com/python/peps/blob/master/pep-0543.rst

https://www.python.org/dev/peps/pep-0543/

http://markmail.org/search/?q=list%3Aorg.python+PEP+543+TLS


>
> > I'm not going to add OpenSSL sources or builds to CPython. We just got
> > rid of copies of libffi and other 3rd party dependencies. Crypto and TLS
> > libraries are much, MUCH more complicated to handle than libffi. It's a
> > constant moving targets of attacks. Vendors and distributions also have
> > different opinions about trust store and policies.
> >
> > Let's keep build dependencies a downstream and vendor problem.
>
> That's not always an option, unfortunately.
>
> --
>   Ned Deily
>   n...@python.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/
> 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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Christian Heimes]

On 2018-01-14 16:54, Ned Deily wrote:
> On Jan 14, 2018, at 08:39, Christian Heimes  wrote:
>> On 2018-01-14 09:24, Matt Billenstein wrote:
>>> Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has
>>> deprecated (and no longer ships the header files for) the version shipped 
>>> with
>>> recent versions of osx.
>>>
>>> Perhaps this is an option to support the various flavors of Linux as well?
>>
>> AFAK Apple has decided to compile and statically link CPython's ssl with
>> an ancient, customized LibreSSL version. Cory posted [1] a couple of
>> months ago
> 
> I think you're conflating some things here.  Apple has not yet shipped a
> version of Python 3 with macOS so the fact that Apple now links their
> version of Python2.7 with a "private" copy of LibreSSL is irrelevant.
> (It's private in the sense that they don't ship the header files for it;
> the shared libs are there just for the use of the open source products
> they ship with macOS that don't yet use the macOS native crypto APIs,
> products like Python and Perl.)
> 
> What Matt is likely thinking of is the Python 3 versions provided by the
> python.org macOS binary installers where we do build and link with our
> own 1.0.2 (and soon 1.1.0 for 3.7) versions of OpenSSL.  Currently,
> the OpenSSL (and several other third-party libs such as libxz which
> is not shipped by Apple) are built as part of the installer build
> script in the Mac section of the source repo.  I would like to
> refactor and generalize that so those third-party libs
> could optionally be used for non-installer builds as well.  But, in
> any case, we don't have much choice for the installer builds until
> such time as cPython has support for the Apple-provided crypto APIs.

Yeah, that sounds useful for macOS and Windows development. Back when I
was doing more Windows stuff, I used our buildbot scripts to provide
local builds of dependencies such as expat and OpenSSL.


>> I'm not going to add OpenSSL sources or builds to CPython. We just got
>> rid of copies of libffi and other 3rd party dependencies. Crypto and TLS
>> libraries are much, MUCH more complicated to handle than libffi. It's a
>> constant moving targets of attacks. Vendors and distributions also have
>> different opinions about trust store and policies.
>>
>> Let's keep build dependencies a downstream and vendor problem.
> 
> That's not always an option, unfortunately.

For Python.org macOS and Windows installers, I'm considering us as our
own downstream vendors. I should rather say "Steve and you" instead of
us. You are both doing the heavy lifting. Thanks for you hard work. :)

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] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Matt Billenstein]

On Sun, Jan 14, 2018 at 10:54:57AM -0500, Ned Deily wrote:
> On Jan 14, 2018, at 08:39, Christian Heimes  wrote:
> > On 2018-01-14 09:24, Matt Billenstein wrote:
> >> Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has
> >> deprecated (and no longer ships the header files for) the version shipped 
> >> with
> >> recent versions of osx.
> >> 
> >> Perhaps this is an option to support the various flavors of Linux as well?
> > 
> > AFAK Apple has decided to compile and statically link CPython's ssl with
> > an ancient, customized LibreSSL version. Cory posted [1] a couple of
> > months ago
> 
> What Matt is likely thinking of is the Python 3 versions provided by the
> python.org macOS binary installers where we do build and link with our
> own 1.0.2 (and soon 1.1.0 for 3.7) versions of OpenSSL.

Yes, referring to the Python3 python.org installers -- I'm seeing this practice
of bundling libs (particularly ssl) become more common as operating system
support lags behind.  In my mind it becomes easier to bundle deps in a binary
installer across the board (Linux, OSX, Windows) rather than rely on whatever
version the operating system provides.

m

-- 
Matt Billenstein
m...@vazor.com
http://www.vazor.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] Thoughts on "contexts". PEPs 550, 555, 567, 568

[Koos Zevenhoven]

The timing of all of this is unfortunate. I'm sorry that my participation
in the discussion has been a bit "on-off" lately. But my recent
contributions have involved studying things like the interaction of
threading/concurrency aspects of signal handling, as well as investigating
subtleties of various proposals for context variables, including my own.
Those are not exactly low-hanging fruit, and I'm sorry about not being able
to eat them.

It is also unfortunate that I haven't written down this proposal
("versions" A-C) to anywhere near the amount of precision than I did for
PEP 555, which wasn't 100% specified in the first draft either. For
consideration, I just thought it's better to at least mention it, so that
those that now have a good understanding of the issues involved could
perhaps understand it. I can add more detail, but to make it a full
proposal now, I would probably need to join forces with a coauthor (with a
good understanding of these issues) to figure out missing parts. I could
tune in later to finish the PEP and write docs in case the approach gets
implemented.

-- Koos


On Wed, Jan 10, 2018 at 7:17 PM, Guido van Rossum  wrote:

> I'm sorry, Koos, but based on your past contributions I am not interested
> in discussing this topic with you.
>
> On Wed, Jan 10, 2018 at 8:58 AM, Koos Zevenhoven 
> wrote:
>
>> The status of PEP 555 is just a side track. Here, I took a step back
>> compared to what went into PEP 555.
>>
>> —Koos
>>
>>
>> On Wed, Jan 10, 2018 at 6:21 PM, Guido van Rossum 
>> wrote:
>>
>>> The current status of PEP 555 is "Withdrawn". I have no interest in
>>> considering it any more, so if you'd rather see a decision from me I'll be
>>> happy to change it to "Rejected".
>>>
>>> On Tue, Jan 9, 2018 at 10:29 PM, Koos Zevenhoven 
>>> wrote:
>>>
 On Jan 10, 2018 07:17, "Yury Selivanov" 
 wrote:

 Wasn't PEP 555 rejected by Guido? What's the point of this post?


 I sure hope there is a point. I don't think mentioning PEP 555 in the
 discussions should hurt.

 A typo in my post btw: should be "PEP 567 (+568 ?)" in the second
 paragraph of course.

 -- Koos (mobile)


 Yury

 On Wed, Jan 10, 2018 at 4:08 AM Koos Zevenhoven 
 wrote:

> Hi all,
>
> I feel like I should write some thoughts regarding the "context"
> discussion, related to the various PEPs.
>
> I like PEP 567 (+ 567 ?) better than PEP 550. However, besides
> providing cvar.set(), I'm not really sure about the gain compared to PEP
> 555 (which could easily have e.g. a dict-like interface to the context).
> I'm still not a big fan of "get"/"set" here, but the idea was indeed to
> provide those on top of a PEP 555 type thing too.
>
> "Tokens" in PEP 567, seems to resemble assignment context managers in
> PEP 555. However, they feel a bit messy to me, because they make it look
> like one could just set a variable and then revert the change at any point
> in time after that.
>
> PEP 555 is in fact a simplification of my previous sketch that had a
> .set(..) in it, but was somewhat different from PEP 550. The idea was to
> always explicitly define the scope of contextvar values. A context manager
> / with statement determined the scope of .set(..) operations inside the
> with statement:
>
> # Version A:
> cvar.set(1)
> with context_scope():
> cvar.set(2)
>
> assert cvar.get() == 2
>
> assert cvar.get() == 1
>
> Then I added the ability to define scopes for different variables
> separately:
>
> # Version B
> cvar1.set(1)
> cvar2.set(2)
> with context_scope(cvar1):
> cvar1.set(11)
> cvar2.set(22)
>
> assert cvar1.get() == 1
> assert cvar2.get() == 22
>
>
> However, in practice, most libraries would wrap __enter__, set and
> __exit__ into another context manager. So maybe one might want to allow
> something like
>
> # Version C:
> assert cvar.get() == something
> with context_scope(cvar, 2):
> assert cvar.get() == 2
>
> assert cvar.get() == something
>
>
> But this then led to combining "__enter__" and ".set(..)" into
> Assignment.__enter__ -- and "__exit__" into Assignment.__exit__ like this:
>
> # PEP 555 draft version:
> assert cvar.value == something
> with cvar.assign(1):
> assert cvar.value == 1
>
> assert cvar.value == something
>
>
> Anyway, given the schedule, I'm not really sure about the best thing
> to do here. In principle, something like in versions A, B and C above 
> could
> be done (I hope the proposal was roughly self-explanatory based on earlier
> discussions). However, at this point, I'd probably need a lot of help to
> make that happen for 3.7.
>
> -- Koos
>
> _

Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568

[Koos Zevenhoven]

I'll quickly add a few things below just in case there's anyone that cares.

On Wed, Jan 10, 2018 at 2:06 AM, Koos Zevenhoven  wrote:

>
> The idea was to always explicitly define the scope of contextvar values. A
> context manager / with statement determined the scope of .set(..)
> operations inside the with statement:
>
> # Version A:
> cvar.set(1)
> with context_scope():
> cvar.set(2)
>
> assert cvar.get() == 2
>
> assert cvar.get() == 1
>
> Then I added the ability to define scopes for different variables
> separately:
>
> # Version B
> cvar1.set(1)
> cvar2.set(2)
> with context_scope(cvar1):
> cvar1.set(11)
> cvar2.set(22)
>
> assert cvar1.get() == 1
> assert cvar2.get() == 22
>
>
> However, in practice, most libraries would wrap __enter__, set and
> __exit__ into another context manager. So maybe one might want to allow
> something like
>
> # Version C:
> assert cvar.get() == something
> with context_scope(cvar, 2):
> assert cvar.get() == 2
>
> assert cvar.get() == something
>
>
Note here, that the point is to get a natural way to "undo" changes made to
variables when exiting the scope. Undoing everything that is done within
the defined scope is a very natural way to do it. Undoing individual
.set(..) operations is more problematic.

Features B+C could be essentially implemented as described in PEP 555,
except with context_scope(cvar) being essentially the same as pushing and
popping an empty Assignment object onto the reverse-linked stack. By empty,
I mean a "key-value pair with a missing value". Then any set operations
would replace the topmost assignment object for that variable with a new
key-value pair (or push a new Assignment if there isn't one).

​However, to also get feature A, the stack may have to contain full
mappings instead of assignemnt objects with just one key-value pair.

I hope that clarifies some parts. Otherwise, in terms of semantics, the
same things apply as for PEP 555 when it comes to generator function calls
and next(..) etc., so we'd need to make sure it works well enough for all
use cases. For instance, I'm not quite sure if I have a good enough
understanding of the timeout example that Nathaniel wrote in the PEP 550
discussion to tell what would be required in terms of semantics, but I
suppose it should be fine.

-- Koos


> But this then led to combining "__enter__" and ".set(..)" into
> Assignment.__enter__ -- and "__exit__" into Assignment.__exit__ like this:
>
> # PEP 555 draft version:
> assert cvar.value == something
> with cvar.assign(1):
> assert cvar.value == 1
>
> assert cvar.value == something
>
>
> Anyway, given the schedule, I'm not really sure about the best thing to do
> here. In principle, something like in versions A, B and C above could be
> done (I hope the proposal was roughly self-explanatory based on earlier
> discussions). However, at this point, I'd probably need a lot of help to
> make that happen for 3.7.
>
> -- Koos
>
>


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
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