Re: [Python-Dev] The untuned tunable parameter ARENA_SIZE

2017-06-02 Thread Larry Hastings
On 06/02/2017 02:46 AM, Victor Stinner wrote: I would be curious of another test: use pymalloc for objects larger than 512 bytes. For example, allocate up to 4 KB? In the past, we already changed the maximum size from 256 to 512 to support most common Python objects on 64-bit platforms. Since

Re: [Python-Dev] The untuned tunable parameter ARENA_SIZE

2017-06-02 Thread Larry Hastings
On 06/02/2017 12:09 PM, Tim Peters wrote: I should note that Py_ADDRESS_IN_RANGE is my code - this isn't a backhanded swipe at someone else. One minor note. During the development of 3.6, CPython started permitting some C99-isms, including static inline functions. Py_ADDRESS_IN_RANGE was th

Re: [Python-Dev] The untuned tunable parameter ARENA_SIZE

2017-06-02 Thread Larry Hastings
On 06/02/2017 02:38 AM, Antoine Pitrou wrote: I hope those are not the actual numbers you're intending to use ;-) I still think that allocating more than 1 or 2MB at once would be foolish. Remember this is data that's going to be carved up into (tens of) thousands of small objects. Large objec

Re: [Python-Dev] The untuned tunable parameter ARENA_SIZE

2017-06-05 Thread Larry Hastings
On 06/04/2017 01:18 PM, Tim Peters wrote: [Larry Hastings ] ... Yet CPython's memory consumption continues to grow. By the time a current "trunk" build of CPython reaches the REPL prompt it's already allocated 16 arenas. I'd be surprised if that's true ;-) T

[Python-Dev] Proposed release schedule for Python 3.5.4

2017-06-21 Thread Larry Hastings
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 d

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

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

2017-06-23 Thread Larry Hastings
On 06/23/2017 01:55 AM, Victor Stinner wrote: Larry: would you be ok to turn this protection off on the 3.4 branch? Or would you feel more confortable if only a few people would be allowed to push to the 3.4 branch, so add me a whitelist group or something like that? Actually I kind of like the

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

2017-06-23 Thread Larry Hastings
On 06/21/2017 07:58 PM, Larry Hastings wrote: 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 th

[Python-Dev] New workflow change: Welcome to blurb

2017-06-23 Thread Larry Hastings
One minor but ongoing problem we've had in CPython core development has been the mess of updating Misc/NEWS. Day-to-day developers may have a conflict if they lose a push race, which means a little editing. You'll have a similar, if slightly worse, problem when cherry-picking a fix between

Re: [Python-Dev] New workflow change: Welcome to blurb

2017-06-24 Thread Larry Hastings
On 06/24/2017 01:53 AM, Antoine Pitrou wrote: Would you like to make it 3.5-compatible? 3.6 is quite young and not all systems have it (e.g. Ubuntu 16.04, which many people use, has 3.5). Well, tbh I think that's a bit silly. First of all, it shouldn't be installed in your system-wide python

Re: [Python-Dev] New workflow change: Welcome to blurb

2017-06-24 Thread Larry Hastings
On 06/23/2017 10:55 PM, Nick Coghlan wrote: Aye, towncrier and OpenStack's reno were the two main alternatives we looked at in addition to Larry's offer of creating a tool specifically for CPython: https://github.com/python/core-workflow/issues/6 Fun fact: all three tools started at about the s

Re: [Python-Dev] [python-committers] New workflow change: Welcome to blurb

2017-06-24 Thread Larry Hastings
On 06/23/2017 11:25 PM, Serhiy Storchaka wrote: I have installed it, but how to use it? $ python3 -m pip install --user blurb Collecting blurb Using cached blurb-1.0-py3-none-any.whl Installing collected packages: blurb Successfully installed blurb-1.0 $ python3 -m blurb /usr/bin/python3: No

Re: [Python-Dev] [python-committers] New workflow change: Welcome to blurb

2017-06-24 Thread Larry Hastings
On 06/24/2017 09:40 AM, Terry Reedy wrote: On 6/23/2017 11:24 PM, Larry Hastings wrote: > You can install blurb from pip: > > % pip3.6 install blurb This does not seem to work right. On Windows: C:\Users\Terry>py -3 -m pip install blurb Collecting blurb Downloading blurb-

Re: [Python-Dev] For all branches? [was Re: New workflow change: Welcome to blurb]

