On Fri, 29 Apr 2022 at 06:50, Thomas Grainger wrote:
> You can use a `__del__` method that warns on collection - like an unawaited
> coroutine
>
> Also if you're in control of importing the dagfile you can record all created
> dags and report any that are missing from the globals of the module
On Fri, 29 Apr 2022 at 06:38, Thomas Grainger wrote:
> Can you show a run-able example of the successful and unsuccessful usage of
> `with DAG(): ... `?
from airflow import DAG
# correct:
dag = DAG("my_dag")
# incorrect:
DAG("my_dag")
The with construct really has nothing to do with it, but i
Pablo Galindo Salgado wrote:
> As it has been mentioned there is no guarantee that your variable will even
> be finalized (or even destroyed) after the frame finishes. For example, if
> your variable goes into a reference cycle for whatever reason it may not be
> cleared until a GC run happens (and
Dennis Sweeney wrote:
> I don't know if there's anything specifically stopping this, but from what I
> understand, the precise moment that a finalizer gets called is unspecified,
> so relying on any sort of behavior there is undefined and non-portable.
> Implementations like PyPy don't always us
Consider this example code:
def test():
a = A()
test()
Currently, the locals (i.e. `a`) are cleared only after the function
has returned:
If we attach a finalizer to `a` immediately after the declaration then
the frame stack available via `sys._getframe()` inside the finalizer
function does
On Sun, 10 Apr 2022 at 09:31, Daniel Pope wrote:
> I would like to bid again for (import package.module) as an expression.
> Instead of doing the import and assigning package to a variable package it
> would evaluate to the module object package.module.
I like this proposal and I agree with pre
On Fri, 8 Apr 2022 at 16:40, Guido van Rossum wrote:
> The interesting idea here seems to make "lazy imports" easier to implement by
> making them explicit in the code. So far, most lazy import frameworks for
> Python have done hacks with `__getattribute__` overrides. IIRC the Cinder
> version
On Fri, 8 Apr 2022 at 10:15, Daniel Pope wrote:
> But, your proposed syntax is not usable because it is ambiguous. Exactly what
> you propose is already used for decorators in a way that the parser would not
> be able to distinguish a decorator from an import expression. Consider:
>
> @ham.s
On Fri, 8 Apr 2022 at 08:51, Paul Moore wrote:
> Are you exaggerating for effect here or would this *actually* just expand to
>
> from datetime import datetime
> default_args = {
> "start_date": datetime(...)
> }
Yes – and of course that is just a snippet, an actual complete script
will have
This is an idea which has been brought up before, sometimes introduced
as "heresy". But an interesting twist has surfaced now which is
typing.
But firstly, let me present the idea. It is very simple, that Python
should have declarative imports, usable anywhere using a simple
syntax, @.
For exampl
2009/12/10 Darren Dale :
> Those aren't new proposals, though, they already exist in distutils.
I see. Thanks for clarifying –– maybe the PEP should better explain this.
\malthe
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
alVersion`` and
``ChronologicalVersion`` (or ``NumberedVersion``). It's not about
strictness or looseness.
Also, the word "rational" is not familiar to me in the context of
versions; is this term known outside of this proposal? I couldn't f
limitations, however, I could
not find a transformer class compatible with its tree structure.
What's the recommended way of working with the AST tree from the
``parser`` module?
\malthe
___
Python-Dev mailing list
Python-Dev@python.org
http:
Lennart Regebro wrote:
2. Using **kw in the argument and looking for noth "with" and "with_",
that way, which will be backwards compatible.
+1
\malthe
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
14 matches
Mail list logo
