[Python-ideas] .then execution of actions following a future's completion

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

Re: [Python-ideas] .then execution of actions following a future's completion

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

Re: [Python-ideas] Non-intrusive debug logging

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

Re: [Python-ideas] Non-intrusive debug logging

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 >>>

Re: [Python-ideas] Non-intrusive debug logging

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

Re: [Python-ideas] Non-intrusive debug logging

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

Re: [Python-ideas] Non-intrusive debug logging

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

Re: [Python-ideas] Non-intrusive debug logging

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

Re: [Python-ideas] __vars__ special method

> 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>

Re: [Python-ideas] Non-intrusive debug logging

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

Re: [Python-ideas] Dataclasses, keyword args, and inheritance

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

Re: [Python-ideas] Preemptive multitasking and asyncio

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]