2017-06-24 Thread Larry Hastings
On 06/24/2017 10:21 AM, Antoine Pitrou wrote: One thing you didn't mention: is the switch on all branches or only master? All active branches: 2.7 3.3 3.4 3.5 3.6 master You should see a Misc/NEWS.d directory on each of those with an up-to-date clone. //arry/ __

Re: [Python-Dev] [python-committers] New workflow change: Welcome to blurb

2017-06-24 Thread Larry Hastings
On 06/24/2017 10:30 AM, Terry Reedy wrote: Solution: name the file blurb.py and put it in site-packages. This is standard and what is done by all other pip-installs that I have run. Put a copy in /Scripts if you want, but that is really optional and only sometimes effective. Brett redid th

Re: [Python-Dev] New workflow change: Welcome to blurb

2017-06-24 Thread Larry Hastings
On 06/24/2017 06:56 PM, Terry Reedy wrote: And what if there isn't? There are sometimes good reasons to have multiple patches on an issue, whereas an issue usually gets only one news item. There's nothing about blurb--or anything else in the workflow IIUC--that says you can't have multiple

Re: [Python-Dev] New workflow change: Welcome to blurb

2017-06-24 Thread Larry Hastings
On 06/24/2017 09:14 PM, Serhiy Storchaka wrote: Not only core developers make PRs for CPython. Since all non-trivial changes need to be mentioned in Misc/NEWS, blurb becomes a required tool for all committers. Well, no. *Writing blurb-compatible files* becomes a required step for all committ

Re: [Python-Dev] Helping contributors with chores (do we have to?)

2017-06-25 Thread Larry Hastings
On 06/25/2017 01:33 AM, Antoine Pitrou wrote: On Sat, 24 Jun 2017 21:37:46 -0700 Larry Hastings wrote: Well, no. *Writing blurb-compatible files* becomes a required step for all committers. And blurb makes that easy. But it's pretty easy to write them by hand; that's why we p

Re: [Python-Dev] Helping contributors with chores (do we have to?)

2017-06-25 Thread Larry Hastings
On 06/25/2017 10:02 AM, Nathaniel Smith wrote: My dudes, in a previous life I helped invent distributed VCS, but I still get confused by fiddly git BS just like everyone else. Really? I thought Bitkeeper was out before the monotone project even started--and TeamWare had monotone beat by mos

Re: [Python-Dev] Helping contributors with chores (do we have to?)

2017-06-25 Thread Larry Hastings
On 06/25/2017 11:01 AM, Nathaniel Smith wrote: On Jun 25, 2017 10:27, "Larry Hastings" <mailto:la...@hastings.org>> wrote: On 06/25/2017 10:02 AM, Nathaniel Smith wrote: My dudes, in a previous life I helped invent distributed VCS, but I still get confused by

[Python-Dev] Should I make a 3.4.7rc1 next weekend?

2017-07-12 Thread Larry Hastings
I'm scheduled to tag and release 3.5.4rc1 next weekend. I've been releasing 3.4 and 3.5 at the same time for the last year; this is convenient for me as it halves the frequency with which I have to put on the "release manager" hat. There are currently no scheduled dates to release 3.4.7.

[Python-Dev] Reminder: 3.5.4rc1 will be tagged next Saturday, July 22 2017

2017-07-12 Thread Larry Hastings
Just a quick reminder. I'll be tagging 3.5.4rc1 next Saturday, July 22. 3.5.4 final will be the last release of 3.5.4 that accepts bugfixes; after that, the 3.5 branch will transition to security-fixes-only mode. If you have bugfixes you want to ship with 3.5.4, please get them committed i

[Python-Dev] Announcing the schedule for 3.4.7

2017-07-15 Thread Larry Hastings
In reply to my proposal of a few days ago, I received two +1s and no other feedback. So I'm going to issue 3.4.7 with relatively-little notice.t Here's the schedule for 3.4.7; it mirrors the schedule for 3.5.4. Saturday, July 22, 2017 - tag 3.4.7 rc1 Sunday, July 23, 2017 - r

Re: [Python-Dev] Impact of Namedtuple on startup time

2017-07-18 Thread Larry Hastings
On 07/17/2017 07:25 PM, Nathaniel Smith wrote: I think the intention is to allow users with a certain kind of security requirement to opt in to a restricted version of the language that doesn't support exec. This is difficult if the stdlib is calling exec all over the place. But nobody is sug

