On Thu, Jun 25, 2015 at 05:55:53PM +0200, Sven R. Kunze wrote:
>
> On 25.06.2015 04:16, Steven D'Aprano wrote:
> >On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
[...]
> >>What is the difference of a function (no awaits) or an awaitable (> 1
> >>awaits) from an end-user's perspectiv
Sven R. Kunze wrote:
# Call func syncronously, blocking until the calculation is done:
x = func()
# Call func asyncronously, without blocking:
y = await func()
Using the word "blocking" this way is potentially
confusing. The calling task is *always* blocked until
the operation completes. The
For one time, while we are in a congratulations tunnel, thank you a lot
AsyncIO core devs:
Since several months, we've pushed on production an average of 2 daemons
based on AsyncIO in my company with several protocols.
Most of the time there are small daemons, however, some are complex.
For now, t
Hi,
2015-06-25 19:25 GMT+02:00 Andrew Svetlov :
> P.S.
> Thank you Victor so much for your work on asyncio.
> Your changes on keeping source tracebacks and raising warnings for
> unclosed resources are very helpful.
Ah! It's good to know. You're welcome.
We can still enhance the source traceback
Zachary Ware wrote:
> On Thu, Jun 25, 2015 at 10:42 AM, Steve Dower
> wrote:
>> This also makes it more viable to use the Windows SDK compilers. If you
>> install the Windows SDK 7.0 (which includes MSVC9) and Windows SDK 7.1 (which
>> includes the platform toolset files for MSVC9 - toolsets were
Hello Elizabeth,
On Thu, 25 Jun 2015 20:23:44 +0300
Elizabeth Shashkova wrote:
> Hello everybody!
>
> When I call fork() inside a daemon thread, the main thread in the child
> process has the "daemon" property set to True. This is very confusing,
> since the program keeps running while the only
On Thu, Jun 25, 2015 at 12:23 PM, Elizabeth Shashkova <
elizabeth.shashk...@gmail.com> wrote:
> When I call fork() inside a daemon thread, the main thread in the child
> process has the "daemon" property set to True.
Didn't this (or a similar) topic come up here recently? For reference:
http://
On Thu, Jun 25, 2015 at 10:42 AM, Steve Dower wrote:
> This also makes it more viable to use the Windows SDK compilers. If you
> install the Windows SDK 7.0 (which includes MSVC9) and Windows SDK 7.1 (which
> includes the platform toolset files for MSVC9 - toolsets were invented later
> than th
> Another issue that bothers me, is code reuse. Independent from whether the
> 'async def' makes sense or not, it would not allow us to reuse asyncio
> functions as if they were normal functions and vice versa (if I understood
> that correctly). So, we would have to implement things twice for the a
On Thu, Jun 25, 2015 at 1:48 PM, M.-A. Lemburg wrote:
> On 25.06.2015 17:12, Zachary Ware wrote:
>> The old files are moved to PC/VS9.0, and they work as expected as far
>> as I've tested them.
>
> So it's still possible to build with "just" VS 2008 installed
> or will the VS 2010 (or later) be re
On 25.06.2015 17:12, Zachary Ware wrote:
> On Thu, Jun 25, 2015 at 8:54 AM, M.-A. Lemburg wrote:
>> On 22.06.2015 19:03, Zachary Ware wrote:
>>> Using the backported project files to build 2.7 would require two
>>> versions of Visual Studio to be installed; VS2010 (or newer) would be
>>> required
Hello everybody!
When I call fork() inside a daemon thread, the main thread in the child
process has the "daemon" property set to True. This is very confusing,
since the program keeps running while the only thread is a daemon.
According to the docs, if all the threads are daemons the program shoul
I'm with Victor: we are in beta now.
Making C API is useful and important but we may wait for new Python release.
The same for asycnio acceleration: we definitely need it but it
requires inviting C API also I believe.
Personally I've concentrated on making third-party libraries on top of
asyncio
M.-A. Lemburg wrote:
> For VS 2008 we now have a long-term solution thanks to MS.
Without the change to the project files, the compiler at
http://aka.ms/vcpython27 isn't sufficient to build Python itself. In theory,
with even more patching to the projects (or otherwise making up for the fact
th
It looks like the code is currently moving fast. I suggest to wait
until Python 3.6 to stabilize the Python C API for async/await. It's a
pain to maintain a public API. I hate having to add 2 or 3 versions of
a single function :-(
Victor
2015-06-25 17:43 GMT+02:00 Yury Selivanov :
> Hi Arc,
>
>
>
On 25.06.2015 04:16, Steven D'Aprano wrote:
On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
Thanks, Yury, for you quick response.
On 24.06.2015 22:16, Yury Selivanov wrote:
Sven, if we don't have 'async def', and instead say that "a function
is a *coroutine function* when it ha
Hi Arc,
On 2015-06-24 10:36 PM, Arc Riley wrote:
A type slot for tp_as_async has already been added (which is good!) but we
do not currently seem to have protocol functions for awaitable types.
I would expect to find an Awaitable Protocol listed under Abstract Objects
Layer, with functions like
On Thu, Jun 25, 2015 at 8:54 AM, M.-A. Lemburg wrote:
> On 22.06.2015 19:03, Zachary Ware wrote:
>> Using the backported project files to build 2.7 would require two
>> versions of Visual Studio to be installed; VS2010 (or newer) would be
>> required in addition to VS2008. All Windows core develo
On 22.06.2015 19:03, Zachary Ware wrote:
> Hi,
>
> As you may know, Steve Dower put significant effort into rewriting the
> project files used by the Windows build as part of moving to VC14 as
> the official compiler for Python 3.5. Compared to the project files
> for 3.4 (and older), the new pro
On Wed, Jun 24, 2015 at 9:48 PM, Stefan Behnel wrote:
>
>
> I'd wait with that a bit, though, until after Py3.5 is finally released
> and the actual needs for C code that want to use the new
> features become clearer.
>
I strongly disagree.
What we would end up with is 3rd party extension module
Private, since it doesn't really have anything to do with evaluating
actual content. FYI, this thread probably should have stayed on
core-mentorship for a bit and then jumped directly to the tracker.
Rustom Mody writes:
> > because (1) you have some support for the idea that at least
> > some
21 matches
Mail list logo
