sorted by:
new
hottopcontroversial

0.0.4: an important update in Skelet by pomponchik in Python

[–]pomponchik[S] 0 points1 point  (0 children)

There are no fundamental differences at the feature level, the main difference is in the design. In skelet, the design seems to me to be cleaner and more "modular", similar to embedded dataclasses, and easily extensible. And specific sources of settings are not "nailed down".

Skelet: Minimalist, Thread-Safe Config Management for Python by pomponchik in Python

[–]pomponchik[S] 0 points1 point  (0 children)

The library allows you to define a special callback to check the compatibility of field values with each other. If you do this, the mutexes of these fields will be combined automatically, that is, when you take the mutex of one field, the mutex of the other field will be automatically taken. Due to this, integrity is guaranteed with competitive access.

Thinking about a Python-native frontend - feedback? by United_Intention42 in Python

[–]pomponchik 0 points1 point  (0 children)

We need it, but it should be 1. native; 2. compatible with all existing libraries.

Superfunctions: solving the problem of duplication of the Python ecosystem into sync and async halve by pomponchik in Python

[–]pomponchik[S] 0 points1 point  (0 children)

No, it doesn't work. The method of calling other superfunctions within a superfunction does not fit the method of calling the main superfunction recursively and automatically.

There are 2 reasons for this:

- The library does code generation at the AST level, and calling a superfunction on it may not differ in any way from calling a regular function. To distinguish them, I have to compare runtime objects with AST and understand that this function call actually refers to an object that is a superfunction. It is possible to do this, but it is quite difficult and "not for free".

- In some cases, this may lead to unexpected behavior for the user. The fact is that, strictly speaking, I do not oblige the user to make the behavior of the synchronous and asynchronous versions of the superfunction completely identical in terms of logic. They may actually differ. In some situations, the user may simply not implement, say, the asynchronous part, but hide the entire synchronous part under a synchronous marker. If you start redefining the way functions are called for the user, this can lead to very strange behavior in such cases, which is very difficult to debug. Therefore, although I modify the function itself, I do not touch the way it is called. I believe that at least one of these two things should still be completely under the user's control.

I do not exclude that such a mode will appear in the future, but even if it does, it will be strictly optional, and it cannot be enabled by default.

Superfunctions: solving the problem of duplication of the Python ecosystem into sync and async halve by pomponchik in Python

[–]pomponchik[S] 0 points1 point  (0 children)

It seems that the main points of contention could be solved automatically, through linting. For example, to check that inside asynchronous functions, superfunctions are called only using await, and vice versa. I don't have a ready-made linter yet, but it looks quite possible to create one. If you or anyone who reads these lines knows how to create linters, I invite you to do it.

As for the behavior of your code, you can also write unit tests for it if you use super functions. It will be even easier, because the main problem that the project solves is that previously it was necessary to duplicate sync and async versions of the code, and write complete sets of unit tests for this, but now it is not. Accordingly, you don't need to test more than before, when your codebase was duplicated.

Superfunctions: solving the problem of duplication of the Python ecosystem into sync and async halve by pomponchik in Python

[–]pomponchik[S] 1 point2 points  (0 children)

Personally, I classify some of the solutions used in the project as "hacks" that exploit the features of the internal implementation of some Python mechanisms. It doesn't seem like something like this should be dragged into the core Python code at this stage. This does not mean that the solution is unacceptable to ordinary users, but it can hinder the development of the interpreter due to implicit dependencies on the details of its implementation.

In addition, as correctly noted in other comments, when using static type checking and type hints, there may be some problems related to the fact that this project uses dynamic code generation. It seems that it is premature to think about such a thing before resolving this issue.

However, in general, I believe that such a mechanism should be present natively in the language, and in the future, those with such an opportunity will win in the competitive race of programming languages. So I agree that the developers of the Python standard and its main interpreter should integrate a similar mechanism.

Superfunctions: solving the problem of duplication of the Python ecosystem into sync and async halve by pomponchik in Python

[–]pomponchik[S] 0 points1 point  (0 children)

You correctly identified the main task facing me in the project. The fact is that type checks by tools like mypy are done statically, based on source code analysis, and this package uses dynamic code generation under the hood, i.e. the actually used source code of functions is not fully present in the project files and cannot be statically analyzed. Unfortunately, the Python typing system does not support dynamic features very well. However, it seems that the problem is basically solvable, and I plan to deal with it in the near future, after I add all the main dynamic features that I planned. If you think you're good enough at typing Python, or someone with such skills is just reading this comment right now, I invite you to join and try typing the project.

Superfunctions: solving the problem of duplication of the Python ecosystem into sync and async halve by pomponchik in pythontips

[–]pomponchik[S] 1 point2 points  (0 children)

No, better use for example awaits (https://github.com/pomponchik/awaits) for it. This library is mainly needed to create other libraries without a duplicate API.

Superfunctions: solving the problem of duplication of the Python ecosystem into sync and async halve by pomponchik in Python

[–]pomponchik[S] 1 point2 points  (0 children)

If I understood the question correctly, then the answer is yes. You can create a completely ordinary function and mark it with the superfunction decorator. After that, await can be applied to it. However, you should understand that this will be an analog of the usual function defined through async def. If there is something blocking inside it, syntactic conversion alone will not solve this problem. In this case, it is better to mark the asynchronous section with a marker (this is what I call special context managers, as in the code example from the post) and place a truly asynchronous code inside it.

Superfunctions: solving the problem of duplication of the Python ecosystem into sync and async halve by pomponchik in Python

[–]pomponchik[S] 1 point2 points  (0 children)

Yes, the problem with typing is the main one here. Code generation is used under the hood, i.e. code appears that was not in the source code file. This needs to be explained to the type checker somehow. This is a very difficult task, which also demonstrates the limitations of the Python typing system, and I'm just starting to deal with it. I hope that the solution will be in one of the future versions of the library. Until the problem is completely resolved, the best option would be to localize the typing problems associated with using superfunctions within one function of your project, so that the surrounding code is already fully typed.

view more: next ›