Re: [Python-Dev] New poll about a macro for safe reference replacing

On 17 December 2015 at 00:12, Serhiy Storchaka wrote: > The problem is only in the macro name. There are objections against any > proposed name, and no one name gained convincing majority. > > Here are names gained the largest numbers of votes plus names proposed > during polling. > > 1. Py_SETREF

Re: [Python-Dev] New poll about a macro for safe reference replacing

On 16/12/2015, Serhiy Storchaka wrote: > Here are names gained the largest numbers of votes plus names proposed > during polling. > > 1. Py_SETREF +0. I can live with it, but SET sounds like a complement to CLEAR, or that it ignores the old value. > 2. Py_DECREF_REPLACE +0.5 > 3. Py_REPLACE +1.

Re: [Python-Dev] async/await behavior on multiple calls

To briefly clarify/correct some of the C# statements that seem to keep being made: * C# produces a future/promise (spelled Task) for each call to an async function * awaiting a Task will return the result if its available, else schedule a continuation in the current loop (spelled synchronizatio

Re: [Python-Dev] async/await behavior on multiple calls

On 2015-12-16 1:11 AM, Nick Coghlan wrote: On 16 December 2015 at 11:41, Barry Warsaw wrote: The asyncio library documentation *really* needs a good overview and/or tutorial. These are difficult concepts to understand and it seems like bringing experience from other languages may not help (a

Re: [Python-Dev] New poll about a macro for safe reference replacing

On Wed, 16 Dec 2015 at 14:41 Yury Selivanov wrote: > > > Here are names gained the largest numbers of votes plus names proposed > > during polling. > > > > 1. Py_SETREF > > 2. Py_DECREF_REPLACE > > 3. Py_REPLACE > > 4. Py_SET_POINTER > > 5. Py_SET_ATTR > > 6. Py_REPLACE_REF > > > I like Py_SETREF

Re: [Python-Dev] New poll about a macro for safe reference replacing

Here are names gained the largest numbers of votes plus names proposed during polling. 1. Py_SETREF 2. Py_DECREF_REPLACE 3. Py_REPLACE 4. Py_SET_POINTER 5. Py_SET_ATTR 6. Py_REPLACE_REF I like Py_SETREF, so +1 for it. 0 for other names. Yury ___

Re: [Python-Dev] New poll about a macro for safe reference replacing

x2 for all of Victor's votes and reasoning. Top-posted from my Windows Phone -Original Message- From: "Victor Stinner" Sent: ‎12/‎17/‎2015 8:16 To: "Serhiy Storchaka" Cc: "Python Dev" Subject: Re: [Python-Dev] New poll about a macro for safe reference replacing 2015-12-16 15:12 GMT+01

Re: [Python-Dev] [Webmaster] Python keeps installing as 32 bit

Yeah, I was using Windows x86-64 executable installer from that page. I tried unzipping it just in case, no luck. I’m thinking I’ll probably just use 32-bit though. I found a post saying 64-bit might have issues compiling. I d

Re: [Python-Dev] New poll about a macro for safe reference replacing

2015-12-16 16:12 GMT+01:00 Serhiy Storchaka : > Originally I proposed pairs of functions with and withot X in the name (as > Py_DECREF/Py_XDECREF). In this poll this detail is omitted for clearness. > Later we can create a new poll if needed. I would prefer a single macro to avoid bugs, I don't th

Re: [Python-Dev] New poll about a macro for safe reference replacing

2015-12-16 15:12 GMT+01:00 Serhiy Storchaka : > Here are names gained the largest numbers of votes plus names proposed > during polling. > > 1. Py_SETREF +1: obvious name > 2. Py_DECREF_REPLACE -1: too long > 3. Py_REPLACE 0: less explicit than but: not mention of reference > 4. Py_SET_POINTE

Re: [Python-Dev] [Webmaster] Python keeps installing as 32 bit

I can say for certain that Python 3.5.1 will install as 64-bit as that's what I'm personally running on the Windows 10 laptop that I'm writing this email on. If you look at https://www.python.org/downloads/release/python-351/ you will notice there are explicit 64-bit installers that you can use. D

Re: [Python-Dev] [Webmaster] Python keeps installing as 32 bit

Hi Robb, This address is really for web site issues, but we are mostly old hands, and reasonably well-connected, so we try to act as a helpful channel when we can. In this case I can't personally help (though another webmaster may, if available, be able to offer advice). I stopped doing system ad

Re: [Python-Dev] async/await behavior on multiple calls

> On Dec 16, 2015, at 03:25, Paul Sokolovsky wrote: > > Hello, > > On Tue, 15 Dec 2015 17:29:26 -0800 > Roy Williams wrote: > >> @Kevin correct, that's the point I'd like to discuss. Most other >> mainstream languages that implements async/await expose the >> programming model with Tasks/Futu

Re: [Python-Dev] async/await behavior on multiple calls

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/16/2015 01:11 AM, Nick Coghlan wrote: > One smaller step that may be helpful is changing the titles of a > couple of the sections from: > > * 18.5.4. Transports and protocols (low-level API) * 18.5.5. Streams > (high-level API) > > to: > > *

Re: [Python-Dev] async/await behavior on multiple calls

On Wed, Dec 16, 2015 at 1:50 AM, Roy Williams wrote: > I totally agree that async/await should not be tied to any underlying > message pump/event loop. Ensuring that async/await works with existing > systems like Tornado is great. > > As for the two options, option 1 is the expected behavior fro

Re: [Python-Dev] New poll about a macro for safe reference replacing

Serhiy Storchaka writes: >> I'm not entirely sure of the benefit of a macro over an inline >> function. > > Because the first argument is passed by reference (as in Py_INCREF > etc). Then a macro implemented using an inline function, e.g., #define Py_REPLACE(p, x) Py_REPLACE_impl(&(p), x). Were

Re: [Python-Dev] New poll about a macro for safe reference replacing

On December 16, 2015 8:12:47 AM CST, Serhiy Storchaka wrote: >I'm bringing this up again, since the results of the previous poll did >not give an unambiguous result. Related links: [1], [2], [3], [4]. > >Let me remind you that we are talking about adding the following macro. > >It is needed fo

Re: [Python-Dev] New poll about a macro for safe reference replacing

On 16.12.15 16:53, Random832 wrote: At the risk of bikeshedding, this needs do { ... } while(0), or it almost certainly will eventually be called incorrectly in an if/else statement. Yes, it's ugly, but that's part of the cost of using macros. Yes, of course, and the patch for issue20440 uses

Re: [Python-Dev] New poll about a macro for safe reference replacing

Serhiy Storchaka writes: > I'm bringing this up again, since the results of the previous poll did > not give an unambiguous result. Related links: [1], [2], [3], [4]. > > Let me remind you that we are talking about adding the following > macro. It is needed for safe replacement links. For now ther

Re: [Python-Dev] async/await behavior on multiple calls

On 2015-12-16 12:55 AM, Kevin Conway wrote: I think the list is trying to tell you that awaiting a coro multiple times is simply not a valid case in Python because they are exhaustible resources. In asyncio, they are primarily a helpful mechanism for shipping promises to the Task wrapper. In

[Python-Dev] New poll about a macro for safe reference replacing

I'm bringing this up again, since the results of the previous poll did not give an unambiguous result. Related links: [1], [2], [3], [4]. Let me remind you that we are talking about adding the following macro. It is needed for safe replacement links. For now there is at least one open crash re

Re: [Python-Dev] async/await behavior on multiple calls

Hello, On Tue, 15 Dec 2015 17:29:26 -0800 Roy Williams wrote: > @Kevin correct, that's the point I'd like to discuss. Most other > mainstream languages that implements async/await expose the > programming model with Tasks/Futures/Promises as opposed to > coroutines PEP 492 states 'Objects with

Re: [Python-Dev] async/await behavior on multiple calls

I totally agree that async/await should not be tied to any underlying message pump/event loop. Ensuring that async/await works with existing systems like Tornado is great. As for the two options, option 1 is the expected behavior from developers coming from other languages implementing async/awai

Re: [Python-Dev] Python semantic: Is it ok to replace not x == y with x != y? (no)

On 15.12.15 15:04, Victor Stinner wrote: Should Python emit a warning when __eq__() is implemented but not __ne__()? No. Actually I had removed a number of redundant (and often incorrect) __ne__ implementations after fixing object.__ne__. Should Python be modified to call "not __eq__()" whe