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

[Brett Cannon]

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. Did you
get your copy of Python by going straight to python.org/download and
clicking the yellow "Download Python 3.5.1" button?

On Wed, 16 Dec 2015 at 12:33 Steve Holden  wrote:

> 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 administration
> for anything but my own machines a long time ago, having done far too much
> :-)
>
> The many mailing list channels available are listed at
> https://mail.python.org/mailman/listinfo. I would recommend that you try
> the distutils list at
> https://mail.python.org/mailman/listinfo/distutils-sig; they don't
> actually build the Python installers (the dev who does that lives on
> python-dev, so that would be the place to go to get the scoop, and your
> email shows enough signs of competence that you need not fear adverse
> reactions). It seems like a reasonable enquiry to me, and I'm sorry I can't
> answer it.
>
> I've Cc'd this email to python-dev on the off-chance that someone will
> recognise my name and let it through, but I don't know how many people are
> working on the Windows installer or how busy they are.
>
> There are plenty of people smart enough to answer your question out there
> now, it's just a question of finding them. stackoverflow.com has a pretty
> good Python channel too.
>
> In any case, good luck, and thanks for reaching out to Python.
>
> regards
>  Steve
>
> On Wed, Dec 16, 2015 at 7:29 PM, Mullins, Robb 
> wrote:
>
>> Hi,
>>
>>
>>
>> Not quite sure where to ask this.
>>
>>
>>
>> I don’t use Python myself.  I keep user desktops updated.  Everything’s
>> 64-bit.  In the past I was able to install 32-bit Python on 32-bit machines
>> and 64-bit Python on 64-bit machines.  Now it’s just the one msi file to
>> install, at least for 3.5.1.  I do have a couple Python 2.7.9 users.
>> We’re all 64-bit for machines, but I keep having Python install as 32-bit.
>> I’m not sure if it recognizes something on the machine and matches it for
>> being 32-bit that I’m not aware of.  It can be tricky to uninstall, so it
>> becomes a slight issue.  I just want to get 64-bit Python on my user
>> machines, unless it’s not possible.
>>
>>
>>
>> Is there a better place to ask this?
>>
>>
>>
>>
>>
>> Thanks,
>>
>> RM
>>
>>
>>
>> Desktop Support Specialist
>>
>> Center for Innovation in Teaching & Learning
>>
>> citl-techsupp...@mx.uillinois.edu *(For computer issues, please use the
>> ticket system.)*
>>
>> (217) 333-2146
>>
>>
>>
>> ___
>> Webmaster mailing list
>> webmas...@python.org
>> https://mail.python.org/mailman/listinfo/webmaster
>>
>>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Andrew Barnert via Python-Dev]

> 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/Futures/Promises as opposed to
>> coroutines  PEP 492 states 'Objects with __await__ method are called
>> Future-like objects in the rest of this PEP.' but their behavior
>> differs from that of Futures in this core way.  Given that most other
>> languages have standardized around async returning a Future as
>> opposed to a coroutine I think it's worth exploring why Python
>> differs.
> 
> Sorry, but what makes you think that it's worth exploring why Python
> Python differs, and not why other languages differ?

They're really the same question.

Python differs from C# in that it builds async on top of language-level 
coroutines instead of hiding them under the hood, it only requires a simple 
event loop (which can be trivially built on a select-like function and a loop) 
rather than a powerful OS/VM-level task scheduler, it's designed to allow 
pluggable schedulers (maybe even multiple schedulers in one app), it doesn't 
have a static type system to assist it, ... Turn it around and ask how C# 
differs from Python and you get the same differences. And there's no value 
judgment either way.

So, do any of those explain why some Python awaitables aren't safely 
re-awaitable? Yes: the fact that Python uses language-level coroutines instead 
of hiding them under the covers means that it makes sense to be able to 
directly await coroutines (and to make async functions return those coroutines 
when called), which raises a question that doesn't exist in C#.

