On 13/06/20 3:02 pm, Steven D'Aprano wrote:
Coroutines are lighter weight than threads because they don't need all
the machinary to pre-emptively run threads in parallel; threads are
lighter weight than processes because they don't need to be in separate
memory spaces enforced by the OS.
Well,
I'm not sure I should rewrite my asyncio code to threading, I'll just keep
going asyncio, maybe one day it'll be possible to get the best of both
worlds ...
On #python they generally tell me that the extra syntax is worth it because
of the internal details, that rewriting to threads does not seem
Hi
Here's something that might make code run quicker. The basic idea is to not
refcount some objects that are sure never to be deleted. On a multicore
machine, this might significantly reduce the number of cache invalidations
(and perhaps misses). I lack many of the skills needed to investigate th
On Sat, Jun 13, 2020 at 8:14 PM J. Pic wrote:
>
> I'm not sure I should rewrite my asyncio code to threading, I'll just keep
> going asyncio, maybe one day it'll be possible to get the best of both worlds
> ...
>
> On #python they generally tell me that the extra syntax is worth it because
> of
This operator will allow to send arguments to function only by certain values.
Example:
def some_function(a > (1, 2,3), b):
# Some code
some_function(1, 2)
some_function(4, 2) # Error "Value '4' is not allowed for argument 'a'"
___
Python-ideas maili
Wouldn't it make more sense to write `def some_function(a in (1, 2,3),
b):`, meaning `a in (1, 2,3)` must be true? Similarly you could have `def
some_function(a > 0):` to mean `a > 0` must be true.
On Sat, Jun 13, 2020 at 2:55 PM artem6191 wrote:
> This operator will allow to send arguments to f
>
> >>> print (1, 2, 3)
> 1 2 3
>
The only real advantage of print being a keyword (exec too, which had tons
of benefits such adding stuff to local scope) was the fact of it actually
being a keyword and not a gimmick to call functions without parentheses.
So this is the worst of 2 worlds. Not a k
Now that double digits reached Python 3 and for the sake of
maintaining compatibility for longer since Python 2.7 recently passed away
and people is finally migrating after 12 years, I propose 5 new Python 3
versions:
So we can have Python 3.10, 3.11, 3.12, 3.13 and finally 3.14 a.k.a Pi-thon
Re
Hi João
You wrote:
> So we can have Python 3.10, 3.11, 3.12, 3.13 and finally 3.14 a.k.a Pi-thon
>
What a lovely idea. There's good precedent for this:
$ tex
This is TeX, Version 3.14159265
$ mf
This is METAFONT, Version 2.7182818 (TeX Live 2019) (preloaded base=mf)
Aside: Each
Is Python 4 being planned at the moment? What backwards incompatible
changes would it introduce?
Steele
On Sat, Jun 13, 2020, 9:22 AM João Bernardo wrote:
> Now that double digits reached Python 3 and for the sake of
> maintaining compatibility for longer since Python 2.7 recently passed away
>
On 2020-06-13 2:32 a.m., Kyle Stanley wrote:
> An await outside async def, would map to awaitable.run().
> A call to baz() would thus create a coroutine foo(), and then run() it.
-1. The `await` expression already has a well-defined purpose of
suspending the coroutine it's used within until
On Sun, Jun 14, 2020 at 12:06 AM Steele Farnsworth
wrote:
>
> Is Python 4 being planned at the moment? What backwards incompatible changes
> would it introduce?
>
It isn't, so "postpone Python 4" really just means "keep doing what's
already happening". At present, it seems fairly likely that the
Can I just write "boo, hiss"?
In any case, even if those may be made unambiguous for the current
parser (I have no idea if that's true), they're visually ambiguous for
a human reader. With parentheses, it's immediate what are function
calls. Without, it's far less obvious whether such calls ar
> Your project is fundamentally about instantiating processes?
Yes, that and spawning other subprocesses depending on the outcome of the
previous one, sometimes concurrently per-host but mostly sequentially, and
clearly most of the time will be spent waiting for suprocesses because all
my commands
On Sat, 13 Jun 2020 at 13:54, artem6191 wrote:
>
> This operator will allow to send arguments to function only by certain values.
> Example:
>
> def some_function(a > (1, 2,3), b):
># Some code
> some_function(1, 2)
> some_function(4, 2) # Error "Value '4' is not allowed for argument 'a'"
def
On 13/06/20 8:47 am, J. Pic wrote:
Why not make using await do asyncio.run "behind the scenes" when called
outside async function ?
That would directly tie the await syntax to the asyncio module. This
would not be a good idea. Currently there is nothing special about
asyncio -- it's just one of
Allowing the 'await' keyword to be omitted would also present some
semantic and implementation difficulties. The mechanism behind
'await' is essentially the same as 'yield from', so you're more
or less asking for 'yield from' to be automagically applied to
the result of an expression.
But this wo
On Sun, Jun 14, 2020 at 9:54 AM Greg Ewing wrote:
> But this would require reading the programmer's mind, because it's
> quite legitimate to create an iterator and keep it around to be
> yielded from later. Likewise, it's legitimate to create an awaitable
> object and then await it later.
>
> (Per
On 14/06/20 12:05 pm, Chris Angelico wrote:
On Sun, Jun 14, 2020 at 9:54 AM Greg Ewing wrote:
Likewise, it's legitimate to create an awaitable
object and then await it later.
(Personally I think it *shouldn't* be legitimate to do that in
the case of await, but Guido thinks otherwise, so it is
On Sun, Jun 14, 2020 at 11:29 AM Greg Ewing wrote:
>
> On 14/06/20 12:05 pm, Chris Angelico wrote:
> > On Sun, Jun 14, 2020 at 9:54 AM Greg Ewing
> > wrote:
> >> Likewise, it's legitimate to create an awaitable
> >> object and then await it later.
> >>
> >> (Personally I think it *shouldn't* be
> If
you're fine with invisible context switches, you're probably better
off with threads, because they're not vulnerable to unexpectedly
blocking actions (a common culprit being name lookups before network
transactions - you can connect sockets asynchronously, but
gethostbyname will block the curr
On 14/06/20 1:42 pm, Chris Angelico wrote:
Hmm, I think I see what you mean. So awaiting it would be "spam(123)"
No, it would still be "await spam(123)". It's just that you wouldn't
be able to separate the await from the call, so this wouldn't be
allowed:
a = spam(123)
await a
Incidenta
On Sun, Jun 14, 2020 at 2:16 PM Kyle Stanley wrote:
>
> > If
> you're fine with invisible context switches, you're probably better
> off with threads, because they're not vulnerable to unexpectedly
> blocking actions (a common culprit being name lookups before network
> transactions - you can conn
> IOW the solution to the problem is to use threads. You can see here
why I said what I did: threads specifically avoid this problem and the
only way for asyncio to avoid it is to use threads.
In the case of the above example, I'd say it's more so "use coroutines by
default and threads as needed"
> for any IO-bound call with a variable time where async isn't an option
(either because it's not available, standardized, widespread, etc.), I'd
advise using loop.run_in_executor()/to_thread() preemptively.
Clarification: this pretty much applies to any non-async IO-bound call that
can block the
25 matches
Mail list logo
