Re: [Python-Dev] [python-committers] Proposed release schedule for Python 3.5.4

2017-06-22 Thread Victor Stinner 
For 3.4, please review my pending security fixes :-) There are more of them.

About the cipher list in ssl, the change itself is simple but it's to
blacklist DES and 3DES since it has been proved that these ciphers are
really too weak nowadays:
http://python-security.readthedocs.io/vuln/cve-2016-2183_sweet32_attack_des_3des.html

By the way, is Larry the only one to be able to merge changes in 3.4?
Before GitHub, all core dev were technically allowed to push in
security-only branches.

I would be interested to be allowed to push my own security fixes, but also
to enable Travis CI and maybe AppVeyor on the 3.4 and 3.3 branches.

Victor

Le 22 juin 2017 04:58, "Larry Hastings"  a écrit :

>
>
> It's time to start planning the next 3.5 release, 3.5.4.  Note that this
> will be the last 3.5 "bugfix" release; after 3.5.4, the 3.5 branch will
> only be open for security fixes.  3.5.4 will also be the last release of
> 3.5 with binary installers.
>
> I propose to tag and release 3.5.4 on these dates:
>
> 3.5.4rc1
> tag Sat July 22 2017
> release Sun July 23 2017
>
> 3.5.4 final
> tag Sun Aug 6 2017
> release Mon Aug 7 2017
>
> Thus rc1 would be tagged in just over four weeks.
>
>
> As for 3.4--
>
> Lately I've been releasing new versions of 3.5 and 3.4 at the same time.
> But I'm not sure it's worth the effort to release another 3.4 right now.
> There have only been two (2) checkins into the 3.4 branch since 3.4.6 was
> released back in January:
>
> f37b0cb230069481609b0bb06891b5dd26320504
> bpo-25008: Deprecate smtpd and point to aiosmtpd
>
> fa53dbdec818b0f2a0e22ca12a49d83ec948fc91
> Issues #27850 and #27766: Remove 3DES from ssl
> default cipher list and add ChaCha20 Poly1305.
>
>
> The first was a documentation-only change which is already live on
> docs.python.org.  The second changes the _DEFAULT_CIPHERS and
> _RESTRICTED_SERVER_CIPHERS constants in Lib/ssl.py.  A reasonable change,
> but minor.  I'm not convinced it's worth spending the time of many people
> in the community at large to update 3.4 just for this.
>
> If you have any feedback / concerns about this schedule, or if you think
> it's important that I release 3.4.7 with these minor changes, please reply
> here.  If I don't hear anything back in a day or two I'll go ahead and make
> this the official schedule.
>
>
> Your friendly neighborhood release manager,
>
>
> */arry*
>
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
___
Python-Dev mailing list
[email protected]
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-committers] Proposed release schedule for Python 3.5.4

2017-06-22 Thread Larry Hastings 



On 06/22/2017 01:04 AM, Victor Stinner wrote:
About the cipher list in ssl, the change itself is simple but it's to 
blacklist DES and 3DES since it has been proved that these ciphers are 
really too weak nowadays:

http://python-security.readthedocs.io/vuln/cve-2016-2183_sweet32_attack_des_3des.html


Not "blacklist"--IIUC the user can still manually specify whatever 
cipher suites they like.  And not DES... who knows how long ago that was 
removed from the list.