What happens when you await an already-consumed awaitables? That question 
doesn't arise in C# because it doesn't have consumable awaitables. Python 
_could_ just punt on that by not allowing coroutines to be awaitable, or 
auto-wrapping them, but that would be giving up a major positive benefit over 
C#. So, that means Python instead has to decide what happens.

In general, the semantics of awaiting an awaitable are that you get its value 
or an exception. Can you preserve those semantics even with raw coroutines as 
awaitables? Sure; as two people have pointed out in this thread, just make 
awaiting a consumed coroutine raise. Problem solved. But if nobody had asked 
about the differences between Python and C#, it would have been a lot harder to 
solve (or even see) the question.

> Also, what "most other languages" do you mean?

Well, what he said was "Most other mainstream languages that implements 
async/await". But you're right; clearly what he meant was just C#, because 
that's the only other mainstream language that implements async/await today. 
Others (JS, Scala) are implementing it or considering doing so, but, just like 
Python, they're borrowing it from C# anyway. (Unless you want to call F# async 
blocks and let! binding the same feature--but if so, C# borrowed from F# and 
everyone else borrowed from C#, so it's still the same.)

> Lua was a pioneer of
> coroutine usage in scripting languages, with research behind that.
> It doesn't have any "futures" or "promises" as part of the language.
> It has only coroutines. For niche cases when "futures" or "promises"
> needed, they can be implemented on top of coroutines.
> 
> And that's actually the problem with Python's asyncio - it tries to
> marry all the orthogonal concurrency concepts, unfortunately good
> deal o'mess ensues.

The fact that futures can be built on top of coroutines, or on top of promises 
and callbacks, means they're a way to tie together pieces of asynchronous code 
written in different styles. And the idea of a simple supertype of both futures 
and coroutines that's sufficient for a large set of problems, means you rarely 
need wrappers to transform one into the other; just use whichever one you have 
as an awaitable and it works.

So, you can write 80% of your code in terms of awaitables, but if the last 20% 
needs to get at the native coroutines, or to integrate with legacy code using 
callbacks, it's easy to do so. In C#, you instead have to simulate those 
coroutines with promises even when you're not integrating with legacy code; in 
a language without futures you'd have to wrap each call into and out of legacy 
code manually.

If you were designing a new language, you could probably get away with 
something a lot simpler. (If the only thing you could ever need a future for is 
to cache an awaitable value, it's a one-liner.) But for Python (and JS, Scala, 
C#, etc.) that isn't an option.

> It doesn't help on "PR" side too, because coroutine
> lovers blame it for not being based entirely on language's native
> coroutines, strangers from other languages want to twist it to be based
> entirely on foreign concepts like futures, Twisted haters hate 

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

[Victor Stinner]

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_POINTER

-1: a reference is not a pointer

> 5. Py_SET_ATTR

-1: it's not an attribute

> 6. Py_REPLACE_REF

+0.5: close to Py_SETREF, but longer and if I recall correctly "set"
is more common than "replace" in the Python language

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steve Holden]

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 administration
for anything but my own machines a long time ago, having done far too much
:-)

The many mailing list channels available are listed at
https://mail.python.org/mailman/listinfo. I would recommend that you try
the distutils list at https://mail.python.org/mailman/listinfo/distutils-sig;
they don't actually build the Python installers (the dev who does that
lives on python-dev, so that would be the place to go to get the scoop, and
your email shows enough signs of competence that you need not fear adverse
reactions). It seems like a reasonable enquiry to me, and I'm sorry I can't
answer it.

I've Cc'd this email to python-dev on the off-chance that someone will
recognise my name and let it through, but I don't know how many people are
working on the Windows installer or how busy they are.

There are plenty of people smart enough to answer your question out there
now, it's just a question of finding them. stackoverflow.com has a pretty
good Python channel too.

In any case, good luck, and thanks for reaching out to Python.

regards
 Steve