Re: [Python-Dev] Python startup time

2017-07-19 Thread Larry Hastings
On 07/19/2017 05:59 AM, Victor Stinner wrote: Mercurial startup time is already 45.8x slower than Git whereas tested Mercurial runs on Python 2.7.12. Now try to sell Python 3 to Mercurial developers, with a startup time 2x - 3x slower... When Matt Mackall spoke at the Python Language Summit s

Re: [Python-Dev] startup time repeated? why not daemon

2017-07-21 Thread Larry Hastings
On 07/21/2017 03:28 PM, Barry Warsaw wrote: The TPI (Terrible Python Idea) I had at Pycon was some kind of (local) memcached of imported Python modules, which would theoretically allow avoiding loading the modules from the file system on start up. There would be all kinds of problems with this

[Python-Dev] Python 3.5.4rc1 and 3.4.7rc1 slipping by a day, to July 24 2017

2017-07-24 Thread Larry Hastings
Release engineering for 3.5.4rc1 and 3.4.7rc1 took a lot longer than expected, because this is the first release using "blurb", and it turned out there was a lot of work left to do and a couple dark corners yet to stumble over. 3.5.4rc1 and 3.4.7rc1 will be released Monday, July 24, 2017.

[Python-Dev] RELEASED] Python 3.4.7rc1 and Python 3.5.4rc1 are now available

2017-07-25 Thread Larry Hastings
On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm relieved to announce the availability of Python 3.4.7rc1 and Python 3.5.4rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 no

Re: [Python-Dev] for...else

2017-07-29 Thread Larry Hastings
As previously requested: please take this discussion to python-ideas. If you reply, remove python-dev from the To: and Cc: lists, and add python-ideas instead. This speculative discussion was never appropriate for python-dev. //arry/ On 07/28/2017 03:11 PM, Rob Cliffe wrote: On 28/07

Re: [Python-Dev] PyThreadState_GET() returns NULL from within PyImport_GetModuleDict()

2017-08-07 Thread Larry Hastings
On 08/07/2017 05:11 PM, Patrick Rutkowski wrote: Does anyone have any ideas here? My one idea: the GIL isn't initialized until you create a new thread. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinf

[Python-Dev] [RELEASED] Python 3.5.4 is now available

2017-08-08 Thread Larry Hastings
On behalf of the Python development community and the Python 3.5 release team, I'm pleased to announce the availability of Python 3.5.4. Python 3.5.4 is the final 3.5 release in "bug fix" mode. The Python 3.5 branch has now transitioned into "security fixes mode"; all future improvements i

[Python-Dev] Python 3.5 has now transitioned to "security fixes only" mode

2017-08-08 Thread Larry Hastings
The Python 3.5 branch has now entered "security fixes only" mode. No more bugfixes will be accepted into the 3.5 branch. In keeping with our modern workflow, I have changed the permissions on the 3.5 branch on Github so that only release managers can accept PRs into the branch. Please add

[Python-Dev] [RELEASED] Python 3.4.7 is now available

2017-08-09 Thread Larry Hastings
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.7. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug

[Python-Dev] Workflow change reminder: The Blurb Has Landed

2017-09-05 Thread Larry Hastings
Yesterday I "blurbified" the 2.7, 3.6, and master branches in CPython. It's finally official: all* branches have now been "blurbified". This means that Misc/NEWS is no longer present in any of CPython's active branches. Instead, Misc/NEWS has been broken up into a zillion little files in

[Python-Dev] PEP 549: Instance Properties (aka: module properties)

2017-09-05 Thread Larry Hastings
I've written a PEP proposing a language change: https://www.python.org/dev/peps/pep-0549/ The TL;DR summary: add support for property objects to modules. I've already posted a prototype. How's that sound? //arry/ ___ Python-Dev mailing list

[Python-Dev] Re: Python multithreading without the GIL

2021-10-12 Thread Larry Hastings
(off-list) On 10/11/21 2:09 PM, Sam Gross wrote: The ccbench results look pretty good: about 18.1x speed-up on "pi calculation" and 19.8x speed-up on "regular expression" with 20 threads (turbo off). The latency and throughput results look good too. JESUS CHRIST //arry/ ___

[Python-Dev] Re: Python multithreading without the GIL

