There's no equivalent of https://rye.astral.sh/guide/pyproject/#toolryescripts yet, but it's apparently planned: https://github.com/astral-sh/uv/issues/5903#issuecomment-227...

It's accurate. Here you go: https://twitter.com/adamwathan/status/1559250403547652097?la...

https://twitter.com/adamwathan/status/1226511611592085504?la...

https://twitter.com/adamwathan/status/1296770370209566720?la...

The most authoritative form of documentation that part of a system is considered a serious design flaw and should not be used in new code, is on xitter?

I'm sure new users of the system will find that. Great job everyone.

FFS

> Yes, there are type stubs for these libraries but they’re either forced to be more strict, preventing use of dynamism, or opt for being less strict but allowing you to use all the library features, at the cost of safety.

There are type stubs for Django that somewhat avoid these compromises: https://github.com/typeddjango/django-stubs

To be able to do this they have to use a Mypy plugin though. And even then it's still far from perfect.

And Pycharm and django-stubs can't work together for some reason.

While it's of course not ideal, stub files can help with this issue. For example you can get stubs for Celery that make both `shared_task` and `delay` properly typed: https://github.com/sbdchd/celery-types

Only since 3.10, though, before that it was actually impossible to type the decorators correctly.

> Only since 3.10, though, before that it was actually impossible to type the decorators correctly.

There were type gymnastics you could do using overloads to reach any arbitrary level of coverage, but it was ugly and always short of fully general.

It is indeed a decorator. It's relying on https://peps.python.org/pep-0614/

Thanks for posting that, I was puzzled too.

- - - -

I can't help myself. The example in the PEP:

    buttons = [QPushButton(f'Button {i}') for i in range(10)]

    # Do stuff with the list of buttons...

    @buttons[0].clicked.connect
    def spam():
        ...

    ...

seems silly to me, I would have done something like:

    connect_button = lambda n: buttons[n].clicked.connect

    @connect_button(0)
    def spam():
        ...

I was a huge Python fan but these days I really feel that Python is being improved to death.

I think this specific change is making Python simpler. It was a weird exception that previously only a limited subset of all possible expressions could be used as a decorator. Now the rule is just "you can decorate a function or class with any expression".

You're right, this is simpler and more regular, but I don't feel that's enough of an improvement to warrant the changes required to implement it.

(The C Python interpreter is not the only code that relies on understanding Python code. For example, I used to use a set of tools called "Snakefood" but they aren't currently maintained. So as Python changes and changes they become less and less useful.)

In the PEP itself, under "How To Teach This" it even says, "the average Python programmer is likely unaware that the current restriction even exists."

And the "good example of code ... that would become more readable, idiomatic, and maintainable if the existing restrictions were relaxed." is not a good example. IMO (as I hinted at above) it's an example of code written by a programmer who is less well-practiced than one might hope.

The "Identity function hack" is part-way to the connect_button() function but it stops short at a goofy, ugly strawman function (that shadows '_'!? Why?) rather than factoring out the common parts of the expressions. Rookie mistake, eh?

(The eval hack is clever but stupid.)

So to me this seems like a poorly justified change that solves a non-problem.

Conversely, it gets easier to write outside tools that interact with Python code by removing corner cases and simplifying the grammar.

> In the PEP itself, under "How To Teach This" it even says, "the average Python programmer is likely unaware that the current restriction even exists."

Yup, and that's terrible. It means people are likely to trip over it.

> Conversely, it gets easier to write outside tools that interact with Python code by removing corner cases and simplifying the grammar.

That sounds like a false economy to me. A one time small savings of developer effort (implementing the old grammar rule for decorators wasn't onerous?) to permit foolish and unnecessary intricacies among the laity.

> It means people are likely to trip over it.

Only if they are attempting to do something foolish. (Who puts whole expressions in a decorator!?)

- - - -

Tell you what, you go find examples where people have tripped over it in the past and I'll code golf them to see if I can come up with something idiomatic and simpler. Does that sound like fun to you? ("Cause it does to me. Candy!)

The documentation seems VERY clear that the "type" field in package.json DOES affect the node runtime: https://nodejs.org/api/packages.html#type

gc_lines isn't a tuple here, it's a generator expression. It will be lazily evaluated.

I'm currently experimenting with it, so I don't have a lot to say yet. But you'll want to use this: https://pypi.org/project/django-stubs/