On Wed, Dec 16, 2015 at 7:29 PM, Mullins, Robb 
wrote:

> Hi,
>
>
>
> Not quite sure where to ask this.
>
>
>
> I don’t use Python myself.  I keep user desktops updated.  Everything’s
> 64-bit.  In the past I was able to install 32-bit Python on 32-bit machines
> and 64-bit Python on 64-bit machines.  Now it’s just the one msi file to
> install, at least for 3.5.1.  I do have a couple Python 2.7.9 users.
> We’re all 64-bit for machines, but I keep having Python install as 32-bit.
> I’m not sure if it recognizes something on the machine and matches it for
> being 32-bit that I’m not aware of.  It can be tricky to uninstall, so it
> becomes a slight issue.  I just want to get 64-bit Python on my user
> machines, unless it’s not possible.
>
>
>
> Is there a better place to ask this?
>
>
>
>
>
> Thanks,
>
> RM
>
>
>
> Desktop Support Specialist
>
> Center for Innovation in Teaching & Learning
>
> citl-techsupp...@mx.uillinois.edu *(For computer issues, please use the
> ticket system.)*
>
> (217) 333-2146
>
>
>
> ___
> Webmaster mailing list
> webmas...@python.org
> https://mail.python.org/mailman/listinfo/webmaster
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Victor Stinner]

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 think that such
macro has a critical impact on performances. It's more designed for
safety, no?

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 from developers
> coming from other languages implementing async/await which is why I found
> the existing behavior to be so unintuitive.  To Barry and Kevin's point,
> this problem is exacerbated by a lack of documentation and examples that
> one can follow to learn about the Pythonic approach to async/await.
>

I don't disagree that more intro docs are needed.

However, just to cut short a fruitless discussion, there is zero chance
that Python will change (nor is there any chance that the other languages
will change). Language features that look the same often don't behave the
same (e.g. variables in Python are entirely different beasts than in C#,
and also behave quite differently from variables in JavaScript). Also, if
you aren't giving up on changing Python, please move to python-ideas, which
is the designated place to discuss possible language changes.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tres Seaver]

-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:
> 
> * 18.5.4. Transports and protocols (callback based API) * 18.5.5.
> Streams (coroutine based API)
> 
> That's based on a sample size of one though (a friend for whom light 
> dawned once I explained that low-level=callbacks and 
> high-level=coroutines), which is why I hadn't written a patch for it.

+1.  That certainly tripped the switch for me.  I wish more of the
asyncio stuff would illuminate itself so smoothly. ;)


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWcbN/AAoJEPKpaDSJE9HYbyUQAJIzzMz7ksUucMZWyF5PvSyg
r0Y1ULmGeLxXloR1hw26ToKQe4EvcgUXU39sIE2Ck7HyDtNHl8CorMyd0aVkcjKW
zFODj0DsEvphlQk+vQPnZZhWxb8xuKlsWmr2PqSZdVRlGK+xkaraSzJsa+loI70/
Vw8FipfS1ytpq1qlI3i8h4UWZLg+CPsa96Lgwz+GW+TmYawYHjzCr/NNhlT6UnsA
JoGxRLZpNOgYeS6/Xo7p2gBOz8MZxE3e7UNeHmE2H96aIz7n6E6A3EKsJ2ms9kWy
cjuMJ21N+SmSODXfBxovfiTOE0QJ+GAqRc26vWWjbYqTrtmPrg8F7tCrGZlpILsK
sYNJvUAzWCgOhG3eI/SJ8NHVdfuPszPdDVZvm2jk0om2UKMjXKmoxago5aW7Ijb7
T9sLLVUWuvxx/54QkJEaFdLYwmEK2DnyVdNvPf7xrMNtKfXrsmFxxtnSjN3pSkuK
tucucR7VVlM2Bm1uxwB7Oqqks44lthEU0LNWNiurujOFX8sUpgIy9rSPntv/7mnK
f44v43Rmshshc3SrPAJuzafpAG4kPrM2J6PTF4OSNwg5ZYj8hlMPI6vIdsrX/q7U
iJKbyYkHAY09yjYOASmTYUXTS/2gyjMG6uKgIabBuQmVhWR63ezlq1D17aCHCVBG
hM0dlyReGudfk/0jM6NW
=II0x
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steve Dower]

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

