[Python-Dev] [RELEASED] Python 3.4.0a1

or implementing custom memory allocators To download Python 3.4.0a1 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0a1 with your code and reporting any issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release M

Re: [Python-Dev] [RELEASED] Python 3.4.0a1

On 08/03/2013 11:22 PM, Larry Hastings wrote: * PEP 435, a standardized "enum" module * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocator

Re: [Python-Dev] [RELEASED] Python 3.4.0a1

On 08/04/2013 07:01 AM, Eli Bendersky wrote: Larry, if there are other things you're going to add, update the web page http://www.python.org/download/releases/3.4.0/ as well - it's the one being linked in the inter-webs now. Good thinking! I'll do that today. //arry/

[Python-Dev] The Return Of Argument Clinic

It's time to discuss Argument Clinic again. I think the implementation is ready for public scrutiny. (It was actually ready a week ago, but I lost a couple of days to "make distclean" corrupting my hg data store--yes, I hadn't upped my local clinic branch in a while. Eventually I gave up on r

Re: [Python-Dev] The Return Of Argument Clinic

On 08/05/2013 02:55 AM, Nick Coghlan wrote: On 5 August 2013 18:48, Larry Hastings wrote: Question 0: How should we integrate Clinic into the build process? Isn't solving the bootstrapping problem the reason for checking in the clinic-generated output? If there's no Python ava

Re: [Python-Dev] The Return Of Argument Clinic

On 08/05/2013 09:59 PM, Nick Coghlan wrote: ___ Question 2: Emit code for modules and classes? [...] Originally Clinic didn't ask for full class and module information, you just specified the full dotted path and that was that. Bu

Re: [Python-Dev] Deprecating the formatter module

On 08/12/2013 04:11 PM, Paul Moore wrote: [...] if I'd stumbled across it by chance, my reaction would have been that it was another one of Python's "hidden gems" that I'd never been aware of. Hidden "gem"? No. Hidden "paste diamond", maybe. YAGNI, //arry/

[Python-Dev] [RELEASED] Python 3.4.0a2

isit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0a2 with your code and reporting any issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4

Re: [Python-Dev] PEP 455: TransformDict

On 09/14/2013 03:40 AM, Antoine Pitrou wrote: Hello, Following the python-dev discussion, I've written a PEP to recap the proposal and the various arguments. It's inlined below, and it will probably appear soon at http://www.python.org/dev/peps/pep-0455/, too. Whenever I read a discussion abou

Re: [Python-Dev] PEP 455: TransformDict

On 09/14/2013 07:30 PM, Antoine Pitrou wrote: On Sat, 14 Sep 2013 14:33:56 +0900 Larry Hastings wrote: Whenever I read a discussion about the dict, I always wonder whether the same thing applies to a set. Have you considered the utility of a TransformSet? Or is it YAGNI? Well, a

Re: [Python-Dev] Best practice for documentation for std lib

On 09/23/2013 03:44 AM, Guido van Rossum wrote: On Sun, Sep 22, 2013 at 7:25 PM, Terry Reedy > wrote: I am gradually changing Idle docstrings, though only Idle developers will ever see them. Writing a 60 char summary forces a clear understanding of the functi

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

On 09/27/2013 11:33 PM, Guido van Rossum wrote: I've been looking at my progress with Tulip and the 3.4 release schedule (PEP 429) and it looks like I will have to do some kind of sprint to get it into the release in time for beta 1, which is planned for Nov 24. Ideally I'd get it into alpha 4,

[Python-Dev] [RELEASED] Python 3.4.0a3

s you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On 10/04/2013 11:15 AM, Victor Stinner wrote: 2013/10/4 Armin Rigo : The current hash randomization is simply not preventing anything; someone posted long ago a way to recover bit-by-bit the hash randomized used by a remote web program in Python running on a server. Oh interesting, is it public

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On 10/05/2013 01:14 AM, Victor Stinner wrote: And how do you retrieve the whole hash value from an HTTP page? You may retrieve some bits using specific HTTP requests, but not directly the whole hash value. I don't know any web page displaying directly the hash value of a string coming from the

[Python-Dev] PEP 457: Syntax For Positional-Only Parameters

ified: $Date$ Author: Larry Hastings Discussions-To: Python-Dev Status: Draft Type: Informational Content-Type: text/x-rst Created: 08-Oct-2013 Overview This PEP proposes a syntax for positional-only parameters in Python. Positional-only parameters are parameters without an exter

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

