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 decorat
> 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> clas
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 d
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] https://glyph.twistedmatrix.com/2014/02/
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 ba
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 for runtime behavior.
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 t
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
>>> sum_wo
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
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 logging output
> should be go
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 concurrent.futures.
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 un
12 matches
Mail list logo