-1: a reference is not a pointer

> 5. Py_SET_ATTR

-1: it's not an attribute

> 6. Py_REPLACE_REF

+0.5: close to Py_SETREF, but longer and if I recall correctly "set"
is more common than "replace" in the Python language

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Mullins, Robb]

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 don’t think users will know or care.  
And there x86 installers are there.
http://www.howtogeek.com/197947/how-to-install-python-on-windows/
[cid:image001.jpg@01D13810.EF3A90C0]
The only other thing I was thinking was something with the chip maybe.  I ran 
into this about a year ago.  (Or more now…)  I Python down for 32 vs 64-bit.  
Then I noticed some 64-bit machines were still doing 32-bit, but I only have 
the x86-64.exe.  I can’t force x64 on it.
It’s not a huge issue at this point.  Once I figure it out, it will save time.  
I’m planning on manually uninstalling versions of Python and then installing 
the current one (leaning toward x86 now) so all the user machines are 
consistent.

Thanks,
Robb




Desktop Support Specialist
Center for Innovation in Teaching & Learning
citl-techsupp...@mx.uillinois.edu 
(For computer issues, please use the ticket system.)
(217) 333-2146

From: Brett Cannon [mailto:br...@python.org]
Sent: Wednesday, December 16, 2015 2:39 PM
To: Steve Holden ; Mullins, Robb 
Cc: webmas...@python.org; python-dev@python.org
Subject: 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. Did you 
get your copy of Python by going straight to 
python.org/download
 and clicking the yellow "Download Python 3.5.1" button?

On Wed, 16 Dec 2015 at 12:33 Steve Holden 
> wrote:
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 administration for 
anything but my own machines a long time ago, having done far too much :-)

The many mailing list channels available are listed at 
https://mail.python.org/mailman/listinfo.
 I would recommend that you try the distutils list at 
https://mail.python.org/mailman/listinfo/distutils-sig;
 they don't actually build the Python installers (the dev who does that lives 
on python-dev, so that would be the place to go to get the scoop, and your 
email shows enough signs of competence that you need not fear adverse 
reactions). It seems like a reasonable enquiry to me, and I'm sorry I can't 
answer it.

I've Cc'd this email to python-dev on the off-chance that someone will 
recognise my name and let it through, but I don't know how many people are 
working on the Windows installer or how busy they are.

There are plenty of people smart enough to answer your question out there now, 
it's just a question of finding them. 
stackoverflow.com
 has a pretty good Python channel too.

In any case, good luck, and thanks for reaching out to Python.

regards
 Steve

On Wed, Dec 16, 2015 at 7:29 

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

[Yury Selivanov]

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
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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, so +1 for it.  0 for other names.
>

+1 for Py_SETREF.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steve Dower]

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 synchronization context)
 - you can have multiple such loops in a single thread though it makes things 
confusing (by extension, you can also have multiple per process, which is 
better)
* results stick around until the Task is garbage collected, so you can await a 
task multiple times
* async/await in C# is a compile time transform - you could hand-code exactly 
equivalent behavior in terms of Task if you so desired

As someone who's dealt extensively with using, debugging and implementing C# 
awaiters, Python's approach is very similar. The main difference is that async 
creates something similar, but lighter weight than a regular future.

Cheers,
Steve

Top-posted from my Windows Phone

