Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tuesday, August 30, 2016, Nick Coghlan wrote: > On 31 August 2016 at 13:37, Jack Diederich > wrote: > > On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum > wrote: > >> But myfunc.__annotations__ already

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On 31 August 2016 at 13:37, Jack Diederich wrote: > On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum wrote: >> But myfunc.__annotations__ already exists -- PEP 3107 puts the >> signature annotations there. The problem with co_annotations is that >>

Re: [Python-Dev] File system path encoding on Windows

On 31 August 2016 at 10:27, Steve Dower wrote: > On 30Aug2016 1702, Victor Stinner wrote: >> I can try to run more tests if you know some other major Python >> applications (modules?) working on Windows/Python 3. > > The major ones aren't really the concern. I'd be

Re: [Python-Dev] Supported versions of OpenSSL

On 31 August 2016 at 09:55, Gregory P. Smith wrote: > On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg wrote: >> Yet, a move to require OpenSSL 1.0.2 for Python 3.7 will make >> it impossible to run such apps on systems that still use OpenSSL >> 1.0.1, e.g. Ubuntu

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On 31 August 2016 at 04:55, Serhiy Storchaka wrote: > On 30.08.16 21:20, Antoine Pitrou wrote: >> But the performance overhead of iterating over a 1-element list >> is small enough (it's just an array access after a pointer dereference) >> that it may not be larger than the

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On 31 August 2016 at 07:11, Chris Angelico wrote: > Didn't all this kind of thing come up when function annotations were > discussed? Insane schemes like dictionaries with UUID keys and so on. > The decision then was YAGNI. The decision now, IMO, should be the > same. Keep

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On 31 August 2016 at 05:06, Serhiy Storchaka wrote: > On 30.08.16 20:42, Nick Coghlan wrote: >> Given Serhiy's clarification that this is primarily a thread safety >> problem, I'm more supportive of the "PySlice_GetIndicesForObject" >> approach (since that can call all the

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum wrote: > On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich > wrote: > > +0. We should try and be consistent even if this is a thing I don't want. > > And trust me, I don't! > > No problem. You won't have to!

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich wrote: > +0. We should try and be consistent even if this is a thing I don't want. > And trust me, I don't! No problem. You won't have to! > That said, as long as pro-mypy people are willing to make everyone else pay > a mypy

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

+0. We should try and be consistent even if this is a thing I don't want. And trust me, I don't! That said, as long as pro-mypy people are willing to make everyone else pay a mypy reading tax for code let's try and reduce the cognitive burden. * Duplicate type annotations should be a syntax

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano wrote: > On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote: >> I'm happy to present PEP 526 for your collective review: > > Are you hoping to get this in before 3.6 beta? Because I'm not sure I > can give this

Re: [Python-Dev] Lib/http/client.py: could it return an OSError with the current response?

On 30 August 2016 at 13:41, Ivo Bellin Salarin wrote: > While using requests to tunnel a request via a proxy requiring user > authentication, I have seen that httplib > (https://hg.python.org/cpython/file/3.5/Lib/http/client.py#l831) raises the > message returned by

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote: > I'm happy to present PEP 526 for your collective review: Are you hoping to get this in before 3.6 beta? Because I'm not sure I can give this much attention before then, but I really want to. -- Steve

Re: [Python-Dev] File system path encoding on Windows

On 30Aug2016 1702, Victor Stinner wrote: I made another quick test on Django 1.10 (I ran Django test suite on my modified Python raising exception on bytes path): I didn't notice any exception related to bytes path. Django seems to only use Unicode for paths. I can try to run more tests if you

Re: [Python-Dev] File system path encoding on Windows

I made another quick test on Django 1.10 (I ran Django test suite on my modified Python raising exception on bytes path): I didn't notice any exception related to bytes path. Django seems to only use Unicode for paths. I can try to run more tests if you know some other major Python applications

Re: [Python-Dev] Supported versions of OpenSSL

On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg wrote: > On 29.08.2016 22:16, 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: > >

Re: [Python-Dev] File system path encoding on Windows

On 30Aug2016 1611, Victor Stinner wrote: 2016-08-30 23:51 GMT+02:00 Victor Stinner : As I already wrote once, my problem is also tjat I simply have no idea how much Python 3 code uses bytes filename. For example, does it concern more than 25% of py3 modules on PyPi, or

Re: [Python-Dev] File system path encoding on Windows

2016-08-30 23:51 GMT+02:00 Victor Stinner : > As I already wrote once, my problem is also tjat I simply have no idea how > much Python 3 code uses bytes filename. For example, does it concern more > than 25% of py3 modules on PyPi, or less than 5%? I made a very quick

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, 30 Aug 2016 at 14:21 Guido van Rossum wrote: > I'm happy to present PEP 526 for your collective review: > https://www.python.org/dev/peps/pep-0526/ (HTML) > https://github.com/python/peps/blob/master/pep-0526.txt (source) > > There's also an implementation ready: >

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

Thanks Guido, also to the rest of the PEP team (4 people) :) On 30.08.2016 23:20, Guido van Rossum wrote: I'm happy to present PEP 526 for your collective review: https://www.python.org/dev/peps/pep-0526/ (HTML) https://github.com/python/peps/blob/master/pep-0526.txt (source) There's also an

Re: [Python-Dev] Supported versions of OpenSSL

> On 30 Aug 2016, at 16:07, M.-A. Lemburg wrote: > > That was not my point. It's unfortunate that Python depends on > a library which is inevitably going to need updates frequently, > and which then may have the implication that Python won't compile on > systems which don't

Re: [Python-Dev] File system path encoding on Windows

Le 30 août 2016 8:05 PM, "Nick Coghlan" a écrit : > This seems to be the crux of the disagreement: our perceptions of the > relative risks to native Windows Python applications that currently > work properly on Python 3.5 vs the potential compatibility benefits to > primarily

[Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

I'm happy to present PEP 526 for your collective review: https://www.python.org/dev/peps/pep-0526/ (HTML) https://github.com/python/peps/blob/master/pep-0526.txt (source) There's also an implementation ready: https://github.com/ilevkivskyi/cpython/tree/pep-526 I don't want to post the full text

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Wed, Aug 31, 2016 at 4:55 AM, Serhiy Storchaka wrote: > On 30.08.16 21:20, Antoine Pitrou wrote: >> >> On Tue, 30 Aug 2016 18:12:01 + >> Brett Cannon wrote: Why not make it always a list? List objects are reasonably cheap in memory

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 11:56 Serhiy Storchaka wrote: > On 30.08.16 21:20, Antoine Pitrou wrote: > > On Tue, 30 Aug 2016 18:12:01 + > > Brett Cannon wrote: > >>> Why not make it always a list? List objects are reasonably cheap in > >>> memory and

Re: [Python-Dev] Supported versions of OpenSSL

On 29.08.2016 22:16, 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

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On 30.08.16 20:42, 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

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On 30.08.16 21:20, Antoine Pitrou wrote: On Tue, 30 Aug 2016 18:12:01 + Brett Cannon wrote: Why not make it always a list? List objects are reasonably cheap in memory and access time... (unlike dicts) Because I would prefer to avoid any form of unnecessary performance

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 18:12:01 + Brett Cannon wrote: > > Why not make it always a list? List objects are reasonably cheap in > > memory and access time... (unlike dicts) > > Because I would prefer to avoid any form of unnecessary performance > overhead for the common case.

Re: [Python-Dev] File system path encoding on Windows

On 30Aug2016 1108, Guido van Rossum wrote: Is this thread something I need to follow closely? I have PEPs coming, and I'll distil the technical parts of the discussion into those. We may need you to impose an opinion on whether 3.6 is an appropriate time for the change or it should wait

Re: [Python-Dev] File system path encoding on Windows

On 31 August 2016 at 01:06, Victor Stinner wrote: > 2016-08-30 16:31 GMT+02:00 Steve Dower : >> Any system that requires communication between two different versions of >> Python must have install instructions (if it's public) or someone who >>

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 10:49 Antoine Pitrou wrote: > On Tue, 30 Aug 2016 17:35:35 + > Brett Cannon wrote: > > > > > > Perhaps a list would work indeed. Realistically, if there are at most > > > 2-3 users of the field at any given time (and most

Re: [Python-Dev] File system path encoding on Windows

Is this thread something I need to follow closely? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] File system path encoding on Windows

On 30Aug2016 0806, Victor Stinner wrote: 2016-08-30 16:31 GMT+02:00 Steve Dower : It's the random user on Windows who installed their library that has the problem. They don't know the fix, and may not know how to apply it (e.g. if it's their Jupyter notebook that won't

[Python-Dev] Changes to PEP 498 (f-strings)

After a long discussion on python-ideas (starting at https://mail.python.org/pipermail/python-ideas/2016-August/041727.html) I'm proposing the following change to PEP 498: backslashes inside brackets will be disallowed. The point of this is to disallow convoluted code like: >>> d = {'a': 4} >>>

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 17:35:35 + Brett Cannon wrote: > > > > Perhaps a list would work indeed. Realistically, if there are at most > > 2-3 users of the field at any given time (and most probably only one or > > zero), a simple type check (by pointer equality) on each list

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

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

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 10:32 Antoine Pitrou wrote: > On Tue, 30 Aug 2016 17:14:31 + > Brett Cannon wrote: > > > > Depends on what vmprof chooses to do. Since the data is designed to be > > disposable it could decide it should always take precedence and

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 17:14:31 + Brett Cannon wrote: > > Depends on what vmprof chooses to do. Since the data is designed to be > disposable it could decide it should always take precedence and overwrite > the data if someone beat it to using the field. Basically I don't

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 01:20 Maciej Fijalkowski wrote: > On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote: > > > > > > On Mon, Aug 29, 2016, 17:06 Terry Reedy wrote: > >> > >> On 8/29/2016 5:38 PM, Brett Cannon wrote: > >> > >> > who

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 09:08 Antoine Pitrou wrote: > On Mon, 29 Aug 2016 21:38:19 + > Brett Cannon wrote: > > 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

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Mon, 29 Aug 2016 21:38:19 + Brett Cannon wrote: > 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 ( >

Re: [Python-Dev] Supported versions of OpenSSL

On Sun, 28 Aug 2016 22:40:11 +0200 Christian Heimes wrote: > > Here is the deal for 2.7 to 3.5: > > 1) All versions older than 0.9.8 are completely out-of-scope and no > longer supported. > > 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8. >

Re: [Python-Dev] Lib/http/client.py: could it return an OSError with the current response?

If you can do it without breaking existing code that doesn't expect the extra information, please go ahead! For things like this it is typically best to go straight to the bug tracker (bugs.python.org) rather than asking the list first -- if the issue turns out to be controversial or mysterious

[Python-Dev] Lib/http/client.py: could it return an OSError with the current response?

Hi everybody, Sorry for bothering you, this is my first post to the python-dev ML. While using requests to tunnel a request via a proxy requiring user authentication, I have seen that httplib ( https://hg.python.org/cpython/file/3.5/Lib/http/client.py#l831) raises the message returned by the

Re: [Python-Dev] File system path encoding on Windows

2016-08-30 16:31 GMT+02:00 Steve Dower : > It's the > random user on Windows who installed their library that has the problem. > They don't know the fix, and may not know how to apply it (e.g. if it's > their Jupyter notebook that won't find one of their files - no obvious

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On 30.08.16 15:31, Dima Tisnek wrote: On 30 August 2016 at 14:13, Serhiy Storchaka wrote: 1. Detect length change and raise. It would be simpler solution. But I afraid that this can break third-party code that "just works" now. For example slicing a list "just works" if

Re: [Python-Dev] File system path encoding on Windows

As I've said before, on Windows this is a compatibility hack to make code written for other platforms work. Making the user opt in is not fair, and does not help improve the libraries that need it, because few people will change their library to work with a non default option. The "developer"

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On Tue, Aug 30, 2016 at 03:11:25PM +0200, Maciej Fijalkowski wrote: > It's more complicated - if the third party rely on the code working > when one thread slices while the other thread modifies that gives > implicit atomicity requirements. Those specific requirements are very > hard to maintain

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On Tue, Aug 30, 2016 at 2:31 PM, Dima Tisnek wrote: > On 30 August 2016 at 14:13, Serhiy Storchaka wrote: >>> 1. Detect length change and raise. >> >> >> It would be simpler solution. But I afraid that this can break third-party >> code that "just works"

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On 30 August 2016 at 14:13, Serhiy Storchaka wrote: >> 1. Detect length change and raise. > > > It would be simpler solution. But I afraid that this can break third-party > code that "just works" now. For example slicing a list "just works" if step > is 1. It can return not

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On 28.08.16 01:25, Terry Reedy wrote: 0. Do nothing. The problem is not in pathological __index__. The problem is in executing Python code and releasing GIL. In multithread production code one thread can read a slice when other thread modifies a collection. In very very rare case it causes

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On 2016-08-30 01:14, Brett Cannon wrote: > So the struct in question can be found at > https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Include/code.h#L10 > . > The official docs say the fields can be changed at any time, so > re-arranging them shouldn't break any

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On 8/30/2016 4:20 AM, Maciej Fijalkowski wrote: On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote: 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

Re: [Python-Dev] Supported versions of OpenSSL

On 8/29/2016 10:59 PM, Nick Coghlan wrote: By contrast (and assuming I understand the situation correctly), the Windows build is already set up around the assumption that you'll need to build OpenSSL yourself. If one installs a minimal svn client and passes -e to Zack's wonderful built.bat,

Re: [Python-Dev] File system path encoding on Windows

Le 30 août 2016 03:10, "Nick Coghlan" a écrit : > However, this view is also why I don't agree with being aggressive in > making this behaviour the default on Windows - I think we should make > it readily available as a provisional feature through a single > cross-platform

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote: > > > 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

Re: [Python-Dev] Supported versions of OpenSSL

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