2021-10-12 Thread Larry Hastings
Oops! Sorry everybody, I meant that to be off-list. Still, I hope you at least enjoyed my enthusiasm! /arry On Tue, Oct 12, 2021, 12:55 Larry Hastings wrote: > > (off-list) > > > On 10/11/21 2:09 PM, Sam Gross wrote: > > The ccbench results look pretty good: about

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-21 Thread Larry Hastings
On 10/21/21 5:01 AM, Henry Fredrick Schreiner wrote: PEP 649 was about the same as the current performance, but PEP 563 was significantly faster, since it doesn’t instantiate or deal with objects at all, which both the current default and PEP 563 do. I don't understand what you're saying abou

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-21 Thread Larry Hastings
On 10/21/21 5:42 PM, Damian Shaw wrote: Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP 649? I think I've seen others mention this but as the code object isn't executed until inspected then if you are just using annotations for type hints it should work fine? Ye

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-21 Thread Larry Hastings
; if the latter, Pydantic et al would have to iterate over every value in an annotation to look for this special value. As a consumer of annotations at runtime, I'd definitely prefer that they raise NameError rather than silently substitute in this alternative value. //arry / On 10/21/21 8

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-21 Thread Larry Hastings
On 10/21/21 1:17 AM, Steven D'Aprano wrote: On Thu, Oct 21, 2021 at 04:48:28PM -0400, Larry Hastings wrote: In Python, if you evaluate an undefined name, Python raises a NameError.  This is so consistent I'm willing to call it a "rule". Various folks have proposed an exc

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-23 Thread Larry Hastings
On 10/22/21 1:45 AM, Steven D'Aprano wrote: Any other runtime annotation tool has to support strings, otherwise the "from __future__ import annotations" directive will have already broken it. If the tool does type-checking, then it should support stringified annotations. They have been a standar

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

2021-10-26 Thread Larry Hastings
On 10/26/21 5:22 PM, Bluenix wrote: * Functions having the same signature share the same annotation tuple. Is this true with code that have a mutable default? [... examples deleted...] You're confusing two disjoint concepts. First of all, all your examples experiment with default values whi

[Python-Dev] Re: Naming convention for AST types

2021-10-29 Thread Larry Hastings
Hey, as public mailing list mistakes go, that one's pretty mild. //arry/ On 10/28/21 6:35 PM, Jeremiah Vivian wrote: Sorry for the two replies, I didn't think the first one would be sent. ___ Python-Dev mailing list -- python-dev@python.org To unsu

[Python-Dev] Oh look, I've been subscribed to python/issues-test-2 notifications again

2021-11-04 Thread Larry Hastings
I guess this is part of the migration from bpo to GitHub issues? Maybe the initial work could be done in a private repo, to cut down on the spurious email notifications to literally everybody subscribed to cpython?  Which is a lot of people. //arry/

[Python-Dev] Re: The current state of typing PEPs

2021-11-29 Thread Larry Hastings
On 11/29/21 2:56 PM, Barry Warsaw wrote: PEP 563 and 649 have visible effects that even within that domain can have important side effects. For example, PEP 563’s loss of local scope, which even “de-stringify-ing” can’t recover. This is what we need help with. Well, sure.  If PEP 563 and 6

[Python-Dev] Re: The current state of typing PEPs

2021-11-29 Thread Larry Hastings
On 11/29/21 7:10 PM, Inada Naoki wrote: Anyone against making a statement that "PEP 563 will never be the default behavior"? I think only the SC is empowered to make such a statement. Then, we do not need to decide "PEP 563 or 649". We can focus on whether we can replace "stock semantics +

[Python-Dev] Re: PEP 674 – Disallow using macros as l-value (version 2)

2022-01-26 Thread Larry Hastings
On 1/26/22 3:02 PM, Victor Stinner wrote: Hi, My PEP 674 proposed to change PyDescr_TYPE() and PyDescr_NAME() macros. This change breaks M2Crypto and mecab-python3 projects in code generated by SWIG. I tried two solutions to prevent SWIG accessing PyDescrObject members directly: https://bugs.pyt

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

2022-02-16 Thread Larry Hastings
I experimented with this at the EuroPython sprints in Berlin years ago.  I was sitting next to MvL, who had an interesting observation about it.  He suggested(*) all the constants unmarshalled as part of loading a module should be "immortal", and if we could rejigger how we allocated them to

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