-Original Message-
From: "Andrew Barnert via Python-Dev" 
Sent: ‎12/‎17/‎2015 6:37
To: "Paul Sokolovsky" 
Cc: "Python-Dev" 
Subject: 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/Futures/Promises as opposed to
>> coroutines  PEP 492 states 'Objects with __await__ method are called
>> Future-like objects in the rest of this PEP.' but their behavior
>> differs from that of Futures in this core way.  Given that most other
>> languages have standardized around async returning a Future as
>> opposed to a coroutine I think it's worth exploring why Python
>> differs.
> 
> Sorry, but what makes you think that it's worth exploring why Python
> Python differs, and not why other languages differ?

They're really the same question.

Python differs from C# in that it builds async on top of language-level 
coroutines instead of hiding them under the hood, it only requires a simple 
event loop (which can be trivially built on a select-like function and a loop) 
rather than a powerful OS/VM-level task scheduler, it's designed to allow 
pluggable schedulers (maybe even multiple schedulers in one app), it doesn't 
have a static type system to assist it, ... Turn it around and ask how C# 
differs from Python and you get the same differences. And there's no value 
judgment either way.

So, do any of those explain why some Python awaitables aren't safely 
re-awaitable? Yes: the fact that Python uses language-level coroutines instead 
of hiding them under the covers means that it makes sense to be able to 
directly await coroutines (and to make async functions return those coroutines 
when called), which raises a question that doesn't exist in C#.

What happens when you await an already-consumed awaitables? That question 
doesn't arise in C# because it doesn't have consumable awaitables. Python 
_could_ just punt on that by not allowing coroutines to be awaitable, or 
auto-wrapping them, but that would be giving up a major positive benefit over 
C#. So, that means Python instead has to decide what happens.

In general, the semantics of awaiting an awaitable are that you get its value 
or an exception. Can you preserve those semantics even with raw coroutines as 
awaitables? Sure; as two people have pointed out in this thread, just make 
awaiting a consumed coroutine raise. Problem solved. But if nobody had asked 
about the differences between Python and C#, it would have been a lot harder to 
solve (or even see) the question.

> Also, what "most other languages" do you mean?

Well, what he said was "Most other mainstream languages that implements 
async/await". But you're right; clearly what he meant was just C#, because 
that's the only other mainstream language that implements async/await today. 
Others (JS, Scala) are implementing it or considering doing so, but, just like 
Python, they're borrowing it from C# anyway. (Unless you want to call F# async 
blocks and let! binding the same feature--but if so, C# borrowed from F# and 
everyone else borrowed from C#, so it's still the same.)

> Lua was a pioneer of
> coroutine usage in scripting languages, with research behind that.
> It doesn't have any "futures" or "promises" as part of the language.
> It has only coroutines. For niche cases when "futures" or "promises"
> needed, they can be implemented on top of coroutines.
> 
> And that's actually the problem with Python's asyncio - it tries to
> marry all the orthogonal concurrency concepts, unfortunately good
> deal o'mess ensues.

The fact that futures can be built on top of coroutines, or on top of promises 
and callbacks, means they're a way to 

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

[Nick Coghlan]

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

+1 if it always uses Py_XDECREF on the previous value (as I'd expect
this to work even if the previous value was NULL)

-0 for a Py_SETREF/Py_XSETREF pair (the problem I see is that it's
unclear that it's the target location that's allowed to be NULL in the
latter case)

> 2. Py_DECREF_REPLACE

-1: too long

> 3. Py_REPLACE

+0 if it uses Py_DECREF on the previous value as part of a
Py_REPLACE/Py_SETREF pair

However, I'm not sure we need the micro-optimisation offering by
skipping the "Is the previous value NULL?" check, and it's always
easier to add an API later than it is to remove one.

> 4. Py_SET_POINTER

-1: As Victor says, "pointer" tends to mean "void *" in out C code,
not "PyObject *".

> 5. Py_SET_ATTR

-1: This operation is useful for updating any reachable reference to
another object, not just attributes

> 6. Py_REPLACE_REF

-0: this is like 3, only with a slightly longer name

