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.

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

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

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

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

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

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] 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

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

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

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.

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

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

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

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

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

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

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

[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: [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

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

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)

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__()"

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