2022-02-19 Thread Larry Hastings
On 2/19/22 04:41, Antoine Pitrou wrote: On Fri, 18 Feb 2022 14:56:10 -0700 Eric Snow wrote: On Wed, Feb 16, 2022 at 11:06 AM Larry Hastings wrote: He suggested(*) all the constants unmarshalled as part of loading a module should be "immortal", and if we could rejigger how we

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

2022-02-20 Thread Larry Hastings
les enough times this could waste a significant amount of memory), I think the former is more important. //arry/ On 2/20/22 06:01, Antoine Pitrou wrote: On Sat, 19 Feb 2022 12:05:22 -0500 Larry Hastings wrote: On 2/19/22 04:41, Antoine Pitrou wrote: On Fri, 18 Feb 2022 14:56:10 -0700 Eric Snow wrote

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

2022-02-21 Thread Larry Hastings
On 2/21/22 21:44, Larry Hastings wrote: While I don't think it's fine to play devil's advocate," Oh!  Please ignore the word "don't" in the above sentence.  I /do/ think it's fine to play devil's advocate. Sheesh, //arry/ _

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

2022-02-21 Thread Larry Hastings
On 2/21/22 22:06, Chris Angelico wrote: On Mon, 21 Feb 2022 at 16:47, Larry Hastings wrote: While I don't think it's fine to play devil's advocate, given the choice between "this will help a common production use-case" (pre-fork servers) and "this could hurt

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)

2022-02-22 Thread Larry Hastings
On 2/22/22 6:00 PM, Eric Snow wrote: On Sat, Feb 19, 2022 at 12:46 AM Eric Snow wrote: Performance --- A naive implementation shows `a 4% slowdown`_. Several promising mitigation strategies will be pursued in the effort to bring it closer to performance-neutral. See the `mitigation`_

[Python-Dev] Re: Defining tiered platform support

2022-03-14 Thread Larry Hastings
On 3/14/22 20:31, Brett Cannon wrote: On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner wrote: It would be great to have the list of supported platforms per Python version! I could see the table in PEP 11 being copied into the release PEPs. By "release PEPs", you mean the release

[Python-Dev] Proto-PEP part 1: Forward declaration of classes

2022-04-22 Thread Larry Hastings
This document is a loose proto-PEP for a new "forward class" / "continue class" syntax.  Keep in mind, the formatting is a mess. If I wind up submitting it as a real PEP I'll be sure to clean it up first. /arry -- PEP : Forward declaration of class

[Python-Dev] Proto-PEP part 2: Alternate implementation proposal for "forward class" using a proxy object

2022-04-22 Thread Larry Hastings
Here's one alternate idea for how to implement the "forward class" syntax. The entire point of the "forward class" statement is that it creates the real actual class object.  But what if it wasn't actually the "real" class object?  What if it was only a proxy for the real object? In this scenar

[Python-Dev] Proto-PEP part 3: Closing thoughts on "forward class", etc.

