Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

On 03/03/2014 01:38 PM, Nick Coghlan wrote: Related question - have you decided yet whether or not to do an rc3? I ask, as I believe it would be good to give the folks like Mike Bayer and Armin Ronacher (who picked up test coverage gaps in rc2 via the Alembic and Flask test suites respectively

Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

On 03/03/2014 07:58 PM, Nick Coghlan wrote: All of our development guides for testing against trunk are designed around running from a Mercurial checkout - it would *really* be whole lot easier for everyone else that is trying to test the release if you could just do a push from your release clon

Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

On 03/03/2014 10:23 PM, Nick Coghlan wrote: But at the moment you're making it *hard* for people to test the release, How? How is testing against a tarball fundamentally different from testing against an hg-cloned repository? I'm really not buying this. //arry/ __

Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

On 03/04/2014 03:59 PM, Barry Warsaw wrote: I too would like an rc3, especially to see if issue 19021 can be fixed, which I suspect will hit a lot of people. I talked to the other guys on the 3.4 team, and we're all willing to do an rc3 this weekend. I'll add that to PEP 429. In other news

[Python-Dev] First attempt at Python 3.4.0rc3 is up

It's published here: http://hg.python.org/releasing/3.4/ There's also a tarball at the old web site: http://midwinter.com/~larry/3.4.status/ However, the "merge.status.html" page is broken. I'm not going to bother to fix it, instead please just look at the hg repo above. I think

Re: [Python-Dev] First attempt at Python 3.4.0rc3 is up

On 03/07/2014 03:14 AM, Nick Coghlan wrote: On 7 March 2014 21:00, Larry Hastings wrote: It's published here: http://hg.python.org/releasing/3.4/ Thanks for that Larry - commits and NEWS for the pip bundling, pkgutil and inspect changes all look good to me :) It's been an anxio

[Python-Dev] [RELEASED] Python 3.4.0 release candidate 3

ill be added. The final release is projected for March 16, 2014. To download Python 3.4.0rc3 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0rc3 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! **

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

On 03/10/2014 08:59 AM, Barry Warsaw wrote: On Mar 10, 2014, at 04:25 PM, Stefan Richthofer wrote: I don't see any reason to bump the major version number until after Python 3.9. Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. Guido famously hates two digit minor versio

[Python-Dev] Any non-3.4.0 docs in "default"?

I'm strongly considering literally copying over all the content in Doc/ from the default branch to the 3.4 branch. Not cherry-picking doc changes, simply copying everything en masse. I have two questions for the core devs. 1) Sound good? 2) Do you know of anything in Doc/ that shouldn't

[Python-Dev] [RELEASED] Python 3.4.0

ved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O To download Python 3.4.0 visit: http://www.python.org/download/releases/3.4.0/ This is a production release. Please report any issues you notice to: http://bugs.python

[Python-Dev] default hg.python.org/cpython is now 3.5

The "3.4" branch is now checked in. It contains all the 3.4 releases since 3.4.0rc1. Its current state is effectively 3.4.1. The "default" branch is now 3.5. Cry havoc, and let slip the dogs of war, //arry/ ___ Python-Dev mailing list Python-De

Re: [Python-Dev] [python-committers] default hg.python.org/cpython is now 3.5

On 03/17/2014 04:23 PM, Nick Coghlan wrote: On 18 Mar 2014 07:37, "Victor Stinner" > wrote: > > Hi, > > I modified the Misc/NEWS file: > > * I moved 3.3 sections to Misc/HISTORY: items were already present, > but the format in Misc/NEWS was improved (changeset

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

On 03/18/2014 12:05 PM, Georg Brandl wrote: Am 18.03.2014 19:29, schrieb Serhiy Storchaka: 26.02.14 11:40, Serhiy Storchaka написав(ла): Let's choose the least confusing names. See discussions at: http://bugs.python.org/issue3081 http://bugs.python.org/issue16447 http://bugs.python.org/issue2

Re: [Python-Dev] Making proxy types easier to write and maintain

On 03/19/2014 08:49 PM, Nick Coghlan wrote: I had vague plans to bug Graham (yay, spelling!) about proposing wrapt for inclusion in 3.5 (possibly split between functools and types rather than as a completely new module, though). I pinged him about it for 3.4. He didn't have the time for i

Re: [Python-Dev] Making proxy types easier to write and maintain

On 03/20/2014 12:49 AM, Nick Coghlan wrote: So long as Graham's willing to go along with it, he doesn't have to to be the one to write the PEP. PEP? Why does it need a PEP? I didn't think it'd even be a new top-level library module, it'd be an addition / additions to functools. //arry/ ___

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On 04/07/2014 02:47 PM, Alexander Belopolsky wrote: On Mon, Apr 7, 2014 at 5:03 PM, Nathaniel Smith > wrote: > It would be nice to support A × B too, because it's much more > readable. You can configure a keyword to write arbitrary characters. > For example,

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On 04/07/2014 03:16 PM, Alexander Belopolsky wrote: On Mon, Apr 7, 2014 at 5:58 PM, Larry Hastings <mailto:la...@hastings.org>> wrote: I am -1**3001 on adding redundant non-ASCII operators to the language. >>> -1**3001 -1 :-) http://www.qu

Re: [Python-Dev] issue with itertools leads the crash

On 04/08/2014 12:50 PM, Chris Angelico wrote: It would be nice to have a simple notation that fetches what it needs and ignores any extras. a, b, c, * = x.split("-") Bomb if there aren't two hyphens in x, but if there are more, just take the first three and ignore the rest. Would work with inf

[Python-Dev] [RELEASED] Python 3.4.1rc1

On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.1rc1. Python 3.4.1rc1 has over three hundred bugfixes and other improvements over 3.4.0. One notable change: the version of OpenSSL bundled with the Windows

Re: [Python-Dev] Merge conflicts from unmerged 3.4 commits, what do I do?

On 05/18/2014 10:31 PM, Raymond Hettinger wrote: On May 19, 2014, at 5:52 AM, Terry Reedy <mailto:tjre...@udel.edu>> wrote: I stopped at this point and ran diskcheck. I then looked at the DAG and noticed 5 previous 3.4 patches that were not merged into 3.5: rev 90750 and 907

[Python-Dev] [RELEASED] Python 3.4.1

On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.1. Python 3.4.1 has over three hundred bugfixes and other improvements over 3.4.0. One notable change: the version of OpenSSL bundled with the Windows instal

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On 06/10/2014 03:05 PM, "Martin v. Löwis" wrote: We certainly don't need to resolve this now. We should discuss it again when the release schedule for 3.5 is proposed. I anticipate 3.5 should be released about 18 months after the release of 3.4, putting it mid-September 2015. //arry/ __

[Python-Dev] Time for 3.4.9 and 3.5.6

My six-month cadence means it's time for the next releases of 3.4 and 3.5.  There haven't been many changes since the last releases--two, to be exact.  These two security fixes were backported to both 3.4 and 3.5: * bpo-32981: Fix catastrophic backtracking vulns (GH-5955) * bpo-33001: Prev

Re: [Python-Dev] Time for 3.4.9 and 3.5.6

On 07/08/2018 10:05 AM, Ivan Pozdeev via Python-Dev wrote: I'll use this opportunity to remind you that 3.4 build is broken -- it can't be built from start to installer with the instructions given because of outside factors (CPython has migrated from Hg to Git). https://bugs.python.org/issu

Re: [Python-Dev] [python-committers] Time for 3.4.9 and 3.5.6

On 07/08/2018 11:50 AM, Ned Deily wrote: On Jul 8, 2018, at 14:23, Julien Palard via Python-Dev wrote: [Larry] 3.5 also got some doc-only changes related to the online "version switcher" dropdown. About this I have a question: the switchers for english version of 3.4 and 3.5 are disabled (

[Python-Dev] 3.4.9rc1 and 3.5.6rc1 slipping by one day to Thursday July 19 2018

I was working with Serhiy on fixing the documentation for some bytecodes in 3.5 (GH-8338) and time got away from me.  They'll both be out later today, Thursday July 19 2018. *yawn,* //arry/ ___ Python-Dev mailing list Python-Dev@python.org https:

[Python-Dev] [RELEASED] Python 3.4.9rc1 and Python 3.5.6rc1 are now available

On behalf of the Python development community, I'm pleased to announce the availability of Python 3.4.9rc1 and Python 3.5.6rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode.  Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only.

[Python-Dev] [RELEASED] Python 3.4.9 and Python 3.5.6 are now available

On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.9 and Python 3.5.6. Both Python 3.4 and 3.5 are in "security fixes only" mode.  Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.4.9 and Python 3.5.6 are now available

On 08/02/2018 07:17 AM, Victor Stinner wrote: 3.4.9 and 3.5.6 have no more known security vulnerabilities :-) Well, not to be a complete pill, but... https://bugs.python.org/issue17180 https://bugs.python.org/issue17239 https://bugs.python.org/issue19050 Sadly, just because they're

Re: [Python-Dev] Error message for wrong number of arguments

On 08/01/2018 02:40 PM, Armin Rigo wrote: I think that argument clinic knows if the built-in function is supposed to be a method or a function. Yes, Argument Clinic knows.  Clinic's "Function" instances have a "cls" member, and if that's set to a Clinic "Class" instance--and it's not one of

[Python-Dev] Winding down 3.4

We of the core dev community commit to supporting Python releases for five years.  Releases get eighteen months of active bug fixes, followed by three and a half years of security fixes.  Python 3.4 turns 5 next March--at which point we'll stop supporting it, and I'll retire as 3.4 release m

Re: [Python-Dev] [python-committers] Winding down 3.4

If they're really all wontfix, maybe we should mark them as wontfix, thus giving 3.4 a sendoff worthy of its heroic stature. Godspeed, and may a flight of angels sing thee to thy rest, //arry/ On 08/20/2018 05:52 AM, Victor Stinner wrote: > "shutil copy* unsafe on POSIX - they preserve set

Re: [Python-Dev] bpo-34595: How to format a type name?

On 09/13/2018 07:01 AM, Eric V. Smith wrote: On 9/12/2018 8:33 PM, Victor Stinner wrote: Hi, For the type name, sometimes, we only get a type (not an instance), and we want to format its FQN. IMHO we need to provide ways to format the FQN of a type for *types* and for *instances*. Here is my

[Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

What follows is the text of issue 34690: https://bugs.python.org/issue34690 The PR is here: https://github.com/python/cpython/pull/9320 I don't know if we should be discussing this here on python-dev, or on bpo, or on Zulip, or on the soon-to-be-created Discourse. But maybe we can ta

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

On 09/14/2018 02:54 PM, Neil Schemenauer wrote: On 2018-09-14, Larry Hastings wrote: [...] improvement 0.21242667903482038 % I assume that should be 21.2 % othewise I recommend you abandon the idea. ;-P Yeah, that thing you said. I wonder how much of the speedup relies on putting it in

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

On 09/19/2018 03:08 PM, Terry Reedy wrote: If Python usually used derived stdlib code, but could optionally use the original .py files via a command-line switch, experimenting with changes to .py files would be easier. When Carl described the patch to me, he said there was already a switch

Re: [Python-Dev] C API changes

On 11/23/18 5:15 AM, Armin Rigo wrote: Also FWIW, my own 2 cents on the topic of changing the C API: let's entirely drop ``PyObject *`` and instead use more opaque handles---like a ``PyHandle`` that is defined as a pointer-sized C type but is not actually directly a pointer. The main difference

Re: [Python-Dev] Lost sight

You have been a marvel, and an enormous boon to the Python community.  You should not feel bad about anything.  Best wishes to you for your future endeavors! //arry/ On 1/21/19 7:26 AM, Serhiy Storchaka wrote: Thank you very match, all who have expressed compassion here and privately. I am

[Python-Dev] Proposed dates for Python 3.4.10 and Python 3.5.7

Howdy howdy!  It's time to make the next bugfix release of 3.5--and the /final/ release /ever/ of Python 3.4. Here's the schedule I propose: 3.4.10rc1 and 3.5.7rc1 - Saturday March 2 2019 3.4.10 final and 3.5.7 final - Saturday March 16 2019 What's going in these releases?  Not much. 

Re: [Python-Dev] before I open an issue re: posix.stat and/or os.stat

On 2/21/19 2:26 AM, Michael wrote: Will this continue to be enough space - i.e., is the Dev size going to be enough?  +2042  #ifdef MS_WINDOWS  +2043  PyStructSequence_SET_ITEM(v, 2, PyLong_FromUnsignedLong(st->st_dev));  +2044  #else  +2045  PyStructSequence_SET_ITEM(v, 2, _PyLong_

Re: [Python-Dev] Proposed dates for Python 3.4.10 and Python 3.5.7

My thanks to Miro and (especially!) Victor for quickly putting together those lovely PRs.  I've now merged everything outstanding for 3.4 and 3.5 except this: https://github.com/python/cpython/pull/10994 It's a backport of LibreSSL 2.7.0 support for 3.5.  This is something I believe Chri

[Python-Dev] Last-minute request: please backport bpo-33329 fix to 3.4 and 3.5

This bug in bpo-33329: https://bugs.python.org/issue33329 was fixed for 3.6+, but it also affects 3.4 and 3.5.  The bug is that with newer versions of glibc--which I'm pretty sure has shipped on all major Linux distros by now--the test suite may send signals that are invalid somehow.  As

[Python-Dev] [RELEASED] Python 3.4.10rc1 and Python 3.5.7rc1 are now available

On behalf of the Python development community, I'm chuffed to announce the availability of Python 3.4.10rc1 and Python 3.5.7rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode.  Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only

Re: [Python-Dev] Last-minute request: please backport bpo-33329 fix to 3.4 and 3.5

On 3/4/19 2:29 AM, Joni Orponen wrote: On Sat, Mar 2, 2019 at 7:08 AM Larry Hastings <mailto:la...@hastings.org>> wrote: This bug in bpo-33329: https://bugs.python.org/issue33329 This is also potentially affecting PGO builds of 2.7 on Debian Buster with GCC. Somehow

[Python-Dev] Python 3.5.7 is now available

On behalf of the Python development community, I'm chuffed to announce the availability of Python 3.5.7. Python 3.5 is in "security fixes only" mode.  It only accepts security fixes, not conventional bug fixes, and the release is source-only. And you can find Python 3.5.7rc1 here: https

[Python-Dev] Python 3.4.10 is now available

On behalf of the Python development community, I'm proud--if slightly sad--to announce the availability of Python 3.4.10. Python 3.4.10 was released in "security fixes only" mode.  It only contains security fixes, not conventional bug fixes, and it is a source-only release. Python 3.4.10 i

Re: [Python-Dev] Easier debugging with f-strings

lt behavior is the most common case at every step. "So, is it checked in?" --GvR, //arry/ On 5/6/19 8:39 PM, Eric V. Smith wrote: Last fall Larry Hastings made a suggestion for adding a way to make so-called "print-based debugging" easier with f-strings. Basically the ap

[Python-Dev] Farewell, Python 3.4

It's with a note of sadness that I announce the final retirement of Python 3.4.  The final release was back in March, but I didn't get around to actually closing and deleting the 3.4 branch until this morning. Python 3.4 introduced many features we all enjoy in modern Python--the asyncio, en

Re: [Python-Dev] Have a big machine and spare time? Here's a possible Python bug.

On 5/22/19 12:15 PM, Tim Peters wrote: There's a Stackoverflow report[1] I suspect is worth looking into, but it requires far more RAM (over 80GB) than I have). [...] But, for a start, it would be good to know if anyone else can actually reproduce the problem. [1] https://stackoverflow.com/ques

[Python-Dev] Re: PEP 640: Unused variable syntax.

On 10/20/20 10:45 PM, Paul Sokolovsky wrote: One problem with this PEP, which I didn't see mentioned in the other replies, is that it tries to grab "?" character, which is already sought-for by another pending PEP: "PEP 505 -- None-aware operators", https://www.python.org/dev/peps/pep-0505/ .

[Python-Dev] Re: Speeding up CPython

On 10/21/20 4:04 AM, Antoine Pitrou wrote: (apart from small fixes relating to borrowed references, and that's mostly to make PyPy's life easier). Speaking as the Gilectomy guy: borrowed references are evil.  The definition of the valid lifetime of a borrowed reference doesn't exist, because

[Python-Dev] Re: Speeding up CPython

On 10/21/20 5:58 AM, Petr Viktorin wrote: At the risk of going off topic: That's for GCC. As far as I know, MSVC uses something like __declspec( thread ). What are the options for generic C99 compilers, other than staying slow? As a practical matter: does CPython even support "generic C99 co

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

I think Python's rules about what constitutes a new scope are a touch inconsistent--or, as the Zen might put it, "practical". First, simple statements never create their own scope.  That's easy.  Second, compound statements that create a new function, "def" and "lambda", always create a new

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On 11/23/20 8:15 AM, Brian Coleman wrote: def process(root_node: Node): def process_node(node: Node): if isinstance(node, StringNode): return node.value elif isinstance(node, NumberNode): return float(node.value) elif isinstance(node, Lis

[Python-Dev] Re: Thanks for the Dev Guide

The dev guide is a community project, like all of Python.  But IIRC the person who drove it and did I think most of the heavy lifting on it was Brett Cannon. And yes, it /is/ excellent, isn't it :D //arry/ On 11/26/20 11:28 AM, Richard Levasseur wrote: Hi everyone, I just wanted to expre

[Python-Dev] Re: NEWS, changelog, and blurb -- a teaching moment

On 12/9/20 11:19 AM, Ethan Furman wrote: Greetings! I'm hoping somebody can alleviate my confusion.  I had thought that the blurb tool was created to resolve the near-constant push races when the NEWS file was updated; but it appears that it only affects the change log. NEWS /is/ the chang

[Python-Dev] Re: NEWS, changelog, and blurb -- a teaching moment

On 12/9/20 5:21 PM, Ethan Furman wrote: On 12/9/20 5:01 PM, Larry Hastings wrote: > "Misc/NEWS" is no longer checked in, it's generated on demand using "blurb merge". So if I understand correctly, blurb makes NEWS, but `whatsnew` is still done by hand. Corre

[Python-Dev] Let's Fix Class Annotations -- And Maybe Annotations Generally

Howdy howdy.  While working on my PEP I stumbled over a lot of behavior by annotations that I found inconsistent and inconvenient.  I think there are several problems here that needs fixing.  This discussion will probably evolve into a PEP, and I'll be happy to steer that process.  But I'm less

[Python-Dev] PEP: Deferred Evaluation Of Annotations Using Descriptors

I've written a new PEP.  Please find it below.  Happy reading! //arry/ -- PEP: Title: Deferred Evaluation Of Annotations Using Descriptors Version: $Revision$ Last-Modified: $Date$ Author: Larry Hastings Discussions-To: Python-Dev Status: Draft Type: Standards Track Co

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

it was gonna be on tomorrow's midterms. //arry/ On 1/11/21 9:59 AM, Chris Angelico wrote: On Tue, Jan 12, 2021 at 4:22 AM Larry Hastings wrote: I've written a new PEP. Please find it below. Happy reading! Can this get added to the PEPs repo and assigned a number and such? BTW, the c

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 10:16 AM, Chris Angelico wrote: Number allocation is pretty informal. Go ahead and grab PEP 649; It's now checked in as PEP 649, with a modern header, modern copyright, and I went ahead and grabbed the formatting stanza from the end too. Welcome to the world, baby 649! //arry/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 10:29 AM, Barry Warsaw wrote: Given that PEP 563 is now the default in unreleased Python 3.10, does it make sense to introduce yet another __future__ import? What would happen if you just piggybacked your idea onto that change? Part of my proposal is to deprecate PEP 563's semant

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

Thanks for your feedback!  I'll reply piecemeal. On 1/11/21 12:32 PM, Paul Bryan wrote: *1. Backwards Compatibility* PEP 563 changed the semantics of annotations. When its semantics are active, annotations must assume they will be evaluated in /mod

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

The control-flow exclusion is for /module//attribute/ or /class attribute/ annotations: class C:   if random.random() > 0.5:     my_attr:int=3   else:     my_attr2:float=3.5 Your example doesn't define any module attributes or class attributes inside flow control statement

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 1:16 PM, Larry Hastings wrote: On 1/11/21 12:32 PM, Paul Bryan wrote: *1. Backwards Compatibility* PEP 563 <https://www.python.org/dev/peps/pep-0563> changed the semantics of annotations. When its semantics are active, annotations must assume they will be evaluated in /

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 3:02 PM, Paul Bryan wrote: PEP 563 does go on to state: For code which uses annotations for other purposes, a regular eval(ann, globals, locals) call is enough to resolve the annotation. And I believe this would no longer be true under PEP 649; further, localns (and maybe globalns

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

At last, a nibble on the other fishing line! ;-) On 1/11/21 1:47 PM, Brett Cannon wrote: So the biggest potential breakages are code that: 1. Directly get the attribute from __dict__ 2. The fact that it would no longer be inherited Am I missing anything else? Those are the big ones, the

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 2:32 PM, Łukasz Langa wrote: 1. What do you anticipate the memory usage will look like for your solution compared to PEP 563? It depends on the scenario.  I talk about three runtime scenarios in PEP 649.  But the most relevant scenario is "annotations are defined but never examine

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 4:39 PM, Guido van Rossum wrote: The easiest thing would be just to create an empty `__annotations__` for classes that have no annotated variables, and to hell with the cost. I assume you'd keep the existing behavior where functions lazy-create an empty dict if they have no annotat

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 4:55 PM, Greg Ewing wrote: On 12/01/21 6:21 am, Larry Hastings wrote: Unbound code objects ...The "annotation code object" is then stored *unbound* as the internal value of ``__co_annotations__``; it is then bound on demand when the use

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 5:28 PM, Guido van Rossum wrote: On Mon, Jan 11, 2021 at 5:21 PM Larry Hastings <mailto:la...@hastings.org>> wrote: Slots intelligently support inheritance, too.  I always kind of wondered why annotations didn't support inheritance--if D is a subclass of C,

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 5:05 PM, Greg Ewing wrote: On 12/01/21 6:22 am, Larry Hastings wrote:  * The language will set __annotations__ to a dict if the object has    annotations, or None if it has no annotations. That sounds inconvenient -- it means that any code referencing __annotations__ has to guard

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 5:02 PM, Paul Bryan wrote: Some more questions... "Binding"," bound" and "unbound" code objects: Is your use of "binding" terminology in the PEP identical to the binding of a function to an object instance as a method during object creation? I'm not.  In PEP 649 I think every ref

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 6:09 PM, Chris Angelico wrote: On Tue, Jan 12, 2021 at 12:56 PM Larry Hastings wrote: It was a balancing act. Using an 64-byte empty dict per object with no defined annotations seems so wasteful. And anything short of an empty dict, you'd have to guard against. Current

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 6:31 PM, Greg Ewing wrote: On 12/01/21 2:21 pm, Larry Hastings wrote: Slots intelligently support inheritance, too. Are you sure about that? My experiments suggest that it has the same problem as __annotations__: Python 3.8.2 (default, Mar 23 2020, 11:36:18) [Clang 8.1.0 (clang

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 6:29 PM, Greg Ewing wrote: On 12/01/21 10:41 am, Larry Hastings wrote: So: if you're using annotations for something besides "type hints", Didn't Guido decree that using annotations for anything other than type hints is no longer supported? It was neve

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 6:34 PM, Paul Bryan wrote: a.__annotations__ = o assert a.__annotations__ == o Would that assert fail?  It depends on what type(o) is, which is surprising. Equally surprising?: a.__co_annotations__ = o a.__annotations__ assert a.__co_annotations__ == o Well, since you asked

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 5:37 PM, Larry Hastings wrote: I'll have to let people with large code bases speak up about this, but my understanding is that most people would prefer Python to use less memory.  On my 64-bit Linux machine, a code object is 136 bytes, its empty __dict__ is 64 bytes, [...]

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 5:33 PM, Inada Naoki wrote: Note that PEP 563 semantics allows more efficient implementation. Annotation is just a single constant tuple, not a dict. We already have the efficient implementation for Python 3.10. The efficient implementation in 3.10 can share tuples. If there are hund

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

Yes, PEP 649 is completely agnostic about what values you put in as annotations.  You can put in strings, complex objects, expressions--whatever you put in, you get back out later. I'm happy to add some text to the PEP if this needs clarifying; I just thought it was obvious. Cheers, //a

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/12/21 8:47 AM, Larry Hastings wrote: It seems possible to create a hybrid of these two approaches! Here's my idea: instead of the compiler storing a code object as the annotations argument to MAKE_FUNCTION, store a tuple containing the fields you'd need to /recreate/ the code

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/12/21 11:26 AM, Jim J. Jewett wrote: If I understand correctly, the problem is that you can't store multiple alternative annotations on my_attr. Therefore: class C: my_attr:(int if random.random > 0.5 else float) should be OK, because there is only a single annotation. S

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/12/21 12:16 PM, Paul Bryan wrote: On Tue, 2021-01-12 at 09:54 -0800, Larry Hastings wrote: Note that this only works in the current version of the PEP / prototype, where annotations are strictly evaluated in module scope.  If we start supporting closures, those need "cell&quo

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/12/21 3:53 PM, Greg Ewing wrote: On 13/01/21 5:47 am, Larry Hastings wrote: instead of the compiler storing a code object as the annotations argument to MAKE_FUNCTION, store a tuple containing the fields you'd need to /recreate/ the code object at runtime--bytecode, lnotab,

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/12/21 5:28 PM, Brett Cannon wrote: The other thing to keep in mind is we are talking about every module, class, and function getting 64 bytes ... which I bet isn't that much. Actually it's only every module and class.  Functions don't have this problem because they've always stored __ann

[Python-Dev] Re: 3.10 change (?) for __bool__

On 1/12/21 11:27 PM, Chris Angelico wrote: The language can also be defined in an optimization-friendly way, though. Consider how we got positional-only arguments in Python: first they existed in C-implemented functions in CPython, even though they couldn't exist in pure Python code, and then th

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/11/21 6:34 PM, Paul Bryan wrote: On Mon, 2021-01-11 at 17:56 -0800, Larry Hastings wrote: On 1/11/21 5:02 PM, Paul Bryan wrote: I'm probably naive, but is there a reason that one could not just store a callable in __annotations__, and use the descriptor to resolve it to a dicti

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

Sorry it took me 3+ days to reply--I had a lot to think about here.  But I have good things to report! On 1/11/21 8:42 PM, Guido van Rossum wrote: On Mon, Jan 11, 2021 at 1:20 PM Larry Hastings <mailto:la...@hastings.org>> wrote: PEP 563 states: For code that uses t

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/15/21 10:12 AM, Paul Bryan wrote: I wonder if then the __co_annotations__ call and overwriting of __annotations__ should be explicitly caused by a to get_type_hints instead of (mysteriously) occurring on an attempt to getattr __annotations__. I would say: absolutely not.  While all "ty

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/15/21 3:29 PM, Greg Ewing wrote: On 16/01/21 7:56 am, Larry Hastings wrote: As mentioned previously in this thread, typing.get_type_hints() is opinionated in ways that users of annotations may not want. This brings us back to my idea of introducing a new annotations() function to hide

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/16/21 8:41 AM, Nick Coghlan wrote: Could you get the best of both worlds by making __annotations__ an auto-populating descriptor on "type", the way it is on functions? Continue to add a non-empty annotations dict to the class dict eagerly, but only add the empty dict when "cls.__annotati

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

1/15/21 12:38 PM, Guido van Rossum wrote: On Fri, Jan 15, 2021 at 10:53 AM Larry Hastings <mailto:la...@hastings.org>> wrote: Sorry it took me 3+ days to reply--I had a lot to think about here.  But I have good things to report! On 1/11/21 8:42 PM, Guido van Rossum wrot

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/16/21 4:09 PM, Greg Ewing wrote: On 17/01/21 12:31 pm, Larry Hastings wrote: Consider the best practice for getting class annotations, example here from Lib/dataclasses.py:     cls_annotations = cls.__dict__.get('__annotations__', {}) Isn't that going to get broken a

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

If you never examine __annotations__, then you can refer to symbols that are never defined and nothing bad happens.  It's just like writing a function that refers to undefined symbols, then never calling that function. If you examine __annotations__, and the annotations refer to values that

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/18/21 12:24 PM, Guido van Rossum wrote: On Sun, Jan 17, 2021 at 7:33 AM Larry Hastings <mailto:la...@hastings.org>> wrote: If your imports are complicated, you could always hide them in a function.  I just tried this and it seems to work fine: def m

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 12:16 PM, Guido van Rossum wrote: I do worry about the best practice getting worse if your PEP 649 is accepted. A good part of what motivated me to start this second thread ("Let's Fix ...") was how much worse best practice would become if PEP 649 is accepted.  But if we accept P

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On 1/18/21 3:42 PM, Inada Naoki wrote: Many type hinting use cases don't need type objects in runtime. So I think PEP 563 is better for type hinting user experience. You mean, in situations where the user doesn't want to import the types, because of heavyweight imports or circular imports? 

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 2:39 PM, Guido van Rossum wrote: Hm. It's unfortunate that this would break code using what is *currently* the best practice. I can't figure out how to avoid it.  The problem is, current best practice sidesteps the class and goes straight to the dict.  How do we intercept that and

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

After working on it and stressing out about it for some months, I decided to take a break and scratch some other itches.  I'll return to PEP 649 soon, and I have every intention of having the PEP done and the prototype done well in advance of 3.10b1--worry not. Thanks for checking in, //ar

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

I missed the discussion around the PEP.  I don't mean to start another one, I'd just like a clarification.  The PEP describes the new functionality, and the interfaces, and that's all fine.  But I didn't see where it discussed where this technology would be used. Would this mainly be used by

<    1   2   3   4   5   6   7   8   9   >