A very quick reply, more tomorrow. On 10/09/2013 02:15 AM, Steven D'Aprano wrote: I note that in your example above, you put the comma outside the square bracket: def addch([y, x,] ch, [attr], /): which seems perfectly readable to me. It becomes less readable / more tiresome with nested gro

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 03:57 AM, Joao S. O. Bueno wrote: def a([b],/,**kw): print (b) does calling "a(b=5)" should raise a TypeError, or put "5" in """kw["b"]""" and leave "b" as "undefined" ? The latter. This is how they are "similarly to *args and **kwargs": >>> def foo(*a, **kw): ...

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 02:38 PM, Benjamin Peterson wrote: Why does a syntax need to be reserved? Documentation conventions and the syntax of internal tools like argument clinic may be changed any time we like. If Argument Clinic is accepted, and ships with Python, my expectation is that it would cease

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 03:31 AM, Benjamin Peterson wrote: 2013/10/8 Larry Hastings : This PEP proposes a backwards-compatible syntax that should permit implementing any builtin in pure Python code. This is rather too strong. You can certainly implement them; you just have to implement the argument

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 07:48 AM, Eric Snow wrote: The PEP doesn't mention anything about inspect.Signature, which already supports positional-only parameters. It should. Well, inspect.Signature support for positional-only parameters is currently insufficient to express all of Python's builtins. As I

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 07:15 AM, Georg Brandl wrote: We have quite a large amount of C functions with positional-only parameters. Adding a "/" to each of those is a) a tedious task and b) probably not helpful for a lot of people: I volunteer to ensure that the "/"s are added if this PEP is accepted.

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 11:46 AM, Nick Coghlan wrote: Generally, it needs to be a bit clearer that the intent of the PEP isn't to say "let's do this", it's to be explicit that acceptance of the Argument Clinic PEP severely constrains the design space for possible solutions if we ever *did* implement Pyt

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 03:36 PM, Antoine Pitrou wrote: I think it would be better to exercise [Argument Clinc] first as an internal tool, eliminate any possible quirks and issues, and *then* perhaps expose it as a public API. By the way, do you think it'll be ready for 3.4? Only if I can stop writing

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 04:26 PM, Georg Brandl wrote: I realize you are -1 on the proposal in general, but I'd be very interested if you could propose an alternate approach where I didn't need "a new spelling for None" as you put it. I think I would make Steven's proposed syntax mandatory: let the impleme

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 04:24 PM, Benjamin Peterson wrote: My proposed syntax is a little complex--but complex is better than complicated and inconsistent and undocumented and inconvenient, which is what we have now. Certainly the argument conventions of these functions are not undocumented, so wonder wha

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 04:38 PM, Paul Moore wrote: For that matter, why does the syntax used by Argument Clinic have to be the same as whatever future syntax is used in Python? If indeed, any ever is? What benefit do we get given the cost (rushing in a syntax that nobody is actually convinced we even need

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 04:45 PM, Anders J. Munch wrote: Larry Hastings wrote: > I look forward to an alternate suggestion. This is the least-bad > thing I could come up with. How about a naming convention instead, where using a leading underscore in a parameter name is a hint that it is posi

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 06:48 PM, Terry Reedy wrote: On 10/9/2013 9:51 AM, Larry Hastings wrote: range() in PyPy accepts keyword parameters, and in fact this works: range(9, step=2) That's way illegal in CPython. But Georg's point is that it does not have to be illegal in CPython.

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 07:50 PM, Eli Bendersky wrote: I'm not sure what you call "parsing". This? >>> def myfoo(*args): a, b = args; print("%s, then %s" % (a, b)) From the Argument Clinic PEP (436): The primary implementation of Python, "CPython", is written in a mixture of Python and C. One imp

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 08:25 PM, Terry Reedy wrote: I am sure that he has rejected any backward-incompatible change, as would I. Allowing keyword passing *is* compatible, so I would not guess about that. I don't know where to look for this discussion, and I read it quite some time ago. So I this is

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 10:46 PM, Mark Shannon wrote: There is no need to create an "undefined" value. Rather than define a parameter by assigning a fake value, just don't define it. We already do this for non-parameter locals and it could be extended to parameters. 'range' would be defined thus: def

[Python-Dev] Checking in Argument Clinic early?

I really want to get Argument Clinic in to Python 3.4. Currently the following is true: * It has an implementation I've been working on for more than a year. * I assert that it's a reasonable approach and the APIs are ready for public consumption. * The syntax for the DSL is the one pr

Re: [Python-Dev] Checking in Argument Clinic early?

On 10/15/2013 02:06 PM, Nick Coghlan wrote: On 15 October 2013 22:55, Larry Hastings wrote: So, quick poll: do you approve of me checking Argument Clinic in to Python 3.4 trunk in its current state before 3.4a4? I'm inclined to say yes, but ultimately the +1 you need is Guido's :

Re: [Python-Dev] Checking in Argument Clinic early?

On 10/15/2013 02:59 PM, Antoine Pitrou wrote: Le Tue, 15 Oct 2013 13:55:47 +0100, Larry Hastings a écrit : You can review the existing code here: https://bitbucket.org/larry/python-clinic/ You didn't create it as a (Bitbucket) fork of CPython, and you didn't put your ch

Re: [Python-Dev] Checking in Argument Clinic early?

On 10/15/2013 03:52 PM, Guido van Rossum wrote: I'm +1 -- I have been ever since Larry & I discussed it at EuroPython 2012. If this love-in continues I'll prep a release tonight and commit it in the morning... just before my flight home across the Atlantic. //arry/ _

[Python-Dev] The Tulip Has Landed

For those interested parties: Guido just checked "asyncio", aka "Tulip", aka "PEP 3156", in to trunk. I expect it to be part of Python 3.4.0a4, hopefully to be released this weekend. Maybe /that'll/ generate some interest in the alpha ;-) //arry/ ___

Re: [Python-Dev] Checking in Argument Clinic early?

On 10/15/2013 09:22 AM, Larry Hastings wrote: If this love-in continues I'll prep a release tonight and commit it in the morning... just before my flight home across the Atlantic. Okay, so, I slowed it down a little--some last-minute things cropped up. I've uploaded a fresh pa

[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

A problem has surfaced just this week in 3.5.1. Obviously this is a good time to fix it for 3.5.2. But there's a big argument over what is "broken" and what is an appropriate "fix". As 3.5 Release Manager, I can put my foot down and make rulings, and AFAIK the only way to overrule me is wi

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/09/2016 08:52 AM, Guido van Rossum wrote: That leaves direct calls to os.urandom(). I don't think this should block either. Then it's you and me against the rest of the world ;-) Okay, it's decided: os.urandom() must be changed for 3.5.2 to never block on a getrandom() call. It's per

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/09/2016 10:22 AM, Donald Stufft wrote: On Jun 9, 2016, at 1:14 PM, Steven D'Aprano wrote: Just to be clear, this is only an option on Linux, right? All the other major platforms block, whatever we decide to do on Linux. Including Windows? To my knowledge, all other major platforms block

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/09/2016 03:44 PM, Ethan Furman wrote: On 06/09/2016 03:22 PM, Larry Hastings wrote: Okay, it's decided: os.urandom() must be changed for 3.5.2 to never block on a getrandom() call. One way to not block is to raise an exception. Since this is such a rare occurrence anyway I don&

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/09/2016 07:38 PM, Nikolaus Rath wrote: On Jun 09 2016, Larry Hastings wrote: Nope, I want the old behavior back. os.urandom() should read /dev/random if getrandom() would block. As the British say, "it should do what it says on the tin". Aeh, what the tin says is "retu

Re: [Python-Dev] BDFL ruling request: should we block foreverwaiting for high-quality random bits?

On 06/09/2016 05:00 PM, Steve Dower wrote: If the pattern is really going to be the hasattr check you posted earlier, can we just do it for people and save them writing code that won't work on different OSs? No. That's what got us into this mess in the first place. 3.5.0 and 3.5.1 *already*

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/09/2016 07:58 PM, Nathaniel Smith wrote: I suspect the crypto folks would be okay with pushing this back to 3.6, so long as the final resolution is that os.urandom remains the standard interface for, as the docstring says, "Return[ing] a string of n random bytes suitable for cryptographic

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/10/2016 12:29 PM, David Mertz wrote: I believe that secrets.token_bytes() and secrets.SystemRandom() should be changed even for 3.5.1 to use getrandom() on Linux. Surely you meant 3.5.2? 3.5.1 shipped last December. //arry/ ___ Python-Dev mai

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/10/2016 11:55 AM, Donald Stufft wrote: Ok, so you’re looking for how would you replicate the blocking behavior of os.urandom that exists in 3.5.0 and 3.5.1? In that case, it’s hard. I don’t think linux provides any way to externally determine if /dev/urandom has been initialized or not.

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/10/2016 01:01 PM, David Mertz wrote: So yes, I think 3.5.2 should restore the 2.6-3.4 behavior of os.urandom(), That makes... five of us I think ;-) (Larry Guido Barry Tim David) and the NEW APIs in secrets should use the "best available randomness (even if it blocks)" I'm not parti

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/10/2016 12:54 PM, Theodore Ts'o wrote: So even on Python pre-3.5.0, realistically speaking, the "weakness" of os.random would only be an issue (a) if it is run within the first few seconds of boot, and (b) os.random is used to directly generate a long-term cryptographic secret. If you ar

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/11/2016 12:49 AM, Steven D'Aprano wrote: Will there be platforms where os.getrandom doesn't exist? If not, then secrets can just rely on it, otherwise what should it do? if hasattr(os, 'getrandom'): return os.getrandom(n) else: # Fail? Fall back on os.urandom? AFAIK: * Only

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/11/2016 11:30 AM, Donald Stufft wrote: The problem is that someone writing software that does os.urandom(block=True) or os.urandom(exception=True) which gets some bytes doesn’t know if it got back cryptographically secure random because Python called getrandom() or if it got back cryptog

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/11/2016 01:48 PM, Guido van Rossum wrote: So I still don't see why we need os.getrandom() -- it has nothing to recommend it over the secrets module (since both won't happen before 3.6). I have two reasons, neither of which I think are necessarily all that persuasive. Don't consider th