This change in 3.4 removes 3DES from the /default/ permissible cipher 
list, changing those entries to use "HIGH cipher suites" instead 
(OpenSSL's term for "cipher suites with key sizes >= 128 bytes").  It 
also adds ChaCha20 to the default cipher list.



By the way, is Larry the only one to be able to merge changes in 3.4? 
Before GitHub, all core dev were technically allowed to push in 
security-only branches.


Oh?  Am I? **insert evil laugh** Ladies and gentlemen, get out your 
checkbooks!  3.4 is about to get... expensive.


Seriously, though, I was mostly hoping other people would handle the 
security stuff and just keep me informed.  If I'm the only one permitted 
to accept PRs into 3.4 (and soon 3.5), okay, I can work with that.  I'm 
still probably gonna delegate the actual judgment of the validity of the 
PRs.  But obviously it'll mean I'll have to be more hands-on, where so 
far I was assuming I could just let other people handle it.



//arry/
___
Python-Dev mailing list
[email protected]
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 544: Protocols - second round

2017-06-22 Thread Markus Wissinger 
Hi,

I have to admit I am not happy with separating the concepts of 'runtime'
and 'static' types as implied by pep544.

I am currently exploring a type hint generator that produces hints out of
types used in unit tests. It debugs the tests and collects the parameter
types of call and return events. It ignores a type when a supertype is
present. Failing isinstance/issubclass calls for protocols would hurt
there. I understand that any type checker code that could provide
isinstance functionality for pep544 protocols would rely on method
signatures that my hint generator is just producing.

proof of concept implementation (writes method docstrings, no pep484 type
hints yet):
https://github.com/markuswissinger/ducktestpy

This is currently just some personal project that some of you will consider
a strange idea. I just want to mention that this use case might not play
well together with pep544.

Regards
Markus

2017-06-05 23:59 GMT+02:00 Guido van Rossum :

> On Fri, Jun 2, 2017 at 3:10 PM, Ivan Levkivskyi 
> wrote:
>
>> On 1 June 2017 at 00:10, Guido van Rossum  wrote:
>>
>>>
>>> On Wed, May 31, 2017 at 2:16 AM, Ivan Levkivskyi 
>>> wrote:
>>>
 On 31 May 2017 at 00:58, Guido van Rossum  wrote:
 [...]

 Thank you for very detailed answers! I have practically nothing to add.
 It seems to me that most of the Kevin's questions stem from unnecessary
 focus
 on runtime type checking. Here are two ideas about how to fix this:

 * Add the word "static" somewhere in the PEP title.

>>>
>>> So the title could become "Protocols: Static structural subtyping (duck
>>> typing)" -- long, but not record-setting.
>>>
>>
>> I am thinking about "Protocols: Structural subtyping (static duck
>> typing)". The reason is that subtyping is already a mostly static concept
>> (in contrast to subclassing),
>> while duck typing is typically associated with the runtime behaviour.
>>
>> This might seem minor, but this version of the title sounds much more
>> naturally to me.
>>
>
> +1
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> markus.wissinger%40gmail.com
>
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Core-mentorship] C version of weakrefset.py.

2017-06-22 Thread Bhavishya 
Hello,
1)I might be totally wrong here, but even if we go with stripping
annotation(in .pyc)...still the "lag" that comes from ABCs needs to be
addressed.

2) I been reading for past few days about your fat-optimizer project and
the corresponding TO-DO list, if you think that PEP-0511 should be
improved, I can work on that.

3)Also I was seeing to existing repos which implement some-kind of
optimizaton, like
numpy,snake-oil

Finally I wanted to decide upon a roadmap, so that I could put more
specific efforts.(fat optimizer?)

Thank You
Regards,
Bhavishya

On Wed, Jun 21, 2017 at 8:05 PM, Victor Stinner 
wrote:

> 2017-06-21 15:21 GMT+02:00 INADA Naoki :
> > ABC slowdown Python startup only 2ms.  But importing typing module take
> 11ms.
> > While typing is not imported from site.py, many new Python application
> > will import it.
> > It may take over 100ms for applications or libraries heavily depending
> on ABCs.
>
> When typing is not used in the application, only used for static
> checks, you can try to "strip" annotations to avoid any overhead on
> the application startup. It's not only a matter of "import typing",
> it's also the cost of instanciating types like "List[int]" (or even
> more complex ones).
>
> I discussed with Jukka Lehtosalo at Pycon US about stripping
> completely annotations. He told me that my PEP 511 may be a good
> solution to keep annotation in the .py code, but strip them for
> "production code", in the cached .pyc files:
>
> "PEP 511 -- API for code transformers"
> https://www.python.org/dev/peps/pep-0511/
>
> This PEP is somehow controversal. Some people fear that it would allow
> people to hack the Python language to write their own incompatible
> variant of Python. I don't think that my PEP adds anything new, it's
> already possible to do that, importlib made it even more easy. I used
> my FAT Python optimizer project to sell this PEP. Since FAT Python is
> also controversal (it hasn't been proved to be actually faster), the
> PEP didn't go far at my last attempt.
>
> Note: Is core-menthorship the best place for such performance
> discussion? :-) Maybe we should open a thread on python-dev@ or speed@
> mailing list.
>
> Victor
>
___
Python-Dev mailing list
[email protected]
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-committers] Proposed release schedule for Python 3.5.4

2017-06-22 Thread Brett Cannon 
On Thu, 22 Jun 2017 at 02:32 Larry Hastings  wrote:

