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 was aware of
> the PEP, bu
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__ im
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 str_annotations too abbreviated,
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 the app.
>
> But then what ben
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
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 people to think it's the
> > thunks).
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 stringify_annotations
> is too hard
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 so that it starts to appear in
>> source code ever
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".
Neverthele
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
>> are you thinking of?
>
> Ah, you're
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 individual
developer
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 coverage for the world's Python code:
>>
>>
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
>> warnings enabled), but not when running th
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
>>> wrote:
>>> > On 7 November 2017 at 21:47, Chris Barker
>>> > wrote:
>>> >> if
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 dict order is preserved in cPython , people WILL count on it!
>
> I won't, and if people
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 wrot
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 think "But
> we've had
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 for limited use cases,
> b
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 reasonable choice to me.
I’m co
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 that imports the actual f
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 t
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:
*
*
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 whether the above makes sense t
> 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 like a bad idea until af
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)
Py_XDECREF(obj->attr); // can call
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
https://github.com/python/cpython/commit/c0cabc23bbe474d542ff8a4f1243f4ec3cce5549
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 fixes
>> merged into the main branch in the first place.
>
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 enough stable now and would
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 on
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 to get the benefits of
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 an end user
and who
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 se
32 matches
Mail list logo