I'm also in favour of Serhiy claiming the casting vote if there's no
clear consensus :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Martin Panter]

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. Fairly obvious what it does.

> 4. Py_SET_POINTER
-1
> 5. Py_SET_ATTR
-1 ** -1. What’s the attribute name?

> 6. Py_REPLACE_REF
+0.5

Ryan’s Py_RESET: -1, it sounds too much like CLEAR
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Yury Selivanov]

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 (and may even hinder)
understanding of Python's model.  After a while, you get it, but I think it
would be good to help folks get there sooner, especially if you're new to the
whole area.

Maybe those of you who have been steeped in asyncio for a long time could
write that up?  I don't think I'm the right person to do that, but I'd be very
happy to review it.

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:

* 18.5.4. Transports and protocols (callback based API)
* 18.5.5. Streams (coroutine based API)

That's based on a sample size of one though (a friend for whom light
dawned once I explained that low-level=callbacks and
high-level=coroutines), which is why I hadn't written a patch for it.


Nick, I've applied your suggested change in
https://hg.python.org/cpython/rev/f02c61f08333

I think it makes sense, as at least it gives some useful
information about the section.  "low-level" and "high-level"
start to mean something when you already understand asyncio
pretty well.

Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Sokolovsky]

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 __await__ method are called
> Future-like objects in the rest of this PEP.' but their behavior
> differs from that of Futures in this core way.  Given that most other
> languages have standardized around async returning a Future as
> opposed to a coroutine I think it's worth exploring why Python
> differs.

Sorry, but what makes you think that it's worth exploring why Python
Python differs, and not why other languages differ? For example,
JavaScript has hard heritage of callback mess. To address that at least
somehow, Promises where introduced, which is still too low-level
concurrency mechanism. When they finally picked up coroutines, they
still have to be carry all that burden of callback mess and
Promises, and that's why "ES7" differs.

Also, what "most other languages" do you mean? Lua was a pioneer of
coroutine usage in scripting languages, with research behind that.
It doesn't have any "futures" or "promises" as part of the language.
It has only coroutines. For niche cases when "futures" or "promises"
needed, they can be implemented on top of coroutines.

And that's actually the problem with Python's asyncio - it tries to
marry all the orthogonal concurrency concepts, unfortunately good
deal o'mess ensues. It doesn't help on "PR" side too, because coroutine
lovers blame it for not being based entirely on language's native
coroutines, strangers from other languages want to twist it to be based
entirely on foreign concepts like futures, Twisted haters hate that it
has too much complication taken from Twisted, etc.

> 
> There's a lot of benefits to making the programming model coroutines
> without a doubt.  It's absolutely brilliant that I can just call code
> annotated with @asyncio.coroutine and have it just work.  Code using
> the old @asyncio.coroutine/yield from syntax should absolutely stay
> the same. Similarly, since ES7 async/await is backed by Promises
> it'll just work for any existing code out there using Promises.
> 
> My proposal would be to automatically wrap the return value from an
> `async` function or any object implementing `__await__` in a future
> with `asyncio.ensure_future()`.  This would allow async/await code to
> behave in a similar manner to other languages implementing
> async/await and would remain compatible with existing code using
> asyncio.
> 
> What's your thoughts?

My thought is "what other languages told when you approached them with
the proposal to behave like Python?".

Also, wrapping objects in other objects is expensive. Especially if
the latter kind of objects isn't really needed - it's perfectly
possibly to write applications which don't use or need any futures at
all, using just coroutines. Moreover, some people argue that most apps
real people would write are such, and Futures are niche feature, so
can't be center of the world.

> 
> Thanks,
> Roy
> 

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Yury Selivanov]

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 virtually all 
cases the pattern is:


> await some_async_def()

and almost never:

> coro = some_async_def()
> await coro



