Le mercredi 16 décembre 2015, Franklin? Lee
a écrit :
>
> I am confident that the time overhead and the savings will beat the
> versioning dict. The versioning dict method has to save a reference to
> the variable value and a reference to the name, and regularly test
> whether the dict has changed
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 Pyt
On 16 December 2015 at 01:14, R. David Murray wrote:
> That said, I'm not sure whether or not there is a way we could add
> "supported versions" to the main docs that would make sense and be
> useful...your bugs.python.org issue would be useful for discussing that.
Having "minimum supported versi
On 15 December 2015 at 23:11, Victor Stinner wrote:
> I guess that the optimizations on "in" and "is" operators are fine,
> but optimizations on all other operations must be removed to not break
> the Python semantic.
Right, this is why we have functools.total_ordering as a class
decorator to "fi
I agree with Barry. We need more material that introduces the community to
the new async/await syntax and the new concepts they bring. We borrowed the
words from other languages but not all of their behaviours.
With coroutines in particular, we can do a better job of describing the
differences bet
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 oth
On Dec 15, 2015, at 17:29, 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 o
On Dec 15, 2015, at 05:29 PM, 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
@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.
I realized yet another thing, which will reduce overhead: the original
array can store values directly, and you maintain the refs by
repeatedly updating them when moving refs around. RefCells will point
to a pointer to the value cell (which already exists in the table).
- `getitem` will be almos
On Tue, Dec 15, 2015 at 4:39 PM, Roy Williams wrote:
> Thanks for the insight Guido.
>
> I've mostly used async/await inside of HHVM/Hack, and used Guava/Java
> Futures extensively in the past so I found this behavior to be quite
> surprising. I'd like to use Awaitables to represent a DAG of wor
Thanks for the insight Guido.
I've mostly used async/await inside of HHVM/Hack, and used Guava/Java
Futures extensively in the past so I found this behavior to be quite
surprising. I'd like to use Awaitables to represent a DAG of work that
needs to get done. For example, I used to be one of the
I think there may be somewhat of a language barrier here. OP appears to be
mixing the terms of coroutines and futures. The behavior OP describes is
that of promised or async tasks in other languages.
Consider a JS promise that has been resolved:
promise.then(function (value) {...});
promise.then
2015-12-15 22:10 GMT+01:00 Franklin? Lee :
> (Stealing your style of headers.)
I'm using reStructured Text, it's not really a new style :-)
> Overhead
>
>
> If inner functions are being created a lot, that's extra work. But I
> guess you should expect a lot of overhead if you're doing s
More thoughts. (Stealing your style of headers.)
Just store a pointer to value
=
Instead of having the inner dict store k_v pairs.
In C, the values in our hash tables will be:
struct refcell{
PyObject *value; // NULL if deleted
};
It's not necessary t
Agreed. (But let's hear from the OP first.)
On Tue, Dec 15, 2015 at 12:27 PM, Andrew Svetlov
wrote:
> Both Yury's suggestions sounds reasonable.
>
> On Tue, Dec 15, 2015 at 10:24 PM, Yury Selivanov
> wrote:
> > Hi Roy and Guido,
> >
> > On 2015-12-15 3:08 PM, Guido van Rossum wrote:
> > [..]
>
2015-12-15 12:23 GMT+01:00 Franklin? Lee :
> I was thinking (as an alternative to versioning dicts) about a
> dictionary which would be able to return name/value pairs, which would
> also be internally used by the dictionary. This would be way less
> sensitive to irrelevant changes in the scope dic
Both Yury's suggestions sounds reasonable.
On Tue, Dec 15, 2015 at 10:24 PM, Yury Selivanov
wrote:
> Hi Roy and Guido,
>
> On 2015-12-15 3:08 PM, Guido van Rossum wrote:
> [..]
>>
>>
>> I don't know how long you have been using async/await, but I wonder if
>> it's possible that you just haven't g
On 15/12/15 22:33, Brett Cannon wrote:
> If you want to run the CPython test suite you can look at
> https://docs.python.org/devguide/runtests.html .
Thanks Brett, I'll look on it.
--
Dmitry Moskalchuk
signature.asc
Description: OpenPGP digital signature
___
Hi Roy and Guido,
On 2015-12-15 3:08 PM, Guido van Rossum wrote:
[..]
I don't know how long you have been using async/await, but I wonder if
it's possible that you just haven't gotten used to the typical usage
patterns? In particular, your claim "anything that takes an
`awaitable` has to kno
I think this goes back all the way to a debate we had when we were
discussing PEP 380 (which introduced 'yield from', on which 'await' is
built). In fact I believe that the reason PEP 380 didn't make it into
Python 2.7 was that this issue was unresolved at the time (the PEP author
and I preferred t
Howdy,
I'm experimenting with async/await in Python 3, and one very surprising
behavior has been what happens when calling `await` twice on an Awaitable.
In C#, Hack/HHVM, and the new async/await spec in Ecmascript 7. In Python,
calling `await` multiple times results in all future results getting
On Tue, 15 Dec 2015 at 10:48 Dmitry Moskalchuk wrote:
> Olemis Lang gmail.com> writes:
>
> >
> > Wow ! Awesome ! What specific ISA version(s) and/or device(s) have you
> tried ?
> >
>
> Hi Olemis,
>
> I'm Dmitry Moskalchuk, initial author and main contributor of CrystaX NDK.
> I could provide de
Olemis Lang gmail.com> writes:
>
> Wow ! Awesome ! What specific ISA version(s) and/or device(s) have you tried ?
>
Hi Olemis,
I'm Dmitry Moskalchuk, initial author and main contributor of CrystaX NDK.
I could provide details if needed.
Answering your question, I assume by ISA you mean
"Inst
Wow ! Awesome ! What specific ISA version(s) and/or device(s) have you tried ?
On 12/15/15, Vitaly Murashev wrote:
> A lot of talks and patches around how to cross-compile python for andriod
> ...
>
> Dear python-dev@,
> I just want to say thanks to all of you for the high quality cross-platform
On Sat, Dec 04, 2015 at 7:49 AM, Victor Stinner
wrote:
> Versionned dictionary
> =
>
> In the previous milestone of FAT Python, the versionned dictionary was a
> new type inherited from the builtin dict type which added a __version__
> read-only (global "version" of dictionary
A lot of talks and patches around how to cross-compile python for andriod
...
Dear python-dev@,
I just want to say thanks to all of you for the high quality cross-platform
code.
Using alternative Android NDK named CrystaX (home page -
https://www.crystax.net ) which provides high quality posix su
On Tue, Dec 15, 2015 at 8:04 AM, Victor Stinner
wrote:
> Is it expected that "not x.__eq__(y)" can be different than
> "x.__ne__(y)"? Is it part of the Python semantic?
In Numpy, `x != y` returns an array of bools, while `not x == y`
creates an array of bools and then tries to convert it to a boo
On Tue, 15 Dec 2015 15:41:35 +0100, Laura Creighton wrote:
> In a message of Tue, 15 Dec 2015 11:46:03 +0100, Armin Rigo writes:
> >Hi all,
> >
> >On Tue, Dec 1, 2015 at 8:13 PM, Laura Creighton wrote:
> >> Python 3.5 is not supported on windows XP. Upgrade your OS or
> >> stick with 3.4
> >
> >
In a message of Tue, 15 Dec 2015 11:46:03 +0100, Armin Rigo writes:
>Hi all,
>
>On Tue, Dec 1, 2015 at 8:13 PM, Laura Creighton wrote:
>> Python 3.5 is not supported on windows XP. Upgrade your OS or
>> stick with 3.4
>
>Maybe this information should be written down somewhere more official?
> I c
Hi all
Because the deadline is imminent and because we have only received some
proposals, we have extended the current deadline. The new submission deadline is
2015-12-20.
Call For Proposals
==
This is the official call for sessions for the Python devroom at FOSDEM 2016.
FOSDEM
Hi all
Because the deadline is imminent and because we have only received some
proposals, we have extended the current deadline. The new submission deadline is
2015-12-20.
Call For Proposals
==
This is the official call for sessions for the Python devroom at FOSDEM 2016.
FOSDEM
Hello,
the comparisons >=, <=, >, < cannot be optimized this way. Not every order
is a total order. For example, sets a = {1, 2} and b = {2, 3} are
incomparable (in the sense that both a >= b and a <= b is False), and it is
no pathology.
Regards, Adam Bartoš
__
Oh, I sent my email too quickly, I forgot to ask for other operations.
Currently, FAT implements the following optimizations:
* "not (x == y)" replaced with "x != y"
* "not (x != y)" replaced with "x == y"
* "not (x < y)" replaced with "x >= y"
* "not (x <= y)" replaced with "x > y"
* "not (x > y
Hi,
I implemented more constant folding optimizations in my FAT Python
project, but it looks like I made a subtle change in the Python
semantic.
Replacing "not x == y" with "x != y" changes the behaviour of Python.
For example, this optimization breaks test_unittest because
unittest.mock._Call im
Hi all,
On Tue, Dec 1, 2015 at 8:13 PM, Laura Creighton wrote:
> Python 3.5 is not supported on windows XP. Upgrade your OS or
> stick with 3.4
Maybe this information should be written down somewhere more official?
I can't find it in any of these pages:
https://www.python.org/downloads/window
36 matches
Mail list logo