2022-04-22 Thread Larry Hastings
Just a quick note from me on the proto-PEP and the two proposed implementations.  When I started exploring this approach, I didn't suspect it'd require such sweeping changes to be feasible. Specifically, I didn't think I was going to propose changing the fundamental mechanism used to create

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-22 Thread Larry Hastings
On 4/22/22 19:17, Chris Angelico wrote: I'm unsure about the forward class. How is it different from subclassing an ABC? They're just different objects.  A subclass of an ABC is either itself another abstract base class, which will never be instantiatable, or a non-abstract class, which is i

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-22 Thread Larry Hastings
On 4/22/22 19:36, Terry Reedy wrote: On 4/22/2022 9:13 PM, Larry Hastings wrote: forward class X() New keywords are a nuisance.  And the proposed implementation seems too complex. My proposed implementation seemed necessary to handle the complexity of the problem.  I would welcome a

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-22 Thread Larry Hastings
On 4/22/22 20:58, Steven D'Aprano wrote: On Fri, Apr 22, 2022 at 06:13:57PM -0700, Larry Hastings wrote: This PEP proposes an additional syntax for declaring a class which splits this work across two statements: * The first statement is `forward class`, which declares the class and

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-22 Thread Larry Hastings
On 4/22/22 22:03, Chris Angelico wrote: Anyhow, [a forward-defined class object is] a class, with some special features (notably that you can't instantiate it). Yes.  Specifically, here's my intention for "forward-defined class objects": you can examine some generic dunder values (__name__,

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Larry Hastings
On 4/22/22 23:41, Mehdi2277 wrote: My main question for this approach is how would this work with type checkers? It would be new syntax for Python, so type checkers would have to understand it. Is there any restriction that forward class's continuation must appear in same module? No.

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Larry Hastings
On 4/23/22 00:53, Steven D'Aprano wrote: It's a "forward-declared class object".  It's the real class object, but it hasn't been fully initialized yet, and won't be until the "continue class" statement. The only thing that makes it not fully initialised is that it has a bozo bit dunder "__forwa

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Larry Hastings
On 4/23/22 01:14, Steven D'Aprano wrote: On Sat, Apr 23, 2022 at 12:46:37AM -0700, Larry Hastings wrote: But rather than speculate further, perhaps someone who works on one of the static type analysis checkers will join the discussion and render an informed opinion about how easy or ha

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Larry Hastings
On 4/23/22 03:10, Terry Reedy wrote: On 4/22/2022 11:16 PM, Larry Hastings wrote: So I still prefer "forward class". I don't think it's as clear as "forward class" 'forward class' for an incomplete class is not at all clear to me.  It is not clear

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Larry Hastings
I should have said "numpy_forward", not "numpy.forward". I changed my mind at the last second as I was writing that email, and momentarily forgot that when you import x.y you implicitly import x. /arry On Sat, Apr 23, 2022, 01:53 Larry Hastings wrote: > > On 4/23

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Larry Hastings
On 4/23/22 06:55, Jelle Zijlstra wrote: So to reiterate, your proposal would be to write this as: forward class B:     pass class A:     value: B continue class B:     value: A Not quite; the "forward class" statement doesn't have a colon or a class body.  This would be written as: fo

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

2022-04-23 Thread Larry Hastings
On 4/23/22 08:57, Eric V. Smith wrote: On 4/23/2022 9:55 AM, Jelle Zijlstra wrote: However, it doesn't solve the problem for base classes. For example, str is conceptually defined as `class str(Sequence["str"]):`. A forward reference can't make `str` defined when the bases are evaluated, be

[Python-Dev] Proto-PEP part 4: The wonderful third option

2022-04-25 Thread Larry Hastings
Sorry, folks, but I've been busy the last few days--the Language Summit is Wednesday, and I had to pack and get myself to SLC for PyCon, &c.  I'll circle back and read the messages on the existing threads tomorrow.  But for now I wanted to post "the wonderful third option" for forward class d

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

2022-04-26 Thread Larry Hastings
On 4/25/22 23:56, Ronald Oussoren wrote: A problem with this trick is that you don’t know how large a class object can get because a subclass of type might add new slots. This is currently not possible to do in Python code (non-empty ``__slots__`` in a type subclass is rejected at runtime), bu

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

2022-04-26 Thread Larry Hastings
On 4/26/22 09:31, MRAB wrote: On 2022-04-26 06:32, Larry Hastings wrote: Note that this spelling is also viable:     class C I don't like that because it looks like you've just forgotten the colon. Perhaps:     class C: ... That's not a good idea.  Every other place

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

2022-05-01 Thread Larry Hastings
FWIW, I'm in agreement.  My "forward class" proposal(s) were me trying to shine a light to find a way forward; I'm in no way adamant that we go that direction.  If we can make 649 palatable without introducing forward declarations for classes, that's great!  If in the future we discover more

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

2022-05-01 Thread Larry Hastings
On 5/1/22 15:44, Paul Bryan wrote: Can someone state what's currently unpalatable about 649? It seemed to address the forward-referencing issues, certainly all of the cases I was expecting to encounter. Carl's talk was excellent here; it would be lovely if he would chime in and reply.  Here

[Python-Dev] Timeline for 3.5.8

2019-09-01 Thread Larry Hastings
Howdy howdy.  Here's what I'm thinking for the next release of 3.5.  This week I'm going to merge / reject all the outstanding PRs for 3.5, then cut rc1 at the Python Core Dev sprints next week, either Monday (2019/9/9) or Tuesday (2019/9/10).  This isn't a lot of notice, but things have slow

[Python-Dev] [RELEASED] Python 3.5.8rc1 is released

2019-09-09 Thread Larry Hastings
On behalf of the Python development community, I'm chuffed to announce the availability of Python 3.5.8rc1. Python 3.5 is in "security fixes only" mode.  This new version only contains security fixes, not conventional bug fixes, and it is a source-only release. You can find Python 3.5.8rc1

[Python-Dev] Re: Timeline for 3.5.8

2019-09-19 Thread Larry Hastings
in a fix, or we need to downgrade the issue from Release Blocker. As I mention on the issue, depending on the complexity of the fix for this issue (if we go that route) I may do another rc before final. In a holding pattern, //arry/ On 9/1/19 11:53 AM, Larry Hastings wrote: Howdy

[Python-Dev] [RELEASED] Python 3.5.8rc2 is released

2019-10-12 Thread Larry Hastings
On behalf of the Python development community, I'm relieved to announce the availability of Python 3.5.8rc2.  It's been a month after Python 3.5.8rc1, and since then we've added a small amount of new code to fix an API-level regression in http client, updated expat to 2.2.8, and upgraded the

[Python-Dev] [RELEASED] Python 3.5.8 is (finally) released

2019-10-28 Thread Larry Hastings
On behalf of the Python development community, I'm relieved to announce the availability of Python 3.5.8. Python 3.5 is in "security fixes only" mode.  This new version only contains security fixes, not conventional bug fixes, and it is a source-only release. You can find Python 3.5.8 here

[Python-Dev] [WARNING] Some users who downloaded the Python 3.5.8 .xz tarball got the wrong version

2019-10-30 Thread Larry Hastings
Due to awkward CDN caching, some users who downloaded the source code tarballs of Python 3.5.8 got a preliminary version instead of the final version.  As best as we can tell, this only affects the .xz release; there are no known instances of users downloading an incorrect version of the .tgz

[Python-Dev] [RELEASED] Python 3.5.9 is released

2019-11-01 Thread Larry Hastings
On behalf of the Python development community, I'm slightly chagrined to announce the availability of Python 3.5.9.  There were no new changes in version 3.5.9; 3.5.9 was released only because of a CDN caching problem, which resulted in some users downloading a prerelease version of the 3.5.8

[Python-Dev] Re: Pass the Python thread state to internal C functions

2019-11-13 Thread Larry Hastings
On 11/12/19 2:03 PM, Victor Stinner wrote: Hi, Are you ok to modify internal C functions to pass explicitly tstate? I did exactly that in the Gilectomy prototype.  Pulling it out of TLS was too slow, and storing it in a global wouldn't work with multiple actually-concurrent threads. //ar

[Python-Dev] Re: Pass the Python thread state to internal C functions

2019-11-13 Thread Larry Hastings
On 11/13/19 5:52 AM, Victor Stinner wrote: Le mer. 13 nov. 2019 à 14:28, Larry Hastings a écrit : I did exactly that in the Gilectomy prototype. Pulling it out of TLS was too slow, What do you mean? Getting tstate from a TLS was a performance bottleneck by itself? Reading a TLS variable

[Python-Dev] HighwayHash > SipHash?

2019-12-03 Thread Larry Hastings
My random Googling turned up a new hash function tonight: "HighwayHash".  It's a keyed hash function like the SipHash we now use for hashing strings / bytes / etc for our lovely dicts. Key points: * Apache 2 license * Can use SIMD * "5x faster than SipHash" I think they mean 5x faster th

[Python-Dev] Should set objects maintain insertion order too?

2019-12-15 Thread Larry Hastings
As of 3.7, dict objects are guaranteed to maintain insertion order.  But set objects make no such guarantee, and AFAIK in practice they don't maintain insertion order either.  Should they? I do have a use case for this. In one project I maintain a "ready" list of jobs; I need to iterate over

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-15 Thread Larry Hastings
they maintained insertion order?  Are there operations on set objects that would no longer be possible? //arry/ On 12/15/19 6:58 PM, Tim Peters wrote: [Larry Hastings ] As of 3.7, dict objects are guaranteed to maintain insertion order. But set objects make no such guarantee, and AFAIK in pra

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-15 Thread Larry Hastings
On 12/15/19 8:25 PM, Raymond Hettinger wrote: On Dec 15, 2019, at 6:48 PM, Larry Hastings wrote: As of 3.7, dict objects are guaranteed to maintain insertion order. But set objects make no such guarantee, and AFAIK in practice they don't maintain insertion order either. Should the

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-16 Thread Larry Hastings
On 12/16/19 10:59 AM, Tim Peters wrote: BTW, what should {1, 2} | {3, 4, 5, 6, 7} return as ordered sets? Beats me.; The obvious answer is {1, 2, 3, 4, 5, 6, 7}.  Which is the result I got in Python 3.8 just now ;-)  But that's just a side-effect of how hashing numbers works, the impl

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-16 Thread Larry Hastings
On 12/16/19 6:30 PM, Tim Peters wrote: If it's desired that "insertion order" be consistent across runs, platforms, and releases, then what "insertion order" _means_ needs to be rigorously defined & specified for all set operations. This was comparatively trivial for dicts, because there are, e

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-16 Thread Larry Hastings
On 12/16/19 7:43 PM, Tim Peters wrote: [Petr Viktorin ] Here's one (very simplified and maybe biased) view of the history of dicts: * 2.x: Dicts are unordered, please don't rely on the order. * 3.3: Dict iteration order is now randomized. We told you not to rely on it! * 3.6: We now use an opt

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-16 Thread Larry Hastings
On 12/16/19 10:32 PM, Tim Peters wrote: [Larry] Python is the language where speed, correctness, and readability trump performance every time. Speed trumping performance didn't make any sense ;-) Sorry, that /was/ super unclear!  I honestly meant speed of /development/. D'oh, //arry/ __

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-17 Thread Larry Hastings
On 12/17/19 2:02 AM, Steven D'Aprano wrote: Without being facetious[1] if you don't care about performance, you don't need a set, you could use a list. Lists don't enforce uniqueness.  Apart from that a list would probably work fine for my needs; in my admittedly-modest workloads I would pr

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-21 Thread Larry Hastings
(mixing together messages in the thread, sorry threaded-view readers) On 12/19/19 3:15 PM, Tim Peters wrote: [Nick] I took Larry's request a slightly different way: [...] Only Larry can answer whether that would meet his perceived need. My _guess_ is that he wouldn't know OrderedSet existed,

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-24 Thread Larry Hastings
On 12/23/19 8:09 PM, Kyle Stanley wrote: Chris Angelico wrote: > I think this is an artifact of Python not having an empty set literal. > [snip] > When both use the constructor call or both use a literal, the > difference is far smaller. I'd call this one a wash. Ah, good catch. I hadn't consi

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-28 Thread Larry Hastings
uot; to it. Here is the original description of my problem, from the original email in this thread.  I considered this an adequate explanation of my problem at the time. On 12/15/19 6:48 PM, Larry Hastings wrote: I do have a use case for this. In one project I maintain a "ready" list o

[Python-Dev] Re: Should set objects maintain insertion order too?

2019-12-29 Thread Larry Hastings
On 12/28/19 6:24 PM, Tim Peters wrote: [Larry] Here is the original description of my problem, from the original email in this thread. I considered this an adequate explanation of my problem at the time. I do have a use case for this. In one project I maintain a "ready" list of jobs; I need t

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

2020-02-03 Thread Larry Hastings
On 2/3/20 3:07 PM, Sebastian Berg wrote: That would mean adding `operator.equivalent(a, b) -> bool` which would allow float to override the result and let `operator.equivalent_value(float("NaN"), float("NaN))` return True; luckily very few types would actually override the operation. You misund

[Python-Dev] Re: [RELEASE] Python 2.7.18, the end of an era

2020-04-21 Thread Larry Hastings
On 4/20/20 8:06 AM, Benjamin Peterson wrote: I'm eudaemonic to announce the immediate availability of Python 2.7.18. [...] Over all those years, CPython's core developers and contributors sedulously applied bug fixes to the 2.7 branch, no small task as the Python 2 and 3 branches diverged.

[Python-Dev] Proposed release schedule for 3.5.9

2020-06-14 Thread Larry Hastings
Gosh how time flies.  3.5 is nearing the end of its security maintenance period, and as such the patches have slowed down.  But we got a couple recently--all having to do with web technologies--so it's probably time to make another release.  I propose to release rc1 in two weeks, and final tw

[Python-Dev] Re: Proposed release schedule for 3.5.9

2020-06-15 Thread Larry Hastings
Oh, good point!  I forgot about that and was, uh, looking in the wrong place.  Yes, the next version will be 3.5.10. //arry/ On 6/14/20 2:30 PM, John Thorvald Wodder II wrote: 3.5.9 was already released back in November. Yes, it's (almost) the same code as 3.5.8, but its version number (

<    2   3   4   5   6   7   8   9   >