Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 10 November 2017 at 16:42, Victor Stinner wrote: > I didn't follow the discussion on the PEP but I was surprised to read "from > __future__ import annotations" in an example. Annotations exist since Python > 3.0, why would Python 3.7 require a future for them? Well, I

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

I didn't follow the discussion on the PEP but I was surprised to read "from __future__ import annotations" in an example. Annotations exist since Python 3.0, why would Python 3.7 require a future for them? Well, I was aware of the PEP, but I was confused anyway. I really prefer "from __future__

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 11/9/2017 9:11 PM, Nick Coghlan wrote: On 10 November 2017 at 05:51, Guido van Rossum wrote: If we have to change the name I'd vote for string_annotations -- "lazy" has too many other connotations (e.g. it might cause people to think it's the thunks). I find

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 10 November 2017 at 14:34, Greg Ewing wrote: > Tres Seaver wrote: >> >> IIUC, that would be as expected: you would see the warnings when running >> your test suite exercising that imported code (which should run with all >> warnings enabled), but not when running

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

Tres Seaver wrote: IIUC, that would be as expected: you would see the warnings when running your test suite exercising that imported code (which should run with all warnings enabled), but not when running the app. But then what benefit is there in turning on deprecation warnings automatically

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

So... Łukasz? On Thu, Nov 9, 2017 at 6:11 PM, Nick Coghlan wrote: > On 10 November 2017 at 05:51, Guido van Rossum wrote: > > If we have to change the name I'd vote for string_annotations -- "lazy" > has > > too many other connotations (e.g. it might cause

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 10 November 2017 at 05:51, Guido van Rossum wrote: > If we have to change the name I'd vote for string_annotations -- "lazy" has > too many other connotations (e.g. it might cause people to think it's the > thunks). I find str_annotations too abbreviated, and

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

On 9 November 2017 at 22:35, Antoine Pitrou wrote: > On Thu, 9 Nov 2017 04:22:20 -0800 > Raymond Hettinger wrote: >> >> Probably, we're the wrong people to be talking about this. The proposal is >> to make these macros part of the official API

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Ethan Furman writes: > Suffering from DeprecationWarnings is not "being hosed". Having > your script/application/framework suddenly stop working because > nobody noticed something was being deprecated is "being hosed". OK, so suffering from DeprecationWarnings is not "being hosed".

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 10 November 2017 at 11:53, Nick Coghlan wrote: > On 10 November 2017 at 11:32, Nathaniel Smith wrote: >> Is this intended to be a description of the current state of affairs? >> Because I've never encountered a test runner that does this... Which runners >>

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 10 November 2017 at 11:32, Nathaniel Smith wrote: > Is this intended to be a description of the current state of affairs? > Because I've never encountered a test runner that does this... Which runners > are you thinking of? Ah, you're right, pytest currently still requires

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On Nov 8, 2017 16:12, "Nick Coghlan" wrote: On 9 November 2017 at 07:46, Antoine Pitrou wrote: > > Le 08/11/2017 à 22:43, Nick Coghlan a écrit : >> >> However, between them, the following two guidelines should provide >> pretty good deprecation warning

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 10 November 2017 at 01:45, Barry Warsaw wrote: > On Nov 9, 2017, at 07:27, Tres Seaver wrote: > >> IIUC, that would be as expected: you would see the warnings when running >> your test suite exercising that imported code (which should run with all >>

Re: [Python-Dev] The current dict is not an "OrderedDict"

On Thu, Nov 9, 2017 at 1:46 PM, Cameron Simpson wrote: > On 08Nov2017 10:28, Antoine Pitrou wrote: >> >> On Wed, 8 Nov 2017 13:07:12 +1000 >> Nick Coghlan wrote: >>> >>> On 8 November 2017 at 07:19, Evpok Padding

Re: [Python-Dev] The current dict is not an "OrderedDict"

On 08Nov2017 10:28, Antoine Pitrou wrote: On Wed, 8 Nov 2017 13:07:12 +1000 Nick Coghlan wrote: On 8 November 2017 at 07:19, Evpok Padding wrote: > On 7 November 2017 at 21:47, Chris Barker wrote: >> if

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

If we have to change the name I'd vote for string_annotations -- "lazy" has too many other connotations (e.g. it might cause people to think it's the thunks). I find str_annotations too abbreviated, and stringify_annotations is too hard to spell. On Thu, Nov 9, 2017 at 11:39 AM, Barry Warsaw

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Nov 8, 2017, at 23:57, Nick Coghlan wrote: > Putting that quibble first: could we adjust the feature flag to be > either "from __future__ import lazy_annotations" or "from __future__ > import str_annotations"? > > Every time I see "from __future__ import annotations" I