That's exactly right, thank you, Kevin.

Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Random832]

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 there is at
> least one open crash report that can be solved with this macro [5] (I
> think there is yet one, but can't find it just now). And 50 potential
> bugs for which we just still do not have a reproducer.
>
> #define Py_XXX(ptr, value)\
> { \
> PyObject *__tmp__ = ptr;  \
> ptr = new_value;  \
> Py_DECREF(__tmp__);   \
> }

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.

If it were implemented as below, then it could evaluate ptr only
once at the cost of requiring it to refer to an addressable
pointer object:
PyObject **__tmpp__ == &(ptr);
PyObject *__tmp__ = *__tmpp__;
*__tmpp__ = (new_value);
PY_DECREF(__tmp__);

I'm not entirely sure of the benefit of a macro over an inline
function.  Or why it doesn't INCREF the new value, maintaining
the invariant that ptr is an owned reference.

> 1. Py_SETREF
> 2. Py_DECREF_REPLACE
> 3. Py_REPLACE
> 4. Py_SET_POINTER
> 5. Py_SET_ATTR
> 6. Py_REPLACE_REF

I think "SET" names imply that it's safe if the original
reference is NULL. This isn't an objection to the names, but if
it is given one of those names I think it should use Py_XDECREF.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 report that can be solved with this macro [5] (I think there 
is yet one, but can't find it just now). And 50 potential bugs for which 
we just still do not have a reproducer.


#define Py_XXX(ptr, value)\
{ \
PyObject *__tmp__ = ptr;  \
ptr = new_value;  \
Py_DECREF(__tmp__);   \
}

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
2. Py_DECREF_REPLACE
3. Py_REPLACE
4. Py_SET_POINTER
5. Py_SET_ATTR
6. Py_REPLACE_REF

Please put your vote (a floating number from -1 to 1 including) for 
every of proposed name. You also can propose new name.



[1] https://mail.python.org/pipermail/python-dev/2008-May/079862.html
[2] http://comments.gmane.org/gmane.comp.python.devel/145346
[3] http://comments.gmane.org/gmane.comp.python.devel/145974
[4] http://bugs.python.org/issue20440
[5] http://bugs.python.org/issue24103

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 this idiom. Here it is 
omitted for clearness.



If it were implemented as below, then it could evaluate ptr only
once at the cost of requiring it to refer to an addressable
pointer object:
 PyObject **__tmpp__ == &(ptr);
 PyObject *__tmp__ = *__tmpp__;
 *__tmpp__ = (new_value);
 PY_DECREF(__tmp__);

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).


Or why it doesn't INCREF the new value, maintaining
the invariant that ptr is an owned reference.


Because in the majority of using cases stealing a reference is what is 
needed. Otherwise we would virtually always need to decref a reference 
just after using this macro. And couldn't use it as Py_XXX(obj->attr, 
PySomething_New()).



I think "SET" names imply that it's safe if the original
reference is NULL. This isn't an objection to the names, but if
it is given one of those names I think it should use Py_XDECREF.


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.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

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 for safe replacement links. For now there is at least one 
>open crash report that can be solved with this macro [5] (I think there
>
>is yet one, but can't find it just now). And 50 potential bugs for
>which 
>we just still do not have a reproducer.
>
>#define Py_XXX(ptr, value)\
> { \
> PyObject *__tmp__ = ptr;  \
> ptr = new_value;  \
> Py_DECREF(__tmp__);   \
> }
>
>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
>2. Py_DECREF_REPLACE
>3. Py_REPLACE
>4. Py_SET_POINTER
>5. Py_SET_ATTR
>6. Py_REPLACE_REF
>

5 kinda sucks, since this has virtually nothing to do with attributes. 3 sounds 
like it does an operation on the object itself. 4 sounds stupid.

So:

1. +0
2. +0.5
3. -1
4. -1
5. -1
6. +1

>Please put your vote (a floating number from -1 to 1 including) for 
>every of proposed name. You also can propose new name.
>

Py_RESET? Like C++'s shared_ptr::reset: 
http://en.cppreference.com/w/cpp/memory/shared_ptr/reset.

>
>[1] https://mail.python.org/pipermail/python-dev/2008-May/079862.html
>[2] http://comments.gmane.org/gmane.comp.python.devel/145346
>[3] http://comments.gmane.org/gmane.comp.python.devel/145974
>[4] http://bugs.python.org/issue20440
>[5] http://bugs.python.org/issue24103
>
>___
>Python-Dev mailing list
>Python-Dev@python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Random832]

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 INCREF
implemented this way it could return the reference (imagine
Py_REPLACE(foo, Py_INCREF(bar))).  The other advantage to an inline
function is that it lets the compiler make the decision about optimizing
for size or time.
 