Re: [Python-Dev] writing to /dev/*random [was: BDFL ruling request: should we block ...]

On 06/11/2016 05:16 PM, Stephen J. Turnbull wrote: Use a Raspberry-Pi, or other advanced expensive hardware. There's no real excuse for not having a hardware generator if the Pi has one! Intel CPUs added the RDRAND instruction as of Ivy Bridge, although there's an ongoing debate as to whether

Re: [Python-Dev] Reminder: 3.6.0a2 snapshot 2016-06-13 12:00 UTC

On 06/10/2016 03:23 PM, Ned Deily wrote: Also note that Larry has announced plans to do a 3.5.2 release candidate sometime this weekend and Benjamin plans to do a 2.7.12 release candidate. So get important maintenance release fixes in ASAP. To clarify: /both/ 3.5.2rc1 /and/ 3.4.5rc1 were ta

[Python-Dev] [RELEASED] Python 3.4.5rc1 and Python 3.5.2rc1 are now available

On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm pleased to announce the availability of Python 3.4.5rc1 and Python 3.5.2rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. All changes ma

Re: [Python-Dev] PEP 468

On 06/13/2016 05:05 PM, MRAB wrote: This could be avoided by expanding the items to include the index of the 'previous' and 'next' item, so that they could be handled like a doubly-linked list. The disadvantage would be that it would use more memory. Another, easier technique: don't fill hol

Re: [Python-Dev] [Python-checkins] cpython (3.5): Fix os.urandom() using getrandom() on Linux

On 06/14/2016 08:07 AM, Steven D'Aprano wrote: Is this right? I thought we had decided that os.urandom should *not* fall back on getrandom on Linux? We decided that os.urandom() should not *block* on Linux. Which it doesn't; we now strictly call getrandom(GRND_NONBLOCK), which will never b

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/15/2016 11:45 PM, Barry Warsaw wrote: So we very clearly provided platform-dependent caveats on the cryptographic quality of os.urandom(). We also made a strong claim that there's a direct connection between os.urandom() and /dev/urandom on "Unix-like system(s)". We broke that particular

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/16/2016 01:03 AM, Barry Warsaw wrote: *If* we can guarantee that os.urandom() will never block or raise an exception when only poor entropy is available, then it may be indeed indistinguishably backward compatible for most if not all cases. I stepped through the code that shipped in 3.5.

[Python-Dev] Here's what's going into 3.5.2 final and 3.4.5 final

Heads up! This is a courtesy reminder from your friendly 3.4 and 3.5 release manager. Here's a list of all the changes since 3.5.2rc1 that are currently going into 3.5.2 final: * 155e665428c6 - Zachary: OpenSSL 1.0.2h build changes for Windows * cae0b7ffeb9f - Benjamin: fix % in Doc/what

[Python-Dev] [RELEASED] Python 3.4.5 and Python 3.5.2 are now available

On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm thrilled to announce the availability of Python 3.4.5 and Python 3.5.2. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. All changes made t

Re: [Python-Dev] Request for CPython 3.5.3 release

On 06/28/2016 02:05 PM, Yury Selivanov wrote: Long story short, I've discovered that asyncio is broken in 3.5.2. Specifically, there is a callbacks race in `loop.sock_connect` which can make subsequent `loop.sock_sendall` calls to hang forever. This thing is very tricky and hard to detect and de

Re: [Python-Dev] Request for CPython 3.5.3 release

On 06/28/2016 02:05 PM, Yury Selivanov wrote: Larry and the release team: would it be possible to make an "emergency" 3.5.3 release? I'd like to hear from the other asyncio reviewers: is this bug bad enough to merit such an "emergency" release? Thanks, //arry/ ___

Re: [Python-Dev] Request for CPython 3.5.3 release

On 06/28/2016 04:23 PM, Raymond Hettinger wrote: On Jun 29, 2016, at 12:42 AM, Larry Hastings wrote: By the way, I don't know why you Cc'd Nick and Brett. While they're fine fellows, they aren't on the release team, and they aren't involved in these sorts of decis

Re: [Python-Dev] AutoNumber Enum

On 06/29/2016 01:01 PM, Ivan Levkivskyi wrote: It looks like the values in AutoNumberEnum are consecutive integers 1,2,3,... Have you considered an option (keyword argument) to change this to powers of two 1,2,4,8,...? Why would you want that? I remind you that this descends from Enum, so it

Re: [Python-Dev] Request for CPython 3.5.3 release

On 06/28/2016 02:51 PM, Larry Hastings wrote: On 06/28/2016 02:05 PM, Yury Selivanov wrote: Larry and the release team: would it be possible to make an "emergency" 3.5.3 release? I'd like to hear from the other asyncio reviewers: is this bug bad enough to merit such an &quo

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3, release)

On 07/03/2016 09:39 AM, Guido van Rossum wrote: Do releases really have to be such big productions? A recent ACM article by Tom Limoncelli[1] reminded me that we're doing releases the old-fashioned way -- infrequently, and with lots of manual labor. Maybe we could (eventually) try to strive for

Re: [Python-Dev] Status of the Argument Clinic DSL

On 08/04/2016 09:11 AM, Alexander Belopolsky wrote: Furthermore, the 3.4 release notes contain a warning saying "The Argument Clinic PEP is not fully up to date with the state of the implementation." It does not look like this situation has improved since. It hasn't. The PEP lags behind the

Re: [Python-Dev] Status of the Argument Clinic DSL

On 08/04/2016 03:45 PM, Alexander Belopolsky wrote: On Thu, Aug 4, 2016 at 2:19 PM, Larry Hastings <mailto:la...@hastings.org>> wrote: AFAIK the Clinic DSL can handle all of Python's C extensions. I have no plans to "revise the whole approach"; if someone

Re: [Python-Dev] Status of the Argument Clinic DSL

On 08/04/2016 11:58 PM, Nick Coghlan wrote: I occasionally wonder if we should document the "/" notation in https://docs.python.org/3/library/inspect.html#introspecting-callables-with-the-signature-object as it can sometimes show up in the text representation of signature objects: >>> prin

[Python-Dev] The Amazing Unreferenced Weakref

This is all about current (3.6) trunk. In Objects/weakrefobject.c, we have the function PyObject_ClearWeakRefs(). This is called when a generic object that supports weakrefs is destroyed; this is the code that calls the callbacks. Here's a little paragraph of code from the center: for

[Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

The documentation for PyWeakref_GetObject() states: Return value: Borrowed reference. Return the referenced object from a weak reference, ref. If the referent is no longer live, returns Py_None. Given that the weakref doesn't have a reference to the object--merely a weak reference, d

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

On 10/10/2016 11:05 AM, Devin Jeanpierre wrote: > whose reference is it borrowing? I think this is a red herring sort of question. "borrowed" only means "unowned". But anyway, we borrowed from the weakref. (Borrowing from somebody doesn't imply they own a reference -- we can borrow from a b

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

On 10/10/2016 06:37 PM, Guido van Rossum wrote: Modified +1: you can't change the behavior of the existing API, but you can deprecate it and introduce a better one with a different name. We'll have until Python 4.0 to carry through the deprecation anyways. And I doubt this is the only C API chan

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

On 10/10/2016 09:36 PM, Chris Angelico wrote: Hmm. Here's a naughty, and maybe dangerous, theory. Obtain a "memory deallocation lock". While it is held (by any thread - it's a guard, more than a lock), Py_DECREF will not actually deallocate memory - objects can fall to zero references without be

[Python-Dev] Fwd: Re: PyWeakref_GetObject() borrows its reference from... whom?

Hit "Reply" instead of "Reply All" last night, oops. Forwarding to the list for posterity's sakes. / /arry/ Forwarded Message Subject: Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom? Date: Mon, 10 Oct 2016 23:

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

By the way, just to finish playing this new fun game "Who'd I Borrow This Reference From?": On 10/10/2016 11:45 AM, Chris Angelico wrote: On Mon, Oct 10, 2016 at 8:35 PM, Larry Hastings wrote: I bet for every other spot in the API I can tell you from whom you're bor

[Python-Dev] Playing games with reference counts (was Re: PyWeakref_GetObject() borrows its reference from... whom?)

On 10/10/2016 10:38 PM, Chris Angelico wrote: On Tue, Oct 11, 2016 at 8:14 AM, Larry Hastings wrote: These hacks where we play games with the reference count are mostly removed in my branch. That's exactly what I would have said, because I was assuming that refcounts would be accurate

Re: [Python-Dev] [Python-ideas] Show more info when `python -vV`

It is a New Feature and therefore ineligible for adding to 3.5 or 3.4. //arry/ On 10/17/2016 08:05 PM, Barry Warsaw wrote: On Oct 17, 2016, at 05:01 PM, Nick Coghlan wrote: * Inada-san would like to enable "python -VV" to print the full REPL header for improved debugging information * we d

Re: [Python-Dev] Python 2.7.13 release dates

On 11/28/2016 10:42 AM, Guido van Rossum wrote: Perhaps (un)related, is the release schedule for 3.5.3 set yet? (I'm holding off putting a new version of typing.py on typeshed until that's out.) Not set in stone, but I have a rough plan. I want the dust to settle around 3.6 first. So, have

[Python-Dev] Release schedule for 3.5.3 and 3.4.6

Here's the release schedule for Python versions 3.5.3 and 3.4.6. Sun Jan 1st, 2017 - tag 3.5.3rc1and 3.4.6rc1 Mon Jan 2nd, 2017 - release 3.5.3rc1and 3.4.6rc1 Sun Jan 15th, 2017 - tag 3.5.3 finaland 3.4.6final Mon Jan 16th, 2017 - release 3.5.3 finaland 3.4.6final The 3.5 branch

[Python-Dev] Someons's put a "Python 2.8" on GitHub

"Python 2.8 is a backwards-compatible Python interpreter with new features from Python 3.x. It was produced by forking Python 2.7.12 and backporting some of the new syntax, builtins, and libraries from Python 3. Python code and C-extensions targeting Python 2.7 or below are expected to run u

[Python-Dev] Should I delay 3.5.3 and 3.4.6 by two weeks?

Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and 3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle" around the release. I expect a flood of adoption of 3.6, and people switching will find bugs, and maybe those bugs are in 3.5 or 3.4. So it just seemed

Re: [Python-Dev] [python-committers] Should I delay 3.5.3 and 3.4.6 by two weeks?

100% of votes cast were for "don't slip", so we won't slip. Retreat! Full steam behind! //arry/ On 12/20/2016 02:25 AM, Matthias Klose wrote: On 19.12.2016 06:26, Larry Hastings wrote: Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and 3.4.6 to ship

[Python-Dev] Reminder: 3.5.3 rc1 and 3.4.6 rc1 tagged tomorrow

Just a reminder: I'll be tagging 3.5.3 rc1 and 3.4.6 rc1 tomorrow, Jan 1 2017, sometime between 24 and 36 hours from now. Please work quickly if there's anything you need to get in to either of those releases. I'm hoping that, for once, there are literally no code changes between rc1 and f

[Python-Dev] [RELEASED] Python 3.4.6rc1 and Python 3.5.3rc1 are now available

On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm pleased to announce the availability of Python 3.4.6rc1 and Python 3.5.6rc1. 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

[Python-Dev] [RELEASED] Python 3.4.6 and Python 3.5.3 are now available

On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm delighted to announce the availability of Python 3.4.6 and Python 3.5.3. 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 onl

Re: [Python-Dev] Can we use "designated initializer" widely in coremodules?

On 01/17/2017 12:02 PM, Steve Dower wrote: Avoiding header files would be my only request. As Brett says, the C99 requirement should not be enforced on all embedders or extenders, so we should try and keep the headers they'll use as compatible as possible. While that's a reasonable policy, u

Re: [Python-Dev] Can we use "designated initializer" widely in coremodules?

On 01/17/2017 04:48 PM, INADA Naoki wrote: On Wed, Jan 18, 2017 at 8:48 AM, Larry Hastings wrote: While that's a reasonable policy, unless we have a way to automatically detect that I suspect C99 stuff will creep into the header files and break the non-C99 customers. Maybe we could get

Re: [Python-Dev] Split Misc/NEWS into individual files

On 02/22/2017 08:26 AM, Eric V. Smith wrote: On 2/22/17 7:27 AM, Victor Stinner wrote: OpenStack happily fixed this issue one or two years ago with "reno": https://pypi.python.org/pypi/reno [...] What do you think of the overall idea? I'm for it. I'd be interested in hearing what current and fo

[Python-Dev] Signups for 2017 Python Language Summit are now open

(reposting, cc'ing python-dev) It’s that time again: time to start thinking about the Python Language Summit! The 2017 summit will be held on Wednesday, May 17, from 10am to 4pm, at the Oregon Convention Center in Portland, Oregon, USA. Your befezzled hosts Larry and Barry will once again be at

[Python-Dev] Wider Call For Participation for the 2017 Python Language Summit

ain this year. We all look forward to his thorough reporting of the event! [BL]arry (Barry Warsaw and Larry Hastings) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.py

[Python-Dev] The untuned tunable parameter ARENA_SIZE

When CPython's small block allocator was first merged in late February 2001, it allocated memory in gigantic chunks it called "arenas". These arenas were a massive 256 KILOBYTES apiece. This tunable parameter has not been touched in the intervening 16 years. Yet CPython's memory consumpti

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

On 06/01/2017 12:38 AM, Larry Hastings wrote: I propose we make the arena size larger. By how much? I asked Victor to run some benchmarks with arenas of 1mb, 2mb, and 4mb. The results with 1mb and 2mb were mixed, but his benchmarks with a 4mb arena size showed measurable (>5%) speedups

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

On 06/01/2017 12:57 AM, Victor Stinner wrote: I would prefer to have an adaptative arena size. For example start at 256 kB and then double the arena size while the memory usage grows. The problem is that pymalloc is currently designed for a fixed arena size. I have no idea how hard it would be to

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

On 06/01/2017 01:19 AM, Antoine Pitrou wrote: If you'd like to go that way anyway, I would suggest 1MB as a starting point in 3.7. I understand the desire for caution. But I was hoping maybe we could experiment with 4mb in trunk for a while? We could change it to 1mb--or even 256k--before b

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

On 06/01/2017 01:41 AM, Larry Hastings wrote: On 06/01/2017 01:19 AM, Antoine Pitrou wrote: malloc() you said? Arenas are allocated using mmap() nowadays, right? malloc() and free(). See _PyObject_ArenaMalloc (etc) in Objects/obmalloc.c. Oh, sorry, I forgot how to read. If ARENAS_USE_MMAP

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

On 06/01/2017 02:03 AM, Victor Stinner wrote: 2017-06-01 10:41 GMT+02:00 Larry Hastings : On 06/01/2017 01:19 AM, Antoine Pitrou wrote: If you'd like to go that way anyway, I would suggest 1MB as a starting point in 3.7. I understand the desire for caution. But I was hoping maybe we

Re: [Python-Dev] "Global freepool"

On 06/01/2017 02:20 AM, Victor Stinner wrote: I would like to understand how private free lists are "so much" faster. In fact, I don't recall if someone *measured* the performance speedup of these free lists :-) I have, recently, kind of by accident. When working on the Gilectomy I turned

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

On 06/01/2017 02:50 AM, Antoine Pitrou wrote: Another possible strategy is: allocate several arenas at once (using a larger mmap() call), and use MADV_DONTNEED to relinquish individual arenas. Thus adding a *fourth* layer of abstraction over memory we get from the OS? block -> pool -> aren

<    1   2   3   4   5   6   7   8   9   >