>
>
> On 06/22/2017 01:04 AM, Victor Stinner wrote:
>
> About the cipher list in ssl, the change itself is simple but it's to
> blacklist DES and 3DES since it has been proved that these ciphers are
> really too weak nowadays:
>
> http://python-security.readthedocs.io/vuln/cve-2016-2183_sweet32_attack_des_3des.html
>
>
> Not "blacklist"--IIUC the user can still manually specify whatever cipher
> suites they like.  And not DES... who knows how long ago that was removed
> from the list.
>
> This change in 3.4 removes 3DES from the *default* permissible cipher
> list, changing those entries to use "HIGH cipher suites" instead (OpenSSL's
> term for "cipher suites with key sizes >= 128 bytes").  It also adds
> ChaCha20 to the default cipher list.
>
>
>
> By the way, is Larry the only one to be able to merge changes in 3.4?
> Before GitHub, all core dev were technically allowed to push in
> security-only branches.
>
>
> Oh?  Am I? **insert evil laugh** Ladies and gentlemen, get out your
> checkbooks!  3.4 is about to get... expensive.
>
> Seriously, though, I was mostly hoping other people would handle the
> security stuff and just keep me informed.  If I'm the only one permitted to
> accept PRs into 3.4 (and soon 3.5), okay, I can work with that.  I'm still
> probably gonna delegate the actual judgment of the validity of the PRs.
> But obviously it'll mean I'll have to be more hands-on, where so far I was
> assuming I could just let other people handle it.
>

Currently the security-only branches are set so that only release managers
can merge PRs since they technically are on the hook if some compatibility
breaks due to some patch (e.g. I expect Ned to use this for 3.7 once we hit
rc to really control what goes in last minute). It's easy enough to turn
this protection off, though, if people want.
___
Python-Dev mailing list
[email protected]
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 544: Protocols - second round

2017-06-22 Thread Stéfane Fermigier 
On Thu, Jun 22, 2017 at 10:44 AM, Markus Wissinger <
[email protected]> wrote:

> Hi,
>
> I have to admit I am not happy with separating the concepts of 'runtime'
> and 'static' types as implied by pep544.
>
> I am currently exploring a type hint generator that produces hints out of
> types used in unit tests. It debugs the tests and collects the parameter
> types of call and return events. It ignores a type when a supertype is
> present. Failing isinstance/issubclass calls for protocols would hurt
> there. I understand that any type checker code that could provide
> isinstance functionality for pep544 protocols would rely on method
> signatures that my hint generator is just producing.
>
> proof of concept implementation (writes method docstrings, no pep484 type
> hints yet):
> https://github.com/markuswissinger/ducktestpy
>
> This is currently just some personal project that some of you will
> consider a strange idea.
>

Not a strange idea, I've had a similar idea and played a bit with it ~10
years ago (inspired by a Java project whose name eludes me now).

Also, I think PyCharm is able to do similar things (see
https://blog.jetbrains.com/pycharm/2013/02/dynamic-runtime-type-inference-in-pycharm-2-7/
).

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free&OSS Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
[email protected]
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 544: Protocols - second round

2017-06-22 Thread Ivan Levkivskyi 
On 22 June 2017 at 10:44, Markus Wissinger 
wrote:

> I have to admit I am not happy with separating the concepts of 'runtime'
> and 'static' types as implied by pep544.
>

This is not something new, already PEP 483 makes a clear distinction
between types (a static concept) and classes (a runtime concept).


> Failing isinstance/issubclass calls for protocols would hurt there. I
> understand that any type checker code that could provide isinstance
> functionality for pep544 protocols would rely on method signatures that my
> hint generator is just producing.
>

isinstance(obj, T) and issubclass(Cls, T) already fail if T is a
subscripted generic like List[int], so that again nothing new here. To
check runtime subtyping with such types one can write a third party
introspection tool based on typing_inspect package on PyPI (which
potentially might in future become an official wrapper for currently
internal typing API).

--
Ivan
___
Python-Dev mailing list
[email protected]
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 544: Protocols - second round

2017-06-22 Thread Stefan Richthofer 

>> I am currently exploring a type hint generator that produces hints out of types used in unit tests.

 