Re: [Python-Dev] OrderedDict(kwargs) optimization?

Got it. Thanks! On Wednesday, November 8, 2017, INADA Naoki wrote: > > That'd be great for preserving kwargs' order after a pop() or a del? > > To clarify, order is preserved after pop in Python 3.6 (and maybe 3.7). > > There is discussion about breaking it to optimize

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On Nov 9, 2017, at 07:27, Tres Seaver wrote: > IIUC, that would be as expected: you would see the warnings when running > your test suite exercising that imported code (which should run with all > warnings enabled), but not when running the app. > > Seems like a

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 11/09/2017 01:49 AM, Greg Ewing wrote: >> On 8 November 2017 at 19:21, Antoine Pitrou wrote: >>> The idea that __main__ scripts should >>> get special treatment here is entirely gratuitous. > > When I'm writing an app in Python, very often my __main__ is > just a stub

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

09.11.17 14:22, Raymond Hettinger пише: Stylistically, all of these seem awkward and I think there is more to it than just the name. I'm not sure it is wise to pass complex inputs into a two-argument macro that makes an assignment and has a conditional refcount side-effect. Even now, one of

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

Hum, to give more context to the discussion, the two discussed macros are documented this way: #ifndef Py_LIMITED_API /* Safely decref `op` and set `op` to `op2`. * * As in case of Py_CLEAR "the obvious" code can be deadly: * * Py_DECREF(op); * op = op2; * * The safe way is: * *

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

On Thu, 9 Nov 2017 04:22:20 -0800 Raymond Hettinger wrote: > > Probably, we're the wrong people to be talking about this. The proposal is > to make these macros part of the official API so that it starts to appear in > source code everywhere. The question isn't

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

> On Nov 9, 2017, at 2:44 AM, Serhiy Storchaka wrote: > > If the problem is with naming, what names do you prefer? This already was > bikeshedded (I insisted on discussing names before introducing the macros), > but may now you have better ideas? It didn't really seem

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

2017-11-09 3:08 GMT+01:00 Raymond Hettinger : > I greatly prefer putting all the decrefs at the end to increase my confidence > that it is okay to run other code that might reenter the current code. There are 3 patterns to update C attributes of an object: (1)

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

Recently, Oren Milman fixed multiple bugs when an __init__() method was called twice. IMHO Py_SETREF() was nicely used in __init__(): https://github.com/python/cpython/commit/e56ab746a965277ffcc4396d8a0902b6e072d049

Re: [Python-Dev] Clarifying Cygwin support in CPython

On Wed, Nov 8, 2017 at 5:28 PM, Zachary Ware wrote: > On Wed, Nov 8, 2017 at 8:39 AM, Erik Bray wrote: >> a platform--in particular it's not clear when a buildbot is considered >> "stable", or how to achieve that without getting necessary

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

09.11.17 04:08, Raymond Hettinger пише: On Nov 8, 2017, at 8:30 AM, Serhiy Storchaka wrote: Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all maintained versions ([1] and [2]). Despite their names they are private. I think that they are

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

Guido van Rossum wrote: I did not assume totally opaque -- but code objects are not very introspection friendly (and they have no strong compatibility guarantees). If I understand the proposal correctly, there wouldn't be any point in trying to introspect the lambdas/thunks/whatever. They're

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 8 November 2017 at 19:21, Antoine Pitrou wrote: The idea that __main__ scripts should get special treatment here is entirely gratuitous. When I'm writing an app in Python, very often my __main__ is just a stub that imports the actual functionality from another module

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

On 9 November 2017 at 02:17, Barry Warsaw wrote: > I suppose there are lots of ways to do this, but at least I’m pretty sure we > all agree that end users shouldn’t see DeprecationWarnings, while developers > should. Agreed. Most of the debate to me seems to be around who is

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

TL;DR version: I'm now +1 on a string-based PEP 563, with one relatively small quibble regarding the future flag's name. Putting that quibble first: could we adjust the feature flag to be either "from __future__ import lazy_annotations" or "from __future__ import str_annotations"? Every time I