>> I think "SET" names imply that it's safe if the original
>> reference is NULL. This isn't an objection to the names, but if
>> it is given one of those names I think it should use Py_XDECREF.
>
> 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 think that any variant on "SET" strongly implies that it need not have
already been set, and think even a "SET/REPLACE" pair would be better
than "XSET/SET".

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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__()" when __ne__() is not
implemented?


__ne__() always is implemented (inherited from object). Default __ne__ 
implementation calls __eq__() and negate it's result (if not 
NotImplemented).


But user class can define __ne__ with arbitrary semantic. That is the 
purpose of adding __ne__.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Roy Williams]

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/await which is why I found
the existing behavior to be so unintuitive.  To Barry and Kevin's point,
this problem is exacerbated by a lack of documentation and examples that
one can follow to learn about the Pythonic approach to async/await.

Thanks,
Roy

On Tue, Dec 15, 2015 at 7:33 PM, Yury Selivanov 
wrote:

> Roy,
>
> On 2015-12-15 8:29 PM, Roy Williams wrote:
> [..]
>
>>
>> My proposal would be to automatically wrap the return value from an
>> `async` function or any object implementing `__await__` in a future with
>> `asyncio.ensure_future()`.  This would allow async/await code to behave in
>> a similar manner to other languages implementing async/await and would
>> remain compatible with existing code using asyncio.
>>
>> What's your thoughts?
>>
>
> Other languages, such as JavaScript, have a notion of event loop
> integrated on a very deep level.  In Python, there is no centralized event
> loop, and asyncio is just one way of implementing one.
>
> In asyncio, Future objects are designed to inter-operate with an event
> loop (that's also true for JS Promises), which means that in order to
> automatically wrap Python coroutines in Futures, we'd have to define the
> event loop deep in Python core.  Otherwise it's impossible to implement
> 'Future.add_done_callback', since there would be nothing that calls the
> callbacks on completion.
>
> To avoid adding a built-in event loop, PEP 492 introduced coroutines as an
> abstract language concept.  David Beazley, for instance, doesn't like
> Futures, and his new framework 'curio' does not have them at all.
>
> I highly doubt that we want to add a generalized event loop in Python
> core, define a generalized Future interface, and make coroutines return
> it.  It's simply too much work with no clear wins.
>
> Now, your initial email highlights another problem:
>
>coro = coroutine()
>print(await coro)  # will print the result of coroutine
>await coro  # prints None
>
> This is a bug that needs to be fixed.  We have two options:
>
> 1. Cache the result when the coroutine object is awaited first time.
> Return the cached result when the coroutine object is awaited again.
>
> 2. Raise an error if the coroutine object is awaited more than once.
>
> The (1) option would solve your problem.  But it also introduces new
> complexity: the GC of result will be delayed; more importantly, some users
> will wonder if we cache the result or run the coroutine again.  It's just
> not obvious.
>
> The (2) option is Pythonic and simple to understand/debug, IMHO.  In this
> case, the best way for you to solve your initial problem, would be to have
> a decorator around your tasks.  The decorator should wrap coroutines with
> Futures (with asyncio.ensure_future) and everything will work as you expect.
>
> Thanks,
> Yury
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rwilliams%40lyft.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com