Note that pytypes (https://github.com/Stewori/pytypes) already supports this. It can dump PEP 484 style stubfiles from runtime type observations (made via decorators or profiler hook).

 

>> isinstance(obj, T) and issubclass(Cls, T) already fail if T is a subscripted generic like List[int], so that again nothing new here. To check runtime subtyping with such types one can write a third party introspection tool based on typing_inspect package on PyPI

 

There are public API functions in pytypes for isinstance and issubclass with support for most PEP 484 types, see https://github.com/Stewori/pytypes#is_of_typeobj-cls and https://github.com/Stewori/pytypes#is_subtypesubclass-superclass respectively. We also use them internally for pytypes' runtime typechecking features.

 

Unfortunately there is no release finalized yet, but it's mostly cleanup work and pip integration left to do. Hope to get a beta release done soon.

 

Best

 

-Stefan

 

Gesendet: Donnerstag, 22. Juni 2017 um 23:53 Uhr
Von: "Ivan Levkivskyi" 
An: "Markus Wissinger" 
Cc: Python-Dev 
Betreff: Re: [Python-Dev] PEP 544: Protocols - second round




On 22 June 2017 at 10:44, Markus Wissinger  wrote:


I have to admit I am not happy with separating the concepts of 'runtime' and 'static' types as implied by pep544.


 

This is not something new, already PEP 483 makes a clear distinction between types (a static concept) and classes (a runtime concept).

 



Failing isinstance/issubclass calls for protocols would hurt there. I understand that any type checker code that could provide isinstance functionality for pep544 protocols would rely on method signatures that my hint generator is just producing.



 

isinstance(obj, T) and issubclass(Cls, T) already fail if T is a subscripted generic like List[int], so that again nothing new here. To check runtime subtyping with such types one can write a third party introspection tool based on typing_inspect package on PyPI (which potentially might in future become an official wrapper for currently internal typing API).

--

Ivan

 



___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.de



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

Re: [Python-Dev] [Core-mentorship] C version of weakrefset.py.

2017-06-22 Thread Bhavishya 
Also I saw your conversation with "Brett Cannon" on lazy-loading some
modules at  startup, and also doing so using ModuleProxy(also several
implementations that exist like importlib's Lazyloader
,
PEAK  ).
So your suggestion's on this too?

Thank You

regards,
Bhavishya

On Thu, Jun 22, 2017 at 7:24 PM, Bhavishya 
wrote:

> Hello,
> 1)I might be totally wrong here, but even if we go with stripping
> annotation(in .pyc)...still the "lag" that comes from ABCs needs to be
> addressed.
>
> 2) I been reading for past few days about your fat-optimizer project and
> the corresponding TO-DO list, if you think that PEP-0511 should be
> improved, I can work on that.
>
> 3)Also I was seeing to existing repos which implement some-kind of
> optimizaton, like
> numpy,snake-oil
>
> Finally I wanted to decide upon a roadmap, so that I could put more
> specific efforts.(fat optimizer?)
>
> Thank You
> Regards,
> Bhavishya
>
> On Wed, Jun 21, 2017 at 8:05 PM, Victor Stinner 
> wrote:
>
>> 2017-06-21 15:21 GMT+02:00 INADA Naoki :
>> > ABC slowdown Python startup only 2ms.  But importing typing module take
>> 11ms.
>> > While typing is not imported from site.py, many new Python application
>> > will import it.
>> > It may take over 100ms for applications or libraries heavily depending
>> on ABCs.
>>
>> When typing is not used in the application, only used for static
>> checks, you can try to "strip" annotations to avoid any overhead on
>> the application startup. It's not only a matter of "import typing",
>> it's also the cost of instanciating types like "List[int]" (or even
>> more complex ones).
>>
>> I discussed with Jukka Lehtosalo at Pycon US about stripping
>> completely annotations. He told me that my PEP 511 may be a good
>> solution to keep annotation in the .py code, but strip them for
>> "production code", in the cached .pyc files:
>>
>> "PEP 511 -- API for code transformers"
>> https://www.python.org/dev/peps/pep-0511/
>>
>> This PEP is somehow controversal. Some people fear that it would allow
>> people to hack the Python language to write their own incompatible
>> variant of Python. I don't think that my PEP adds anything new, it's
>> already possible to do that, importlib made it even more easy. I used
>> my FAT Python optimizer project to sell this PEP. Since FAT Python is
>> also controversal (it hasn't been proved to be actually faster), the
>> PEP didn't go far at my last attempt.
>>
>> Note: Is core-menthorship the best place for such performance
>> discussion? :-) Maybe we should open a thread on python-dev@ or speed@
>> mailing list.
>>
>> Victor
>>
>
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com