I really don't want to distract Yury with this. Let's consider this (or
something that addresses the same need) for 3.8.
To be clear this is meant as a feature for concurrent.futures.Future, not
for asyncio.Future. (It's a bit confusing since you also change asyncio.)
Also to be honest I don't
Hello all,
So, first time posting here. I’ve been bothered for a while about the lack of
the ability to chain futures in python, such that the next future will execute
upon the first’s completion. So I submitted a pr to do this. This would add
the .then(self, fn) method to
On Thu, Jan 25, 2018 at 5:09 PM, Nick Timkovich
wrote:
> I think part of the reason that logging appears complicated is because
> logging actually is complicated. In the myriad different contexts a Python
> program runs (daemon, command line tool, interactively), the
I think part of the reason that logging appears complicated is because
logging actually is complicated. In the myriad different contexts a Python
program runs (daemon, command line tool, interactively), the logging output
should be going to all sorts of different places. Thus was born handlers.
If
This can be accomplished as a decorator. Jim Crist wrote a version of this using
the codetransformer library. The usage is pretty simple:
@trace()
def sum_word_lengths(words):
total = 0
for w in words:
word_length = len(w)
total += word_length
return total
>>>
Steve Barnes wrote:
I would suggest, however, that if this feature is introduced it be
controlled via a run-time switch &/or environment variable which
defaults to off.
I disagreew with defaulting it to off. That would encourage
lazy developers to distribute library code full of #l lines,
so
On Thu, Jan 25, 2018 at 11:44:55AM +0100, St??fane Fermigier
wrote:
> 1. I too dislikes the idea of using comments as semantically significant
> annotations.
>
> I think it's quite OK for annotation that are aimed at external tools (e.g.
> '# nocover' or '# noqa') but not
This strikes me as something a debugger should do, rather than the regular
interpreter.
And using comment-based syntax means that they would get ignored by the
regular interpreter— which is exactly what you want.
As for a decoration approach— that wouldn’t let you do anything on a line
by line
Explicit yield points makes reasoning about multitasking much easier. The
author of Twisted wrote an excellent post about this.[1] I agree that the
Python documentation doesn't do justice to the question, "when should I use
asyncio instead of threads?"
[1]
I'm not completely opposed to this feature. But there are some cases to
consider. Here's the first one that occurs to me: note that due to the
way dataclasses work, it would need to be used everywhere down an
inheritance hierarchy. That is, if an intermediate base class required
it, all class
> I think you may have misunderstood the purpose of vars(). It isn't to be
> a slightly different version of dir(), instead vars() should return the
> object's namespace. Not a copy of the namespace, but the actual
> namespace used by the object.
>
> This is how vars() currently works:
>
> py>
Some thoughts:
1. I too dislikes the idea of using comments as semantically significant
annotations.
I think it's quite OK for annotation that are aimed at external tools (e.g.
'# nocover' or '# noqa') but not for runtime behavior.
2. It's probably possible do do interesting things using
12 matches
Mail list logo