Nathaniel Smith wrote:
It wasn't that we created these keywords to solve some
implementation problem and then inflicted them on users.
I disagree -- looking at the history of how we
ended up with async/await, it looks to me like
this is exactly what *did* happen.
First we had generators. Then
Paul Moore wrote:
I don't know *that* much about Erlang, but Python's model is that of a
single shared address space with (potentially multiple) threads of
code running, having access to that address space.
I don't know much about Erlang either, but from what I
gather, it's a functional
Yann Kaiser wrote:
The way I see it, the great thing about async/await as opposed to
threading is that it is explicit about when execution will "take a
break" from your function or resume into it.
Another thing is that async/await tasks are very lightweight
compared to OS threads, so you can
Erik Bray wrote:
Then following my own logic it
would be desirable to also allow the nested for loop syntax of list
comprehensions outside them as well.
The only use for such a syntax would be to put
an inadvisable amount of stuff on one line.
When describing a procedural series of steps,
the
אלעזר wrote:
it feels like a
placeholder for this meaning would be better. E.g.:
class A:
def __add__(self, other: CLS) -> CLS: ...
That's fine for a class that refers to itself, but
what about classes that refer to each other? This
only addresses a small part of the
Terry Reedy wrote:
In the default
mode with user code executed in a separate no-window process, there is
currently no way for the child process to know the current size of
Shell's tk text window in the parent process.
On unix it should be possible to let the child know if it's
connected
אלעזר wrote:
@partial(partial, partial(partial, partial))
def add(a, b, c): return a + b + c
For large numbers of arguments, it's much clearer if you
write it this way:
>>> from functools import partial as badger, partial as mushroom
>>> @badger(badger, badger(badger, badger(badger,
Arek Bulski wrote:
def __glob_eq__(a,b):
if not a == b:
raise FoundInequalityError(a,b)
return True
assert obj1 == obj2 #<-- using eq above
How would you ensure that this overriding only applied in
the places you want it? You don't want to change the meaning
of == in the code
Chris Angelico wrote:
Yes. You could tweak that by looking at cls.__module__ and grab it
from sys.modules, but I kept the example simple. However, I would NOT
use the standard name lookup mechanism.
Most classes in builtins won't let you monkeypatch them
anyway, so I'm not sure it's worth the
Steven D'Aprano wrote:
Obviously if I write 1.1K then I'm expecting a float.
Why is it obvious that you're expecting a float and not
a decimal in that case?
The SI units are all decimal, and I think if we support these, we should
insist that K == 1000, not 1024. For binary scale factors,
Chris Angelico wrote:
If units are retained, what you have is no longer a simple number, but
a value with a unit, and is a quite different beast. (For instance,
addition would have to cope with unit mismatches (probably by throwing
an error), and multiplication would have to combine the units
Chris Angelico wrote:
f"This is a number: {13:0\u07c4}"
If I understand correctly, the proposal intends to make
it easier for a syntax hightlighter to treat
f"This is a number: {foo[42]:0\u07c4}"
as
f"This is a number: {foo[42] :0\u07c4}"
----
801 - 812 of 812 matches
Mail list logo
